Streaming Analytics

Streaming Analytics wertet laufend eintreffende Ereignisse (etwa Klicks, Sensor-Messwerte oder Zahlungen) direkt beim Eintreffen aus, statt sie erst zu sammeln und später als Block zu analysieren. Das Verfahren berechnet fortlaufend Kennzahlen (aktuelle Zahlen wie Umsatz pro Minute), erkennt Muster in den Daten und löst Alerts (automatische Warnmeldungen) aus, sobald ein Schwellwert überschritten wird. Die Ergebnisse fließen in Dashboards, Warnsysteme oder weitere Verarbeitungsschritte.

Was ist Streaming Analytics?

Streaming Analytics beschreibt die Auswertung eines kontinuierlichen Ereignisstroms, also einer Folge von Ereignissen, die zeitlich geordnet und prinzipiell endlos eintreffen. Die Auswertung läuft mit: Sobald ein neues Ereignis ankommt, aktualisiert das System sein Ergebnis, ohne den gesamten Datenbestand neu zu lesen. Damit liegt der Fokus auf dem analytischen Zweck: laufende Kennzahlen berechnen, Muster erkennen, Warnmeldungen auslösen und vorbereitete Auswertungen (materialisierte Sichten) aktuell halten.

Die zentralen Operatoren sind Windowing, Sessionization, kontinuierliche Aggregation, Joins auf Streams und Muster-Erkennung. Zeitfenster können tumbling (nicht überlappend), sliding (überlappend) oder session-basiert (nach Inaktivitäts-Timeout) definiert sein. Sessionization gruppiert Ereignisse desselben Akteurs zu Sitzungen; kontinuierliche Aggregation liefert laufend aktualisierte Summen, Mittelwerte oder Perzentile pro Fenster. Zustandsbehaftete Berechnungen wie Fenster-Aggregate und Streaming-Joins halten Zwischenergebnisse in einem State-Store; Watermarks steuern die Toleranz gegenüber Ereignissen, die zeitverzögert oder in falscher Reihenfolge eintreffen.

Der Begriff hat an Gewicht gewonnen, weil kontinuierliche Ereignisquellen zunehmen: Klickströme, IoT-Sensorik, Zahlungstransaktionen, Log-Daten und [Change Data Capture](/insights/glossar/change-data-capture/) aus operativen Datenbanken erzeugen laufend Ereignisse. Für analytische Fragen, deren Wert mit der Zeit verfällt (aktuelle Session-Zahlen, laufende Betrugs-Signale, Betriebs-KPIs mit Sekunden-Refresh), reicht die intervallbasierte Batch-Analytik nicht mehr aus.

Werkzeuge für Streaming Analytics sind in zwei Klassen aufgeteilt. Generische Stream-Processing-Engines mit analytischer Fähigkeit wie [Apache Spark Structured Streaming](https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html), [Apache Flink](https://flink.apache.org/) und Kafka Streams decken die klassischen Operatoren ab. Streaming-Datenbanken und Materialisierungs-Engines wie [ksqlDB](https://docs.ksqldb.io/), Materialize und RisingWave stellen kontinuierlich aktualisierte materialisierte Sichten mit SQL-Interface bereit. Auf Databricks wird Streaming Analytics typischerweise mit Structured Streaming oder deklarativ mit [Lakeflow Declarative Pipelines](https://docs.databricks.com/aws/en/dlt/) umgesetzt.

Abgrenzung: Data Streaming, Real-Time Analytics, Batch Analytics und Complex Event Processing

Streaming Analytics wird häufig mit benachbarten Begriffen verwechselt. Die Trennlinien laufen entweder entlang der Perspektive (analytischer Zweck versus Verarbeitungsmodell), der Latenz-Klasse oder des Ausschnitts an Operatoren.

Der wichtigste Unterschied verläuft zwischen Streaming Analytics und Data Streaming: Data Streaming benennt, wie verarbeitet wird (kontinuierlich, inkrementell, auf einem unbounded Strom); Streaming Analytics benennt, wozu (Kennzahlen, Muster, Alerts). Jede Streaming-Analytics-Anwendung stützt sich auf Data Streaming; nicht jede Data-Streaming-Pipeline ist analytisch (reine Replikation via CDC etwa nutzt Streaming ohne analytische Auswertung).

Beispiel: Klickstrom-Aggregation für ein Near-Real-Time-Dashboard

Ein E-Commerce-Betreiber verarbeitet den Klickstrom seiner Web-Anwendung. Klick-Ereignisse laufen über ein Kafka-Topic in eine Spark-Structured-Streaming-Query. Die Query aggregiert in überlappenden Sliding-Windows von einer Minute: aktive Sessions pro Minute, Add-to-Cart-Rate pro Produktkategorie, Conversion-Verhältnis pro Traffic-Quelle. Der State-Store hält die Session-Aggregate; Watermarks verwerfen Ereignisse, die mehr als 60 Sekunden verspätet eintreffen. Das Ergebnis speist ein Dashboard mit einem Refresh-Intervall von fünf Sekunden.

Parallel läuft ein zweiter Streaming-Analytics-Job als Alert-Kanal. Er beobachtet die Add-to-Cart-Rate pro Kategorie in einem gleitenden Fünf-Minuten-Fenster und schreibt ein Alert-Event in ein Kafka-Alert-Topic, sobald der Wert unter einen konfigurierten Schwellwert fällt. Ein nachgelagertes System nimmt das Alert-Event auf und benachrichtigt den Bereitschaftsdienst.

Verbreitete weitere Einsatzfelder sind die Betrugserkennung auf Transaktionsströmen (Aggregate über Häufigkeit, Betrag, geografische Distanz), IoT-Monitoring mit Schwellwert-Alerts auf Sensordaten, Real-Time-Personalisierung mit laufend aktualisierten Session-Merkmalen sowie Betriebs-Dashboards für Logistik, Zahlungssysteme oder Streaming-Plattformen.