Echtzeitanalyse: Von aktuellen Daten zu schnelleren Entscheidungen

Echtzeitanalyse wird oft als Wettlauf um eine geringere Latenz betrachtet. Aber nicht jeder Workload erfordert Latenzzeiten im Subsekundenbereich, und die Abfragegeschwindigkeit ist nur ein Teil der Gleichung: Daten können dennoch veraltet sein, die Performance kann bei maximaler Parallelität nachlassen und die nachgelagerte Verarbeitung kann das Ergebnis so weit verzögern, dass es nicht mehr nützlich ist.

Die eigentliche Frage ist, ob der gesamte Analytics-Pfad – vom Eingang neuer Daten in das System bis hin zu einer Person, Anwendung oder einem Agenten, die das Ergebnis nutzen – schnell genug für den unterstützten Workload abläuft. Eine praktische Sicht auf die Echtzeitanalyse blickt über die reine Geschwindigkeit hinaus auf die Architektur, die ein ausreichend aktuelles und zuverlässiges Ergebnis liefert.

Echtzeitanalyse verarbeitet und analysiert Daten, während Ereignisse eintreten oder kurz danach, und bietet Personen oder Systemen einen aktuellen Überblick über das Geschehen. Ein entscheidendes Merkmal der Echtzeitanalyse ist, dass aktuelle Ereignisse zusammen mit historischen Daten in derselben Abfrageumgebung analysiert werden können. Beispielsweise markiert ein Betrugsmodell eine aktuelle Transaktion, indem es sie mit dem Kontoverhalten mehrerer Monate vergleicht. Die genaue Latenzanforderung hängt vom Workload ab – eine Betrugsprüfung benötigt möglicherweise ein Ergebnis in Millisekunden oder Sekunden, während ein Bestands-Dashboard seinen Zweck auch mit Aktualisierungen alle paar Minuten erfüllen könnte.

Der vollständige Pfad sieht in der Regel so aus:

Jede Phase trägt zur verstrichenen Zeit bei. Die Ingestion bestimmt, wie schnell neue Ereignisse oder Änderungen im Quellsystem in die Analyseumgebung gelangen. Die Datentransformation bereitet diese Daten für die Nutzung vor. Data Governance überträgt Definitionen, Zugriffskontrollen und andere Richtlinien in den Pfad mit geringer Latenz. Der Serving-Layer muss Ergebnisse schnell genug für die konsumierende Anwendung oder die Nutzer:innen zurückgeben, und die Antwort muss erfolgen, solange die Informationen nützlich sind.

Der Pfad erklärt, warum die Abfragegeschwindigkeit allein nicht aussagt, ob ein System in Echtzeit arbeitet. Beispielsweise könnte ein Dashboard ein Ergebnis in 200 Millisekunden zurückgeben, während es Daten abfragt, die mehrere Minuten alt sind. Andererseits kann eine kontinuierlich aktualisierte Tabelle das gegenteilige Problem haben, wenn die nachgelagerte Anwendung zu langsam ist.

Drei Kennzahlen beschreiben verschiedene Arten von Latenz.

• Datenaktualität gibt an, wie weit die verfügbaren Analysedaten hinter dem Quellereignis oder Quellsystem zurückliegen. Wenn beispielsweise eine Transaktion um 10:00:00 Uhr stattfindet und um 10:00:08 Uhr abfragbar wird, liegen die Daten bereits acht Sekunden zurück, bevor eine analytische Abfrage beginnt.

• Die Abfragelatenz misst, wie lange eine Abfrage dauert, um ein Ergebnis zurückzugeben, sobald die erforderlichen Daten für den Serving-Layer verfügbar sind. Ein selektives Lookup liefert möglicherweise fast sofort ein Ergebnis, während eine breitere Aggregation über ein großes historisches Dataset länger dauern könnte.

• Die End-to-End-Entscheidungslatenz betrachtet die gesamte verstrichene Zeit vom Ereignis über die Datenverfügbarkeit und -analyse bis hin zur menschlichen oder maschinellen Reaktion. Je nach Architektur können sich einige dieser Phasen überschneiden, anstatt nacheinander abzulaufen.

