Im thinkBI Podcast geht es diesmal um Event-Streaming und die Frage, was davon für Business Intelligence eigentlich wirklich relevant ist. Der Reiz des Themas ist offensichtlich: Daten entstehen fortlaufend, Systeme können Ereignisse sofort weitergeben, Dashboards lassen sich beinahe in Echtzeit aktualisieren. Technisch klingt das nach dem nächsten logischen Schritt.
Genau darin liegt aber auch die erste Irritation. Denn nicht alles, was schneller verfügbar ist, ist für BI automatisch besser.
Streaming beginnt nicht beim Dashboard, sondern beim Ereignis
Wenn über Streaming gesprochen wird, denkt man schnell an aktuelle Visualisierungen oder an das Echtzeit-Dashboard. Das greift zu kurz. Der eigentliche Anfang liegt viel früher, nämlich dort, wo in einer Applikation überhaupt ein Ereignis entsteht.
Ein Kunde wird angelegt. Eine Bestellung wird ausgelöst. Ein Sensor sendet einen Wert. Ein Prozess wechselt seinen Status. Solche Ereignisse können von einer Anwendung nicht nur intern verarbeitet, sondern auch an eine Streaming-Infrastruktur weitergegeben werden. Dort kommen Produzenten, Broker, Topics, Queues und Konsumenten ins Spiel. Systeme veröffentlichen Ereignisse. Andere Systeme abonnieren sie. Ein Broker hält sie vor, verteilt sie weiter und macht sie für weitere Verarbeitung verfügbar.
Für BI ist das zunächst eine interessante Möglichkeit. Statt Daten erst später gesammelt aus einer Datenbank oder einem Export zu laden, können Ereignisse unmittelbar in eine analytische Strecke einfließen. Das klingt nach mehr Aktualität. Aber Aktualität allein erklärt noch nicht den Wert.
Das eigentliche Versprechen heißt nicht Tempo, sondern Ereignislogik
Der sichtbare Vorteil von Streaming ist Geschwindigkeit. Die tiefere Veränderung liegt woanders. Streaming ersetzt nicht einfach einen nächtlichen Ladeprozess durch einen schnelleren technischen Transport. Streaming verändert die Logik, nach der Daten überhaupt durch das System laufen.
In klassischer BI werden Daten gesammelt, in einem Rhythmus übernommen und dann in Batches verarbeitet. Dieses Muster ist nicht primitiv. Es ist eine sehr stabile Form von Datenverarbeitung. Sie schafft klare Ladefenster, kontrollierbare Verarbeitung und für viele Entscheidungen vollkommen ausreichende Aktualität.
Wer Streaming wirklich nutzen will, verlässt dieses Muster teilweise. Daten sollen nicht erst liegen bleiben, bis ein Sammelprozess startet. Sie sollen auf dem Weg durch das System bereits weiterverarbeitet werden. Ereignisse werden nicht nur gespeichert, sondern sie werden zum Auslöser weiterer Schritte. Genau deshalb reicht es nicht, irgendwo einen Event Hub oder Kafka-Cluster zu ergänzen und ansonsten im alten Batch-Denken zu bleiben.
Das ist keine kleine technische Erweiterung. Das ist ein Perspektivwechsel.
Man kann Event-Daten laden, ohne schon Streaming-Analytics zu betreiben
Gerade hier liegt eine verbreitete Unschärfe. Natürlich kann man einen Event-Stream auch relativ konservativ nutzen. Ein BI-System kann Ereignisse aus einem Broker in bestimmten Intervallen abholen, bündeln und weiterverarbeiten. Das kann sinnvoll sein. Man hat dann bereits eine andere Datenquelle und vielleicht eine robustere Erfassungslogik als bei anderen Schnittstellen.
Aber das ist noch nicht das volle Versprechen von Streaming-Analytics.
Sobald Ereignisse lediglich gesammelt und später wieder in einem klassischen Rhythmus verarbeitet werden, bleibt die eigentliche Architektur weiterhin batchorientiert. Man nutzt dann Events als Quelle, aber nicht unbedingt eine eventgetriebene Verarbeitung. Das ist kein Fehler. Es ist nur etwas anderes als die starke Echtzeit-Erzählung, die mit Streaming oft verbunden wird.
Genau diese Unterscheidung ist wichtig, weil sie eine nüchterne Entscheidung erlaubt. Nicht jede Organisation braucht sofortige Verarbeitung. Nicht jede Kennzahl gewinnt durch Sekundenaktualität. Nicht jede Entscheidung wird besser, nur weil ein Ereignis sofort sichtbar wird.
Echtzeit ist nur sinnvoll, wenn Entscheidung und Verarbeitung dazu passen
Damit wird das eigentliche Problem sichtbar. Viele Diskussionen über Streaming kreisen um Technologie, aber nicht um Entscheidungslogik. Man spricht über Plattformen, Topics oder Konsumenten, bevor geklärt ist, welche Entscheidung überhaupt von dieser Geschwindigkeit abhängt.
Für viele BI-Situationen reicht ein tägliches Update aus. Manche Bereiche brauchen vielleicht stündliche Aktualisierungen. Wieder andere gewinnen tatsächlich durch Near Real Time, etwa wenn Prozesse überwacht, Zustände laufend bewertet oder operative Reaktionen unmittelbar unterstützt werden sollen.
Der Punkt ist nicht, dass Streaming übertrieben wäre. Der Punkt ist, dass Streaming einen Preis hat. Systeme müssen Ereignisse sauber erzeugen. Broker müssen betrieben werden. Konsumenten müssen robust mit fortlaufenden Nachrichten umgehen. Datenmodelle und Verarbeitungsschritte müssen stärker auf Ereignisfolgen als auf periodische Gesamtbestände ausgelegt werden.
Wer diesen Aufwand eingeht, sollte wissen, wofür.
Gute BI fragt nicht zuerst nach Echtzeit, sondern nach architektonischer Passung
Nach direktem SQL-Zugriff, Dateiexporten und Web-APIs erweitert Streaming den Bereitstellungsraum um eine weitere Option. Aber auch hier gilt dieselbe Grundregel: Nicht die technisch attraktivste Form ist automatisch die beste.
Gute BI fragt deshalb nicht zuerst, ob Echtzeit möglich ist. Gute BI fragt, welche Bereitstellungsform zur Struktur des Problems passt.
Wenn Entscheidungen in einem stabilen Tagesrhythmus getroffen werden, kann eine klassische Batch-Strecke die reifere Lösung sein. Wenn operative Prozesse fortlaufend auf Ereignisse reagieren müssen, kann Streaming sinnvoll sein. Wenn Streaming nur eingeführt wird, weil es moderner wirkt, entsteht leicht eine Architektur, die komplexer ist als der tatsächliche Nutzen.
Vielleicht ist genau das die entscheidende Klarstellung: Streaming ist nicht die schnellere Version klassischer BI. Streaming ist eine andere Verarbeitungslogik. Wer diesen Weg wählt, sollte nicht nur Daten schneller bewegen wollen, sondern Ereignisse, Verarbeitung und Entscheidung neu aufeinander abstimmen.
Dann kann Streaming-Analytics sehr wertvoll sein. Ohne diese Passung bleibt Echtzeit oft nur eine technische Fähigkeit auf der Suche nach einem belastbaren Zweck.
🎧 Die komplette Folge findest du im thinkBI Podcast.
Musik: Great Podcast Intro (short & long) von Lundstroem
Quelle: freemusicarchive.org (Creative Commons) – https://freemusicarchive.org/music/lundstroem/songs-for-leona/great-podcast-intro-both-short-and-long-version-included/
