Ultraschnelle Anomalieerkennung mit Apache Spark im Echtzeitmodus

Dieser Beitrag stellt ein wiederverwendbares Muster für operative Workloads vor, die wirklich etwas bewirken: Betrugserkennung, IoT-Sensorüberwachung, Echtzeit-Personalisierung, Verarbeitung von Sicherheitssignalen – jedes Szenario, bei dem eine sofortige Reaktion auf Ereignisse für die Geschäftsergebnisse entscheidend ist.

Das Hauptziel: Wenn ein Ereignis verdächtig oder ungültig erscheint, markieren Sie es sofort und leiten Sie es für entsprechende nachgelagerte Maßnahmen weiter.

In diesem Blog demonstrieren wir die Anomalieerkennung bei Ethereum-Blockchain-Transaktionen. Wir analysieren Ethereum-Blockchain-Daten und markieren Transaktionen mit ungültigen Mustern in Echtzeit. Konkret erkennen wir:

1. Datenqualitätsverletzungen: Blöcke, in denen gas_used > gas_limit gemäß dem Ethereum-Protokoll physikalisch unmöglich sind, was auf Datenbeschädigung, Producer-Bugs oder Schema-Parsing-Fehler hinweist
2. Verletzungen der Payload-Hygiene: Das Feld extra_data, das erkennbare PII- oder Anmeldedaten-Muster (E-Mail-Adressen, JWT-Token, AWS-Zugriffsschlüssel) enthält, signalisiert Datenlecks oder falsch konfigurierte Producer

Obwohl wir Ethereum-Daten zur Demonstration verwenden, lässt sich diese Klassifizierung als „verdächtig oder ungültig“ auf zahlreiche wertvolle Anwendungsfälle übertragen:

• Betrugserkennung: Eine Transaktion weist anomale Muster auf → nachgelagerte Untersuchungs-Workflows auslösen
• IoT-Überwachung: Ein Sensorwert liegt außerhalb der physikalisch möglichen Parameter → automatische Reaktion einleiten
• Sicherheitsoperationen: Payload enthält Geheimnisse oder PII-Muster → Quarantäne in Echtzeit mit einheitlicher Governance
• Personalisierungs-Engines: Auf bestimmte Verhaltensereignisse mit sofortigen, kontextbezogenen Angeboten reagieren

Dieselbe Erkennungslogik lässt sich direkt auf jeden Bereich übertragen: Finanztransaktionen mit unerwarteten PII, IoT-Payloads mit Sensorwerten außerhalb des zulässigen Bereichs oder API-Ereignisprotokolle mit Geheimnissen, die hätten geschwärzt werden müssen. Der Ethereum-Stream bietet einen sauberen, reproduzierbaren Datensatz, um dieses Muster in großem Maßstab zu demonstrieren.

Über den Spark Real-Time Mode

Real-Time Mode (RTM) ist ein neuer Trigger-Typ für Apache Spark™ Structured Streaming, der Latenzen im Millisekundenbereich für Spark-APIs liefert – ohne eine separate, spezialisierte Engine wie Apache Flink.

Während der standardmäßige Micro-Batch-Modus von Structured Streaming wie ein Flughafen-Shuttlebus funktioniert, der vor der Abfahrt wartet, bis er voll ist, arbeitet der RTM wie ein Hochgeschwindigkeits-Laufband, das jedes Ereignis bei der Ankunft verarbeitet. Er erreicht dies durch drei architektonische Innovationen: kontinuierlicher Datenfluss (Ereignisse werden bei ihrer Ankunft verarbeitet, nicht in diskreten Blöcken), Pipeline-Scheduling (alle Abfragestufen laufen gleichzeitig und ohne Blockierung) und Streaming-Shuffle (Daten werden sofort im Arbeitsspeicher zwischen Tasks übertragen, unter Umgehung der Festplatte).

