Thema: data-pipelines
-
Wie weit zurück sollte eine geplante Pipeline für verspätet eintreffende Ereignisse erneut verarbeiten, und wie haben Teams das Fenster gewählt?
Offene Frage: Stream-Engines räumen ein, dass manche Ereignisse beliebig verspätet eintreffen können, und Batch-Scheduler führen jedes Intervall einmal nach dessen Abschluss aus; ein verbreiteter Kompromiss verarbeitet bei jedem Lauf die letzten N Intervalle erneut, aber N ist meist geraten. Welche Evidenz wurde zur Bemessung von N genutzt, und was geschah mit noch später eingetroffenen Ereignissen?
-
ETL versus ELT: Wo die Transformation läuft und was das ändert
ETL transformiert Daten in einer separaten Engine, bevor sie ins Ziel geladen werden; ELT lädt zuerst die Rohdaten und transformiert sie mit der eigenen Verarbeitung des Zielspeichers. Die Wahl entscheidet, wo Rechenleistung bezahlt wird, welche Rohdaten im Warehouse landen und wie leicht sich eine Transformation erneut ausführen lässt.
-
Idempotente Datenpipelines: Partitions-Überschreiben, sichere Neuläufe und Backfills ohne Doppelzählung
Eine Pipeline-Aufgabe sollte bei jedem erneuten Lauf für dasselbe Datenintervall dieselbe Ausgabe erzeugen: eine feste Partition der Eingabe lesen, die entsprechende Partition der Ausgabe ersetzen statt anhängen, und dort, wo Ersetzen nicht möglich ist, nach Schlüssel upserten. Backfills werden dadurch zu gewöhnlichen Neuläufen über eine Reihe von Intervallen, statt zu einer Quelle doppelter Zeilen.
-
Choosing between batch and streaming: required latency, event time and late data
Batch processes a bounded input after its interval closes and is reproducible by construction; streaming processes an unbounded input as it arrives and must reason about event time, watermarks and late data to give stable answers. Pick streaming only when a consumer acts within seconds of an event; otherwise the batch path is simpler, and it is needed for reprocessing anyway.
Maschinenlesbar: JSON