Die Betrachtung aller drei Aspekte macht es einfacher zu erkennen, woher eine Verzögerung tatsächlich stammt. Für Workloads nahezu in Echtzeit sollten Teams auch die akzeptable Verzögerung explizit definieren. „Neue Datensätze sollten innerhalb von fünf Minuten für die Analyse verfügbar sein“ gibt beispielsweise Architekt:innen, Anwendungsteams und Geschäftsanwender:innen etwas Konkretes an die Hand, an dem sie sich orientieren können.

Echtzeitanalyse, ein Oberbegriff, beschreibt ein analytisches Ergebnis mit geringer Latenz. Streaming Analytics und Analysen nahezu in Echtzeit sind beides Teilbereiche der Echtzeitanalyse – sie unterscheiden sich darin, wie Daten in das System gelangen und ob sie während der Übertragung transformiert werden.

Bei Streaming Analytics werden Daten kontinuierlich erfasst und optional während der Übertragung verarbeitet, bevor sie für Abfragen mit geringer Latenz im Serving-Layer landen. Batch-Analysen bedienen hingegen Workloads, bei denen Aktualität keine primäre Einschränkung darstellt.

Dies sind typische Bereiche, keine festen Grenzen. Die praktische Unterscheidung besteht darin, wie sich Daten durch die Pipeline bewegen: kontinuierlich, in kurzen Intervallen oder in geplanten Jobs. Dies ist die Komponente der Datenaktualität.

Der Serving-Layer bestimmt die Abfragegeschwindigkeit. Echtzeitanalyse erfordert sowohl ausreichend aktuelle Daten als auch ausreichend schnelle Abfragen, sodass die Wahl des Verarbeitungsmusters eher davon abhängt, wie aktuell die Daten sein müssen, als davon, wie schnell die Abfragen zurückgegeben werden müssen. Im Batch geladene Daten können Echtzeitanalysen weiterhin unterstützen, wenn der Serving-Layer schnell ist und der Workload die Verzögerung des Batch-Intervalls toleriert.

Eine geringere Latenz rechtfertigt ihre Kosten nur dann, wenn das Warten auf ein Ergebnis ein Unternehmen daran hindert, das zu tun, was es mit diesem Ergebnis tun muss. Das genaue Latenzziel variiert je nach Anwendungsfall, aber der Test ist ähnlich: Ist der Wert eines früheren Handelns größer als die Kosten für die Reduzierung der Latenz?

Verluste verhindern

Echtzeitanalyse kann Teams dabei helfen, zu reagieren, solange ein Verlust noch vermeidbar ist. Bei der Betrugserkennung gibt die Analyse einer Transaktion vor der Autorisierung dem System die Möglichkeit, sie zu stoppen oder zu überprüfen, bevor sie abgeschlossen ist. In der Fertigung kann die Gerätetelemetrie abnormale Temperatur-, Vibrations- oder Druckwerte schnell genug aufdecken, um eine Inspektion oder Wartung auszulösen, bevor ein Zustand zu Ausfallzeiten führt. Sicherheitsteams verwenden denselben Ansatz, wenn sie Authentifizierungs-, Endpunkt- oder Netzwerkereignisse schnell genug analysieren, um verdächtige Aktivitäten einzudämmen.

Chancen nutzen

Bei Personalisierung, Empfehlungen und Next-Best-Actions kann das jüngste Verhalten ändern, was das System als Nächstes präsentieren sollte. Ein Händler könnte aktuelle Browsing-Aktivitäten mit Produktverfügbarkeit und Kaufhistorie kombinieren, um Empfehlungen während einer Sitzung zu aktualisieren, während ein Preissystem ein Angebot anpassen könnte, wenn sich Nachfrage oder Bestand ändern.

Abläufe verbessern

Operative Entscheidungen hängen oft davon ab, Änderungen zu erkennen, solange noch Zeit ist, die Arbeit umzuleiten. In Lieferketten können Bestands-, Versand- oder Lieferantenaktualisierungen in Prognosen oder Risikomodelle einfließen, die Teams dabei helfen, Bestände neu zuzuweisen, Routen zu ändern oder auf Störungen zu reagieren. In Contact Centern können Live-Transkripte oder Interaktionsdaten die Intent- oder Sentiment-Analyse während des Gesprächs unterstützen und den Agent:innen Hinweise geben, die sie noch vor Ende der Interaktion nutzen können. Ähnliche Muster gelten für Service-Level, Kampagnenoptimierung und andere operative Workflows.

