Wie gehst du in einer Streaming-Pipeline mit verspätet eintreffenden Events um?

Nutz Event Time statt Processing Time und definier ein Watermark, also die heuristische Schätzung der Engine, dass keine Events älter als ein bestimmter Timestamp mehr eintreffen. Fenster schließen, wenn das Watermark ihr Ende passiert. Setz eine erlaubte Verspätung, damit leicht verspätete Events Ergebnisse noch aktualisieren, und leite alles Spätere in einen Side Output oder eine Abstimmungstabelle, statt es stillschweigend zu verwerfen.

Zuerst hängt alles an der Event Time, denn Ergebnisse nach Processing Time ändern sich bei jedem Replay und sind damit für Abstimmungen wertlos. Das Watermark ist dann die Behauptung der Engine, dass sie keine Events älter als diesen Timestamp mehr erwartet, und Fenster werden finalisiert, wenn es sie passiert. Diesen Abstand zu wählen ist die eigentliche Designentscheidung: ein kurzes Watermark liefert schnelle Ergebnisse, die manchmal unvollständig sind, ein langes liefert korrekte Ergebnisse spät. Ich setze das aus Daten und nicht aus dem Bauch. In einer Mobile-App-Pipeline haben wir den Abstand zwischen Event Time und Ingestion Time gemessen und fanden das 99. Perzentil bei etwa vier Minuten, getrieben von Handys ohne Netz, also haben wir die erlaubte Verspätung auf zehn Minuten gesetzt. Alles Spätere ging in einen Side Output, der einen täglichen Abstimmungsjob speiste, welcher die betroffenen Fenster im Warehouse korrigiert hat. Die Regel, an der ich festhalte: verspätete Daten werden nie leise verworfen. Wenn wir sie verwerfen, werden sie vorher gezählt.