Streaming Data & Apache Kafka: Real-Time-Architektur

Real-Time-Daten sind kein Luxusfeature. Für eine wachsende Klasse von Use Cases sind sie eine geschäftliche Anforderung.

Fraud Detection, die auf den Transaktionen von gestern läuft, ist nutzlos. Personalisierung auf Basis des Verhaltens der letzten Woche verpasst den Moment. Operative Dashboards, die sich stündlich aktualisieren, kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen keine Echtzeitentscheidungen tragen. Der geschäftliche Wert von Daten nimmt mit der Zeit ab, und bei manchen Use Cases sehr schnell.

Was Streaming Data tatsächlich ist

Streaming Data ist eine kontinuierliche, unbegrenzte Folge von Events. Anders als Batch-Daten (ein begrenzter Datensatz, der in geplanten Intervallen verarbeitet wird) fließen Streaming-Daten kontinuierlich und müssen mit niedriger Latenz verarbeitet werden.

Ein Beispiel aus der Praxis: Jeder Klick, jeder Page View, jedes Add-to-Cart und jeder Kauf auf einer E-Commerce-Site ist ein Streaming-Event. Diese Events entstehen durch Nutzeraktionen im Millisekundenbereich. Ihre Verarbeitung in Real Time ermöglicht: Echtzeit-Bestandsaktualisierungen, sofortiges Fraud Scoring, Live-Personalisierung und operative Dashboards.

Apache Kafka: die dominierende Streaming-Plattform

Kafka ist der De-facto-Standard für Streaming-Data-Infrastruktur. Die Architektur im Überblick:

Topics: Logische Kanäle. Events werden in Topics veröffentlicht (z. B. "checkout-events", "user-clicks"). Topics können viele Producer und viele Consumer haben.

Producer: Anwendungen, die Events in Topics veröffentlichen. Ihr Checkout-Service veröffentlicht ein "purchase-completed"-Event, sobald eine Order aufgegeben wird.

Consumer: Anwendungen, die Topics abonnieren und Events verarbeiten. Ihr Fraud-Detection-Service konsumiert "purchase-completed"-Events und bewertet jede Transaktion.

Consumer Groups: Mehrere Consumer können eine Gruppe bilden und die Arbeit untereinander aufteilen. Wenn Sie ein Topic mit 10 Partitionen und 10 Consumer-Instanzen haben, bearbeitet jede Instanz eine Partition, horizontale Skalierbarkeit.

Retention: Kafka speichert Events für einen konfigurierbaren Zeitraum (Standard: 7 Tage). Späte Consumer können die Historie erneut abspielen. Das unterscheidet sich von einer Message Queue, in der konsumierte Nachrichten gelöscht werden.

LinkedIn, wo Kafka erfunden wurde, verarbeitet damit über eine Billion Events pro Tag. Uber, Netflix und Airbnb bewegen jeweils Hunderte Milliarden Events täglich durch Kafka-Cluster.

Stream Processing: Apache Flink und Spark Streaming

Events aus Kafka zu konsumieren ist eine Sache. Sie in Real Time zu enrichen, zu joinen, zu aggregieren und darauf zu reagieren erfordert Stream Processing.

Apache Flink ist die dominierende Stream-Processing-Engine. Sie verarbeitet Events mit Latenzen unter einer Sekunde, unterstützt zustandsbehaftete Berechnungen (laufende Summen, Session Windows) und geht sauber mit verspätet eintreffenden Daten um.

Apache Spark Structured Streaming ist der Spark-native Ansatz, vertraut für Teams, die Spark bereits im Batch einsetzen. Unterstützt Micro-Batch (nahe Real Time) nativ, echtes Streaming mit höherer Komplexität.

Beispiel-Use-Case: Eine Streaming-PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen → für Fraud Detection in Real Time:

1. Kafka konsumiert Purchase-Events aus dem Checkout-Service
2. Flink enricht jedes Event mit der Kundenhistorie (aus einem Feature StoreFeature StoreEin zentrales Repository zur Verwaltung von ML-Features, das Konsistenz zwischen Training und Serving sicherstellt.Vollständige Definition ansehen → abgerufen)
3. Flink wendet das Fraud-Scoring-Modell an (unter 100 ms)
4. Liegt der Score über dem Schwellwert, wird das Event in das Topic "flagged-transactions" veröffentlicht
5. Ein nachgelagerter Service löst eine manuelle Prüfung oder eine Kartensperre aus

Der gesamte Ablauf ist in unter 500 ms abgeschlossen, vom Purchase-Event bis zum Fraud Flag.

Wann Streaming den Aufwand wert ist (und wann nicht)

Streaming-Infrastruktur ist deutlich komplexer aufzubauen und zu betreiben als Batch. Bevor Sie sich festlegen:

Real Time lohnt sich, wenn:

• Geschäftsentscheidungen mit Datenlatenz stark an Wert verlieren (Fraud, Live-Personalisierung)
• Operative Prozesse den aktuellen Zustand benötigen (Bestand, Logistik)
• Kundenseitige Features von Real-Time-Daten abhängen

Batch genügt, wenn:

• Analytische Workloads keine aktuellen Daten brauchen (Wochenreports, Monatsmodelle)
• Eine Latenz von einigen Stunden akzeptabel ist
• Die Streaming-Expertise im Team begrenzt ist

Die Streaming-Steuer, zusätzliche Engineering-Komplexität, operativer Overhead, schwierigeres Debugging, ist real. Zahlen Sie sie nur, wenn der Business Value es rechtfertigt.

Quiz Questions

1. Quelle est la principale différence entre le streaming et le batch processing ?

A) Le streaming est toujours plus coûteux

B) Le streaming traite des événements continus avec une faible latence, le batch traite des datasets bornés à intervalles planifiés

C) Le batch ne peut pas gérer de grandes quantités de données

D) Le streaming nécessite obligatoirement Apache Kafka

Réponse: B

1. Dans l'architecture Kafka, qu'est-ce qu'un "topic" ?

A) Un type de message d'erreur

B) Un canal logique auquel les producteurs publient des événements et que les consommateurs lisent

C) Une base de données de streaming

D) Un outil de monitoring

Réponse: B

1. Pour quel cas d'usage le streaming en temps réel est-il absolument nécessaire par rapport au batch ?

A) Rapports hebdomadaires de revenus

B) Modèles de prévision mensuels

C) Détection de fraude en temps réel lors des transactions

D) Consolidation des données comptables

Réponse: C