Produktwert schaffen

Einige Produkte stellen Analytics über Dashboards, APIs oder eingebettete Erlebnisse direkt für Kund:innen bereit. In diesen Fällen sind Aktualität und Query-Performance Teil des Produkts selbst. Eine kundenorientierte Anwendung zeigt möglicherweise aktuelle Kontoaktivitäten, den Betriebsstatus oder Nutzungsmetriken an, während eine API aktuelle analytische Ergebnisse in eine andere Anwendung oder einen anderen Workflow einspeisen könnte.

Sobald ein Team weiß, wie schnell ein Ergebnis neue Ereignisse widerspiegeln muss, kann es den End-to-End-Pfad verfolgen, um zu sehen, wo sich Latenz ansammelt.

Ein typischer Workflow sieht so aus:

1. Erstellen oder erfassen Sie eine Ereignis- oder Quellsystemänderung.

2. Erfassen oder replizieren Sie diese Änderung.

3. Validieren Sie die Änderung und reichern Sie sie an oder transformieren Sie sie nach Bedarf.

4. Stellen Sie die resultierenden Daten dem Serving-Layer zur Verfügung.

5. Führen Sie die analytische Abfrage, Regel oder das Modell aus.

6. Stellen Sie das Ergebnis Nutzer:innen, einer Anwendung, einem Workflow oder einem Agenten bereit.

7. Reagieren Sie, wo es der Anwendungsfall erfordert.

8. Beobachten Sie Aktualität, Latenz, Korrektheit und Ausfälle über den gesamten Pfad.

Diese Phasen laufen jedoch nicht immer nacheinander ab. Ein Stream-Prozessor könnte Ereignisse transformieren, während sie aufgenommen werden, nachgelagerte Berechnungen können inkrementell ausgeführt werden und eine Anwendung könnte den Zustand zwischen Ereignissen beibehalten. Was letztendlich zählt, ist die verstrichene End-to-End-Zeit sowie die Latenz und Variabilität der daran beteiligten Phasen.

Angenommen, ein Betrugs-Workload hat ein maximales Antwortfenster von zehn Sekunden. Wenn es routinemäßig sechs Sekunden dauert, bis eine Transaktion vom Quellsystem in einen abfragbaren Zustand übergeht, ist bereits mehr als die Hälfte dieses Fensters verstrichen, bevor die analytische Abfrage beginnt. Die Messung der Latenz in jeder Phase – und die Betrachtung von p50, p95 und p99 anstelle von reinen Durchschnittswerten – hilft Teams zu erkennen, wo sich Verzögerungen unter realen Produktionsbedingungen ansammeln.

Die Messung der Latenz in jeder Phase zeigt, wo Zeit verbraucht wird, aber das Produktionsverhalten fügt weitere Einschränkungen hinzu. Eine Query-Performance, die bei geringer Last gut aussieht, kann bei Spitzen-Parallelität nachlassen, und ein hoher Ereignisdurchsatz garantiert nicht, dass nachgelagerte Daten aktuell bleiben.

Die Pipeline muss auch unordentliches Ereignisverhalten bewältigen, ohne nachgelagerte Ergebnisse zu verfälschen. Ereignisse können verspätet oder in der falschen Reihenfolge eintreffen, und Anwendungen senden sie möglicherweise erneut, wenn die Zustellung ungewiss ist. Netzwerkunterbrechungen können ebenfalls Lücken oder Duplikate erzeugen. Abhängig von den beteiligten Technologien können Teams Replay, Deduplizierung, idempotente Schreibvorgänge, Offsets und Event-Time-Handling verwenden, um den nachgelagerten Zustand konsistent zu halten.

Governance hat auch architektonische Konsequenzen. Das Verschieben aktueller Daten in ein separates Serving-System kann die Reaktionszeit verbessern, schafft aber auch einen weiteren Ort, an dem Zugriffsrichtlinien, Metrikdefinitionen und Datenherkunft (Data Lineage) reproduziert werden müssen.

