Wie wird das Problem des 'Late Arrival' von Events in Streaming-Pipelines mittels Watermarking technisch gelöst?

Watermarking löst die Diskrepanz zwischen Event Time (Zeitpunkt des Ereignisses) und Processing Time (Zeitpunkt des Eintreffens im System). In Streaming-Pipelines nutzen wir Watermarks als heuristische Marker, die dem System signalisieren, wie weit die Event Time vorangeschritten ist. Ein Watermark mit dem Zeitstempel $T$ besagt: „Wir erwarten keine Events mehr mit einem Zeitstempel, der kleiner als $T$ ist.“

Technisch setzen wir diesen Prozess über folgende Schritte um:

  1. Event-Time Extraktion: Jedes Event muss einen Zeitstempel aus der Quelle mitliefern.
  2. Watermark-Generierung: Das System berechnet den Watermark basierend auf dem maximal beobachteten Event-Zeitstempel minus einer definierten Toleranzschwelle (Lateness Threshold).
  3. Fenstersteuerung: Zeitfenster (Windows) bleiben so lange offen, bis der Watermark die obere Grenze des Fensters überschreitet. Erst dann wird das Fenster geschlossen und das Aggregat berechnet.
  4. Handling von Late Data: Events, die nach dem Schließen des Fensters eintreffen, werden als „late“ markiert.

Die Wahl der Strategie beeinflusst direkt die Trade-offs zwischen Latenz und Korrektheit:

StrategieMechanismusAuswirkung auf LatenzDatenvollständigkeit
Strict WatermarkingKurze ToleranzschwelleNiedrig (schnelle Ergebnisse)Risiko von Datenverlust
Relaxed WatermarkingHohe ToleranzschwelleHoch (längeres Warten)Höhere Präzision
Side-OutputLate Events in separaten StreamNiedrigVollständig (via nachträglicher Korrektur)

Die Definition dieser Schwellenwerte ist ein zentraler Bestandteil einer präzisen IT-Consulting & Digitale Strategie, da sie die Systemperformance und die Geschäftslogik maßgeblich beeinflusst. Wenn ein Event eintrifft, dessen Zeitstempel hinter dem aktuellen Watermark liegt, greifen konfigurierbare Policies: Entweder wird das Event verworfen, das bestehende Fensterergebnis aktualisiert (Update) oder das Event in einen Side-Output geschrieben, um es in einer Batch-Korrekturphase zu verarbeiten.

Wir empfehlen, Watermarks niemals statisch zu setzen, sondern dynamische Heuristiken zu implementieren und verspätete Daten konsequent über Side-Outputs in eine Dead-Letter-Queue zu leiten, um die Integrität der Echtzeit-Aggregationen nicht durch zu hohe Latenzen zu gefährden.

Sergej Wiens

Sergej Wiens

Gründer & Software Architekt