Stream Processing (Stream-Verarbeitung) verarbeitet Daten kontinuierlich und mit geringer Latenz, während sie eintreffen – statt in zeitversetzten Stapeln. Es ist die technische Grundlage für Echtzeit-Analysen, Event-Driven Architecture-Anwendungen und Datenpipelines, die Event Stream-Daten aus Queues und Brokern konsumieren.
Stream Processing vs. Batch Processing
Batch Processing verarbeitet begrenzte Datenmengen nach Zeitplan (stündlich, nächtlich) – einfach und durchsatzoptimiert, aber die Ergebnisse sind mindestens ein Batch-Intervall alt. Stream Processing arbeitet Datensätze einzeln (oder in Mikro-Batches) unmittelbar nach ihrem Eintreffen; die Latenz liegt je nach Engine im Bereich weniger Millisekunden bis Sekunden. Apache Flink gilt als echter kontinuierlicher Stream-Processor, während Spark Structured Streaming Streams als Mikro-Batches verarbeitet.
Fenster und Zustand
Für Aggregationen über Zeitbereiche werden Fenster definiert: Tumbling Windows (fest, überlappungsfrei), Sliding Windows (überlappend, gleitend) und Session Windows (durch Inaktivitätslücken begrenzt). Viele Anwendungen benötigen außerdem zustandsbehaftete Verarbeitung – etwa gleitende Summen oder Anreicherung mit Referenzdaten. Engines wie Flink, Kafka Streams oder ksqlDB halten diesen Zustand verwaltet und checkpointen ihn für Fehlertoleranz.
Garantien und Praxis
Stream-Engines bieten unterschiedliche Liefergarantien: at-most-once (Nachricht kann verloren gehen), at-least-once (keine Verluste, aber Duplikate möglich) und exactly-once (genau einmal – praktisch über idempotente Schreibvorgänge und Transaktionen realisiert). In der Praxis ist at-least-once mit idempotenten Writes oft einfacher und ausreichend. Wichtige Bausteine sind außerdem Dead Letter Queues für nicht verarbeitbare Datensätze und die Replay-Fähigkeit des Event Streams, um Fehler anhand historischer Daten zu reproduzieren.
Verwandte Grundlagen: Event Bus, Message Queue, Change Data Capture.