Diese Duplizierung wird mit zunehmender Erweiterung der Architektur schwerer zu verwalten. Wie Will Xu, Principal Product Manager für Snowflake Interactive Analytics, sagt: „Jedes Mal, wenn Daten eine sichere Umgebung verlassen, um woanders transformiert zu werden, erstellen Sie Sicherheitsregeln neu und hoffen, dass Sie es zweimal richtig gemacht haben. Eine Pipeline, die sich über fünf Tools erstreckt, schafft fünf Fehlerquellen, an denen eine kleine Änderung im Upstream unbemerkt nachgelagerte Dashboards beschädigen kann.“ Die Aufbewahrung aktueller und historischer Daten unter demselben Governance-Modell verringert das Risiko von Lücken in der Zugriffskontrolle, inkonsistenten Metriken und lückenhafter Datenherkunft.

Aktuelle Daten können auf unterschiedliche Weise in das System gelangen. Einige Workloads beginnen mit expliziten Ereignis-Streams, während andere auf Change Data Capture oder Replikation angewiesen sind, um Einfügungen, Aktualisierungen und Löschungen aus operativen Systemen zu erfassen.

Wenn neue Ereignisse oder Datenbankaktualisierungen die analytische Umgebung erreichen, sollte der Pfad mit geringer Latenz nur die Vorbereitung umfassen, die für das unmittelbare analytische Ergebnis erforderlich ist. Inkrementelle Verarbeitung kann unnötige Neuberechnungen reduzieren, wenn sich nur ein Teil der Quelldaten ändert. Das bedeutet nicht automatisch ein ereignisweises Streaming: Ein inkrementelles System kann dennoch nach einem Zeitplan oder gemäß einem Aktualitätsziel aktualisiert werden.

Für viele Workloads benötigt das aktuelle Ereignis auch einen historischen Kontext. Ein Transaktionsbetrag, ein Sensorwert oder eine Kundenaktion bedeutet oft mehr, wenn sie mit früherem Verhalten, etablierten Baselines oder zentral festgelegten Geschäftsdefinitionen verglichen werden können.

Sobald die Daten vorbereitet sind, bestimmt der Serving-Layer, wie schnell Nutzer:innen und Anwendungen sie abrufen können. Die richtige Wahl hängt von der Art des Workloads ab: was abgefragt wird, wie viele Anfragen gleichzeitig eintreffen, wie viel historischer Kontext benötigt wird und welche Latenz die nutzende Anwendung aufrechterhalten muss.

Ein guter Ausgangspunkt ist es, diese Anforderungen zuzuordnen, bevor Technologien verglichen werden:

Die Tail-Latenz verdient besondere Aufmerksamkeit. Eine durchschnittliche Abfragezeit von 300 Millisekunden sagt beispielsweise nicht viel über die Erfahrung von Nutzer:innen aus, deren Anfragen regelmäßig in einem p99 von drei Sekunden landen. In interaktiven Anwendungen definieren diese langsameren Anfragen oft das Erlebnis unter Produktionslast.

In-Memory-Verarbeitung und Caching können die Abruflatenz für einige Zugriffsmuster senken, obwohl keines von beiden den gesamten End-to-End-Pfad adressiert. Ein Cache benötigt weiterhin eine Aktualitätsrichtlinie und Invalidierungslogik. Wenn Aktualisierungen ihn nur langsam erreichen, geben sehr schnelle Lesevorgänge einfach ältere Daten effizienter zurück.

Einige Architekturen lösen dies, indem sie separate Systeme für Ereignistransport, Stream-Processing, analytisches Serving, Caching und Präsentation verwenden. Jedes zusätzliche System führt seine eigenen Fehlermodi, Governance-Grenzen und operativen Mehraufwand ein, weshalb die Konsolidierung eines größeren Teils des Pfads auf einer einzigen Plattform sowohl Komplexität als auch Risiko reduzieren kann.

Sobald die Daten den Serving-Layer erreichen, stellt sich als Nächstes die Frage, wie Personen und Anwendungen sie konsumieren werden. Ein Dashboard, eine kundenorientierte Anwendung, eine API oder eine dialogbasierte Benutzeroberfläche können alle auf derselben Architektur mit geringer Latenz aufbauen, aber jede hat unterschiedliche Anforderungen an Performance und Parallelität.

