Zwischen Batch und Streaming wählen: benötigte Latenz, Event-Zeit und verspätete Daten

Worum es geht

Ein Batch-Job liest eine begrenzte Eingabe, üblicherweise ein Intervall der Terminplanung, nachdem das Intervall beendet ist, und schreibt ein Ergebnis, das jederzeit aus derselben Eingabe neu berechnet werden kann. Ein Streaming-Job liest eine unbegrenzte Eingabe, die die Dataflow-Dokumentation (zitiert) als Sammlung mit potenziell unendlich vielen Elementen pro Schlüssel beschreibt, sodass eine Gruppierung allein nach Schlüssel unmöglich ist und die Aggregation Windows, Watermarks und Trigger benötigt; ein Watermark ist der Schwellenwert, ab dem das System erwartet, dass alle Daten eines Windows eingetroffen sind, und Daten, die später mit einem Zeitstempel innerhalb des Windows eintreffen, sind verspätete Daten. Die Flink-Dokumentation (zitiert) unterscheidet zwei Zeitbegriffe: Processing Time, die Uhr der Maschine, die den Operator ausführt, die am einfachsten ist und die niedrigste Latenz aufweist, aber nicht deterministisch ist, da Ergebnisse von Ankunftsgeschwindigkeit und Ausfällen abhängen; und Event Time, den Zeitpunkt, zu dem jedes Ereignis auf seinem erzeugenden Gerät stattfand, was auch bei ausserhalb der Reihenfolge eintreffenden Ereignissen oder beim erneuten Verarbeiten der Historie konsistente Ergebnisse liefert – auf Kosten des Wartens auf Nachzügler, und nur für eine endliche Zeit, da manche Elemente beliebig verzögert eintreffen können.

Warum es wichtig ist

Der Unterschied liegt nicht in der Geschwindigkeit, sondern in der Semantik. Eine Batch-Summe für Montag ist durch die Zeilen definiert, die beim Lauf des Jobs vorhanden waren; eine Streaming-Summe für Montag ist eine Folge vorläufiger Ergebnisse, die sich noch ändern kann, wenn verspätete Ereignisse eintreffen, und das Design muss festlegen, ob diese verworfen, als Korrekturen ausgegeben oder ignoriert werden. Teams, die für ein stündlich aktualisiertes Dashboard auf Streaming setzen, zahlen für Zustand, Checkpoints und einen dauerhaft laufenden Job, ohne dass irgendjemand die dafür erkaufte Latenz nutzt.

So wird es angewendet

• Bei der empfangenden Seite ansetzen: die Aktion benennen, die mit dem Ergebnis ausgeführt wird, und wie rasch nach dem Ereignis sie erfolgen muss. Nur eine Reaktion innerhalb von Sekunden bis einer Minute rechtfertigt einen Streaming-Pfad; ein Bericht kann warten, bis das Intervall abgeschlossen ist.
• Ist Streaming gerechtfertigt, Event Time verwenden, die zulässige Verspätung explizit festlegen und verspätete Ereignisse an einen Side Output leiten, den eine Batch-Korrektur verarbeitet.
• Selbst für gestreamte Ergebnisse einen Batch-Pfad zur erneuten Verarbeitung beibehalten: Er ist die Referenz für Korrektheit, das Werkzeug zur Wiederherstellung nach einem Fehler und der Weg, um die Historie nachträglich zu befüllen.
• Micro-Batches (Minuten) vor einer kontinuierlichen Engine in Betracht ziehen; sie behalten die Batch-Semantik bei geringerer Latenz bei.

Stolpersteine

Stream-Joins halten Zustand für das Join-Window auf beiden Seiten; unbegrenzte Windows bedeuten unbegrenzten Speicher. Exactly-once-Ausgabe erfordert idempotente oder transaktionale Senken, nicht nur eine Engine-Einstellung. Zwei Antworten, gestreamt und per Batch, für dieselbe Metrik müssen abgeglichen werden, sonst vertraut die empfangende Seite keiner von beiden.