Streaming – Daten-Streaming oder Stream Processing – bezeichnet die kontinuierliche Übertragung und Verarbeitung von Daten als fortlaufenden Strom einzelner Ereignisse oder Datenpunkte, anstatt sie zunächst zu sammeln und als geschlossene Menge (Batch) zu verarbeiten. Im Streaming-Modell wird jedes Datenelement einzeln und sofort nach seinem Entstehen verarbeitet – die Verarbeitung ist kontinuierlich, ohne definierten Anfang oder Ende des Datensatzes.
Streaming ist die technische Infrastruktur hinter Echtzeitdaten: Während Echtzeitdaten das Konzept beschreiben (Daten sofort verfügbar), beschreibt Streaming die Architektur, wie das erreicht wird. Für Automatisierungssysteme ist Streaming relevant, wenn Datenvolumina zu groß für synchrone Verarbeitung sind, wenn Reaktionszeiten unter einer Sekunde erforderlich sind, oder wenn Daten aus vielen parallelen Quellen kontinuierlich zusammengeführt werden müssen.
Streaming-Technologien im Vergleich
Apache Kafka
Hochdurchsatz-Message-Broker. Millionen Events/Sekunde. Persistenter Log. Standard in Enterprise-Umgebungen.
Apache Flink
Stream-Processing-Engine. Komplexe Transformationen, Aggregationen und Joins auf Datenströmen in Echtzeit.
Kafka Streams
Leichtgewichtige Stream-Processing-Bibliothek direkt auf Kafka. Kein separater Cluster nötig.
AWS Kinesis
Managed Streaming-Service von AWS. Einfacher Einstieg, skaliert automatisch, integriert in AWS-Ökosystem.
Redis Streams
Leichtgewichtige Stream-Lösung für moderate Volumen. Gut für Microservice-Kommunikation und Caching-nahe Szenarien.
MQTT
Protokoll speziell für IoT-Geräte. Sehr leichtgewichtig, funktioniert auch mit begrenzter Bandbreite und Rechenleistung.
Wann Streaming, wann Batch?
Streaming ist nicht immer die bessere Lösung – es ist die richtige Lösung für spezifische Anforderungen. Batch-Verarbeitung ist einfacher, günstiger und ausreichend für alle Szenarien, bei denen Reaktionen innerhalb von Minuten oder Stunden akzeptabel sind. Streaming ist erforderlich, wenn Reaktionen in Sekunden oder Millisekunden notwendig sind, wenn ein kontinuierlicher Datenfluss aus vielen parallelen Quellen koordiniert werden muss, oder wenn das Datenvolumen für synchrone Verarbeitung zu hoch ist.
Praxisbeispiel
Ein Logistikdienstleister verarbeitet GPS-Tracking-Daten von 340 Fahrzeugen, die alle 30 Sekunden ihre Position senden. Das sind 680 Ereignisse pro Minute, 40.800 pro Stunde – für Batch-Verarbeitung kein Problem. Aber: Kunden wollen Echtzeit-ETA-Updates, und Disponenten müssen sofort reagieren, wenn ein Fahrzeug vom optimalen Pfad abweicht. Lösung: MQTT für die Fahrzeugkommunikation (leichtgewichtig, auch bei schlechter Mobilfunkverbindung stabil), Kafka als zentraler Event-Bus, ein Flink-Job berechnet ETA und Abweichungs-Alerts in Echtzeit. Dashboard-Update: jede 30 Sekunden. Alert an Disponenten: unter 5 Sekunden nach erkannter Abweichung. Batch-Alterative wäre hier untauglich – ein 15-Minuten-verzögerter Alert bei einer Routenabweichung hat keinen operativen Wert mehr.