Der RTM wurde speziell für operative Workloads entwickelt, bei denen sich die Latenz direkt auf die Geschäftsergebnisse auswirkt – Betrugserkennung, Echtzeit-Personalisierung, ML-Feature-Berechnung und IoT-Überwachung. Für Workloads, die eine Latenz von 1–2 Sekunden tolerieren können, bleibt das traditionelle Micro-Batch-Verfahren die kostengünstigere Wahl.

Warum der RTM ein Game Changer ist

1. Ultraschnell: Latenzzeiten im Subsekundenbereich jetzt erreichbar

Der Real-Time Mode verändert grundlegend, was mit Apache Spark möglich ist. End-to-End-Latenzen von ca. 5 ms bis ca. 300 ms, je nach Komplexität des Workloads, bringen Spark in Bereiche, die zuvor von spezialisierten Stream-Processing-Engines dominiert wurden. Traditionelles Micro-Batch bietet Latenzen von 1–2 Sekunden; der Real-Time Mode erreicht ca. 5 ms bis ca. 300 ms.
Die Architektur erreicht dies durch vorab zugewiesene Ausführungspipelines und asynchrones Checkpointing, wodurch der Scheduling-Overhead entfällt, der die Micro-Batch-Verarbeitung traditionell einschränkte. Für operative Workloads, bei denen es auf Millisekunden ankommt – Betrugserkennung, IoT-Überwachung, Echtzeit-Angebote –, ist dieses Leistungsniveau bahnbrechend.

2. Vereinfachter Stack: Keine separate Technologie erforderlich

Unternehmen stoßen häufig auf ein kostspieliges Missverständnis: „Spark ist für Echtzeit-Anwendungsfälle nicht leistungsstark genug, daher benötigen wir für diese eine Anforderung einen völlig separaten Stack.“

Für Workloads, die eine Latenz von 1–2 Sekunden tolerieren, liefert Spark-Micro-Batch Daten zuverlässig und mit einem hervorragenden Preis-Leistungs-Verhältnis in Delta Lake. Für operative Workloads, die Antwortzeiten im Subsekundenbereich erfordern, macht der Real-Time Mode separate Technologien völlig überflüssig – wie die Teams von Coinbase, DraftKings und MakeMyTrip bestätigen, die ihre analytischen und operativen Workloads auf einem einzigen Spark-basierten Stack konsolidiert haben.

Mit dem Real-Time Mode verarbeitet Spark sowohl analytische (im Sekundenbereich) als auch operative (im Millisekundenbereich) Workloads auf einer einzigen, einheitlichen Plattform. Dies reduziert:

• Operative Komplexität: Ein einziger Technologie-Stack zum Verwalten, Überwachen und zur Fehlerbehebung
• Schulungsaufwand: Vorhandenes Spark-Fachwissen lässt sich direkt auf Echtzeit-Anwendungsfälle übertragen
• Reibungsverluste bei der Integration: Keine komplexen Übergaben zwischen separaten Streaming-Engines
• Gesamtbetriebskosten: Die Konsolidierung senkt Infrastruktur-, Lizenz- und Betriebskosten

3. Entwicklerfreundlich: Einfache Trigger-Änderung, keine Code-Umschreibungen

Der vielleicht überzeugendste Aspekt des Real-Time Mode ist seine bemerkenswerte Einfachheit für Entwickler, die bereits mit Structured Streaming vertraut sind. Die Aktivierung dieser leistungsstarken Funktion erfordert keine komplexe Migration oder grundlegende Code-Restrukturierung.

Unternehmen können Latenzen im Millisekundenbereich freischalten, indem sie einfach die Trigger-Konfiguration ändern:

Das ist alles. Dieselbe vertraute Structured Streaming API. Dasselbe Checkpoint-Management. Dieselbe At-Least-Once-Zustellungssemantik. Nur eine einzige Konfigurationsänderung, um operative Intelligenz im Subsekundenbereich zu ermöglichen.

Hinweis zu Zustellungsgarantien: RTM mit Kafka-Sink bietet At-Least-Once-Zustellungsgarantien. Nachgelagerte Consumer sollten potenzielle Duplikate durch idempotente Schreibvorgänge oder Deduplizierungslogik behandeln.