Für interaktive Analytics, einschließlich natürlichsprachlicher und dialogbasierter Analytics, sollten Teams eine akzeptable Reaktionszeit neben der erwarteten Parallelität, einschließlich der Spitzennachfrage, definieren. Die Performance bei leichtem Entwicklungsverkehr kann ganz anders aussehen, wenn Hunderte oder Tausende von Nutzer:innen oder Anwendungen gleichzeitig Anfragen stellen.

Abfragemuster beeinflussen auch die Vorhersehbarkeit. Hochselektive Anfragen erzeugen im Allgemeinen eine konsistentere Latenz als offene Operationen, die große Datenmengen scannen. Wenn eine teure Abfrage nützlich ist, benötigt die konsumierende Anwendung möglicherweise einen Fallback – asynchrone Verarbeitung, ein weniger detailliertes Ergebnis oder einen klaren Hinweis darauf, dass die Anfrage länger dauern wird.

Aktualität sollte auch dort sichtbar sein, wo Nutzer:innen sie benötigen. Ein „Datenstand“-Indikator hilft beispielsweise jemandem, ein Dashboard oder eine operative Ansicht zu interpretieren, deren Nützlichkeit von der Aktualität abhängt. Anwendungen und APIs können stattdessen Aktualitäts-Metadaten offenlegen, die nachgelagerte Systeme programmatisch auswerten können.

Will Xu von Snowflake drückt es so aus: „Behandeln Sie Live-Zahlen und endgültige Zahlen nicht als dasselbe. Eine Live-Zahl sollte deutlich sichtbar als ‚Stand jetzt‘ gekennzeichnet sein – ähnlich wie ein Aktienkurs, der während der Handelszeiten schwankt –, während die Schlusszahl geprüft wird. Geben Sie Ihren Teams Live-Daten für mehr Tempo, aber legen Sie für das Vertrauen verbindliche Abschlusswerte fest.“

Zentral festgelegte Definitionen müssen über diese Schnittstellen hinweg intakt bleiben. Umsatz, aktive Kund:innen oder Bruttomarge sollten dasselbe bedeuten, unabhängig davon, ob das Ergebnis in einem Dashboard, einer Anwendung oder einer natürlichsprachlichen Antwort erscheint. Zugriffskontrollen und Datenherkunft sollten mit den Daten mitgeführt werden, wenn diese die einzelnen Nutzungsschichten erreichen.

Predictive Analytics muss verschiedene zeitliche Anforderungen bewältigen. Teams müssen die Aktualität der Modelleingaben, die Zeit zur Generierung einer Vorhersage und die Zeit zwischen dieser Vorhersage und der daraus resultierenden Aktion verfolgen.

Die Feature-Aktualität gibt an, wie aktuell die Modelleingaben sind. Die Inferenzlatenz misst, wie lange das Modell benötigt, um eine Vorhersage zu erstellen. Die Aktionslatenz umfasst die Zeit zwischen der Vorhersage und der darauf folgenden Reaktion.

Diese Phasen laufen nicht zwangsläufig im selben Rhythmus ab. Einige Workloads nutzen Online-Scoring, bei dem ein Modell ein einzelnes Ereignis bewertet, sobald es auftritt. Andere aktualisieren Vorhersagen alle paar Minuten, sobald neue Feature-Werte verfügbar sind. Ereignisgesteuerte Inferenz ist eine weitere Option, bei der eine bestimmte Änderung eine neue Vorhersage auslöst, auch wenn dies bei den meisten Quellereignissen nicht der Fall ist. Welches Muster am besten funktioniert, hängt davon ab, wie lange die Vorhersage nützlich bleibt.

Aktuelle Features benötigen weiterhin die üblichen Modellkontrollen. Teams müssen Drift, verzögerte Labels, Feedbackschleifen und Änderungen in der Verteilung eingehender Daten berücksichtigen.

Bei Empfehlungssystemen, Anwendungen und KI-Agenten können aktuelle Daten den Kontext verändern, der verwendet wird, um Optionen zu bewerten, eine Aktion auszuwählen oder eine Antwort zu generieren. Beispielsweise könnte ein Empfehlungssystem die aktuelle Sitzungsaktivität mit der Kaufhistorie, der Produktverfügbarkeit und früheren Präferenzen kombinieren. Die Ereignis-Ingestion bringt das neue Verhalten ein, Feature-Updates integrieren es in den relevanten Kontext, die Entscheidungsfindung wählt eine Ausgabe aus und Feedback-Signale zeigen, was danach passiert ist.