Diese nahtlose Integration stellt einen entscheidenden Vorteil dar. Teams können operative Workloads prototypisch entwickeln und in die Produktion überführen, ohne den erheblichen Aufwand für das Erlernen, Bereitstellen und Verwalten völlig separater Technologie-Stacks betreiben zu müssen. Dieser Ansatz beschleunigt Innovationen drastisch und verringert gleichzeitig das Risiko, das traditionell mit der Einführung neuer Echtzeitfunktionen verbunden ist.

Nachdem wir dargelegt haben, warum der Real-Time Mode wichtig ist, wollen wir uns ansehen, wie dieses Muster in der Praxis implementiert wird. Die folgenden Abschnitte demonstrieren eine produktionsbereite Guardrail-Pipeline – das operative Muster, das diese Funktionen in geschäftlichen Nutzen verwandelt.

Architektur-Übersicht: Aufbau eines operativen Guardrail-Streams

Jedes eingehende Ereignis wird sofort ausgewertet, wodurch ein angereichertes nachgelagertes Ereignis erzeugt wird, das Folgendes enthält:

• Entscheidung: ALLOW im Vergleich zu QUARANTINE
• Gründe: Detaillierte Erklärung aller ausgelösten Markierungen (Datenqualitätsverletzungen, Bedenken hinsichtlich der Payload-Hygiene)

Dieses operative Muster dient als Single Source of Truth für die Entscheidungsfindung in Echtzeit:

• Sollte dieses Ereignis zur Untersuchung in Quarantäne gestellt werden?
• Wie reichern wir Ereignisse an, damit nachgelagerte Systeme sofort reagieren können?

Obwohl unsere Demonstration Ethereum-Blockdaten verwendet, lässt sich dieses Muster universell anwenden: Finanztransaktionen, Sensormesswerte, Authentifizierungsprotokolle, API-Aufrufe – die Architektur bleibt konsistent.

Validierung im großen Maßstab

Getreu unserem Versprechen, produktionsreife Lösungen bereitzustellen, haben wir dieses Muster im großen Maßstab validiert. Die vollständige Ethereum-Chain – etwa 95 GB verteilt auf 4 Partitionen, was rund 23 Millionen Nachrichten entspricht – wurde zu Testzwecken in Kafka geladen.

Definieren von Validierungsregeln für die Ereignisklassifizierung

Wir implementieren bewusst einfache, aussagekräftige Validierungsregeln:

Regel 1: Validierung der Payload-Hygiene

Scannen Sie das Feld extra_data nach Mustern, die eindeutig auf Daten hinweisen, die in Produktions-Streams nicht vorhanden sein sollten. Die Codebeispiele zeigen eine grundlegende Mustererkennung (E-Mail-Adressen, JWT-Token, AWS-Schlüsselformate).

Unternehmen sollten diese durch Regeln ersetzen, die für ihre Compliance-Anforderungen spezifisch sind – PII-Muster, interne Identifikatoren, API-Anmeldedaten und ähnliche sensible Daten.

Die entscheidende Erkenntnis: Echtzeit-Leitplanken gehören als Teil einer einheitlichen Governance direkt in die Pipeline und sollten nicht erst bei der Analyse nach einem Vorfall entdeckt werden.

Regel 2: Validierung der Datenqualität

gas_used > gas_limit

Diese Bedingung sollte bei gültigen Daten niemals auftreten. Wenn sie erkannt wird, deutet dies auf eines von mehreren Problemen hin:

• Datenbeschädigung während der Übertragung
• Fehler bei der Datengenerierung auf Erzeugerseite
• Inkonsistenzen beim Schema-Parsing
• Ausfälle von Upstream-Systemen

Aus betrieblicher Sicht ist dies genau die Art von Anomalie, die wir sofort kennzeichnen möchten – um eine schnelle Reaktion zu ermöglichen, bevor nachgelagerte Systeme betroffen sind.

Nachdem unsere Validierungslogik steht, widmen wir uns nun der Streaming-Konfiguration, die eine Ausführung im Subsekundenbereich ermöglicht.

Real-Time Mode: Wesentliche Konfiguration

Der Real-Time Mode wird über den Real-Time-Trigger aktiviert und arbeitet im Update-Modus. In PySpark geben Sie einen Intervallparameter an (z. B. "5 minutes").

Zwei kritische Konfigurationsanforderungen:

1. Cluster-Konfiguration: Die Databricks-Dokumentation spezifiziert die erforderlichen Job-Cluster-Einstellungen und das Flag zur RTM-Aktivierung
2. Ausgabemodus: Muss den update-Modus mit RTM-Triggern verwenden

In dieser Demo verwendete Konfiguration:

• Runtime: Databricks Runtime 16.4 LTS oder neuer
• Compute: Dedizierter Cluster (Einzelbenutzer) mit fester Worker-Anzahl (Autoskalierung deaktiviert)
• Photon: Deaktiviert (wird mit RTM nicht unterstützt)
• Worker: 4 Worker für diesen Workload
• Ausgabemodus: update (erforderlich für RTM)

Siehe das begleitende Repository für die vollständige cluster_config.template.json.

Implementierung: Echtzeit-Leitplanken-Pipeline

Diese Single-Pass-Pipeline demonstriert die nahtlose Integration zwischen Kafka und dem Spark Real-Time Mode:

1. Verbindung zur Kafka-Quelle herstellen
2. Eingehende JSON-Payloads parsen
3. Entscheidung und Gründe berechnen
4. Angereichertes JSON zurück in Kafka schreiben

Sie können den Code hier lesen.

Ergebnisse: Leistung im großen Maßstab

Wir haben die Leistung des Real-Time Mode validiert, indem wir Ethereum-Blockchain-Daten verarbeitet haben – ~23 Millionen Nachrichten, verteilt auf 4 Kafka-Partitionen im kontinuierlichen Streaming-Modus.

Durchsatzleistung

Die Pipeline zeigte beeindruckende Durchsatzeigenschaften:

• Eingangsrate: 65.592 Zeilen/Sekunde
• Verarbeitungsrate: 69.713 Zeilen/Sekunde (dauerhaft)
• Verarbeitete Datensätze insgesamt: ~23.213.628 Nachrichten
• Cluster-Konfiguration: DBR 16.4 LTS, 4 Worker (i3.xlarge), dedizierter Einzelbenutzermodus, Photon deaktiviert

Latenzmetriken

Driver-Protokolle erfassen detaillierte Latenzmetriken über das Ereignis spark.streaming.madeProgress. Der Real-Time Mode meldet processingLatencyMs, was die Zeit zwischen dem Lesen eines Datensatzes durch die Abfrage und dem Schreiben in den nachgelagerten Sink misst.

Für diese zustandslose Validierungs-Pipeline, die ~23 Millionen Datensätze verarbeitet, haben wir Folgendes beobachtet:

• P0, P50, P90, P95: 1 Millisekunde (wird in den Metriken auf 0 gerundet) P99: 1 Millisekunde Verarbeitungsrate: 69.713 Zeilen/Sekunde dauerhaft
• Verständnis von processingLatencyMs: Diese Metrik misst die Zeit zwischen dem Lesen eines Datensatzes durch RTM und dem Schreiben in den nachgelagerten Sink. Sie wird pro Task gemessen und im Abschnitt rtmMetrics.processingLatencyMs von StreamingQueryProgress mit Perzentilen (P0, P50, P90, P95, P99) angegeben. Für eine einstufige Kafka-zu-Kafka-Pipeline wie diese stellt sie effektiv die End-to-End-Latenz pro Datensatz dar.
• Bedeutung: Die überwiegende Mehrheit der Datensätze (95. Perzentil) wurde in weniger als einer halben Millisekunde verarbeitet, und selbst das langsamste 1 % war innerhalb von 1 Millisekunde abgeschlossen. Die Werte, die „0“ für P0–P95 anzeigen, weisen auf Latenzen unter 0,5 ms hin (vom Metriksystem abgerundet).