Ein Agent, der mit Unternehmensdaten arbeitet, benötigt eine Möglichkeit, um festzustellen, ob der erhaltene Kontext für die angeforderte Aufgabe aktuell genug ist. Zugriffsrichtlinien sollten angewendet werden, und das System benötigt ein beobachtbares Fallback-Verhalten, wenn erforderliche Informationen veraltet oder nicht verfügbar sind.

Für diese Workloads ist Aktualität nur nützlich, wenn die Anwendung sie mit dem Kontext kombinieren kann, auf den sie sich bereits stützt. Eine Empfehlungs-Engine könnte das aktuelle Sitzungsverhalten zusammen mit der Kaufhistorie nutzen, während ein KI-Agent möglicherweise die neuesten operativen Daten zusammen mit zentral festgelegten Geschäftsdefinitionen und Berechtigungen benötigt.

Bei der Echtzeitanalyse geht es nicht nur darum, Ereignisse schneller zu erfassen. Der wahre Wert liegt darin, Live-Signale in vertrauenswürdige Entscheidungen und Kundenerlebnisse zu verwandeln. Snowflake vereint den Lebenszyklus der Echtzeitanalyse auf einer vernetzten Plattform mit zentraler Governance.

Mit Snowpipe Streaming schreiben Ihre Anwendungen Zeilen direkt in Snowflake-Tabellen, sobald sie eintreffen. Es unterstützt bis zu 20 GB/s aggregiert (unkomprimiert) pro Tabelle und eine Latenz von nur 5 Sekunden mit einem pauschalen, auf der Ingestion basierenden Preismodell. Mit Named Channels bleiben die Zeilen in der Reihenfolge, in der Sie sie innerhalb jedes Kanals senden, und mithilfe integrierter Offset-Token können Ihre Anwendungen selbst nach einem Neustart eine Exactly-once-Zustellung erreichen. Elastic Channels ermöglichen es Tausenden von Geräten oder Diensten, über einen einzigen gemeinsamen Endpunkt, der selbstständig skaliert und eine At-least-once-Zustellung bietet, in eine einzige Tabelle zu streamen, sodass Sie nur einen Verbindungspunkt verwalten müssen.

Für Transformationen ermöglichen Dynamic Tables Teams die Definition der transformierten, analysebereiten Tabellen, die nachgelagerte Dashboards, Anwendungen und Nutzer:innen benötigen. Abhängig vom konfigurierten Aktualisierungsmodus und den unterstützten Abfrageoperationen können Dynamic Tables nur geänderte Zeilen verarbeiten, anstatt das gesamte Ergebnis neu zu berechnen.

Für latenzempfindliches Query Serving nutzt Interactive Analytics interaktive Warehouses, die für analytische Workloads mit geringer Latenz und hoher Parallelität konzipiert sind. Interaktive Warehouses unterstützen Standard-, dynamische, interaktive und Iceberg Tables.

Mit Snowflake können Unternehmen Daten von der Ingestion über analysebereite Tabellen bis hin zu umsetzbaren Erkenntnissen auf einer Plattform mit zentraler Governance bringen, ohne einen separaten Echtzeit-Data-Stack zu erstellen oder Daten in isolierte Serving-Systeme zu duplizieren. Echtzeitdaten bleiben mit Kontext und Governance verbunden, was Teams hilft, mit weniger operativer Komplexität und dem Potenzial zur Kostensenkung vom Ereignis über die Erkenntnis zur Aktion zu gelangen.

Eine nützliche Echtzeit-Architektur beginnt damit, was der Workload von aktuellen Daten benötigt: eine Live-Ansicht, eine menschliche Entscheidung, eine Anwendungsantwort oder eine automatisierte Aktion. Von dort aus können Teams bestimmen, wie schnell neue Ereignisse verfügbar sein müssen, wie viel Transformation vor dem Konsum erfolgen muss, welche Abfragelatenz der Serving-Layer aufrechterhalten muss und wie viel Variabilität der Anwendungsfall bei p95 oder p99 tolerieren kann.

Die Architektur sollte neue Informationen schnell genug durch das System leiten, um eine aktuelle Ansicht, Entscheidung oder Antwort zu unterstützen.