Hinweis: Diese Ergebnisse stellen die Leistung einer zustandslosen Validierungs-Pipeline dar. Komplexere zustandsbehaftete Operationen (Aggregationen, Windowing) können je nach Komplexität des Workloads höhere Latenzen im RTM-Bereich von ~5 ms bis ~300 ms aufweisen.

Wichtige Leistungserkenntnisse

• Interpretation: 99 % aller Datensätze wurden in weniger als 1 Millisekunde verarbeitet, wobei nur das langsamste 1 % eine Millisekunde erreichte. Dies zeigt eine außergewöhnlich konsistente Leistung mit geringer Latenz.
• Durchsatz: Die Pipeline hielt eine Verarbeitungsrate von 69.713 Zeilen/Sekunde aufrecht, während sie ~23 Millionen Datensätze verarbeitete, was eine stabile Leistung unter kontinuierlicher Last beweist.

Diese Metriken bestätigen, dass der Real-Time Mode eine produktionsreife Latenz im Submillisekundenbereich (P95 0,5 ms, P99 = 1 ms) liefert, während er hochvolumige Streams mit fast 70.000 Zeilen/Sekunde verarbeitet – wodurch der traditionelle Kompromiss zwischen einheitlichen Plattformen und Anforderungen an geringe Latenzzeiten entfällt.

Fazit

Der Real-Time Mode erweitert Apache Spark™ Structured Streaming auf eine neue Klasse von Workloads – betriebliche, latenzempfindliche Anwendungen, die eine sofortige Reaktion auf Streaming-Daten erfordern. Indem er den Spark-APIs, die Ihr Team bereits verwendet, Latenzen im Subsekundenbereich verleiht, macht er den Betrieb einer separaten, spezialisierten Engine für Ihre zeitkritischsten Pipelines überflüssig.

Das Wertversprechen ist überzeugend:

• Eine einheitliche Plattform bewältigt sowohl analytische (im Sekundenbereich) als auch betriebliche (im Millisekundenbereich) Workloads
• Bestehendes Spark-Know-how lässt sich direkt übertragen – keine separate Spezialisierung erforderlich
• Minimales Migrationsrisiko – eine einzige Änderung der Trigger-Konfiguration schaltet Echtzeitfunktionen frei
• In der Produktion validierte Leistung – P99-Latenzen von 1 ms bei P95 unter 0,5 ms bei der Verarbeitung von Millionen von Ereignissen

Egal, ob Sie Pipelines zur Betrugserkennung, Personalisierungs-Engines oder ML-Feature-Berechnungssysteme erstellen: Der Real-Time Mode liefert die Latenz, die Ihre Anwendung erfordert, und behält gleichzeitig die Einfachheit und die Breite des Ökosystems von Spark bei.

Erste Schritte

Klonen Sie das begleitende Repository, um diese Leitplanken-Pipeline End-to-End auszuführen – es enthält die vollständige Implementierung, die Cluster-Konfiguration und eine Bereitstellungsanleitung.

Um tiefer einzusteigen, lesen Sie die Dokumentation zum Real-Time Mode für Konfigurationsoptionen und unterstützte Quellen/Sinks, oder sehen Sie sich den Technical Deep Dive zum Real-Time Mode für einen vollständigen Durchgang durch die Architektur an.

Ressourcen

• Real-Time Mode: Technischer Deep Dive – Wie wir Streaming unter 300 Millisekunden in Apache Spark™ integriert haben
• Latenzen im Subsekundenbereich für operative Workloads auf Databricks erzielen
• Databricks Real-Time Mode-Dokumentation
• Zugehöriges Code-Repository – Real-Time Mode Guardrail-Demo – Produktionsbereite Implementierung mit umfassender Testsuite, Clusterkonfiguration und Bereitstellungshandbuch

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag