Idempotente Datenpipelines: Partitions-Überschreiben, sichere Neuläufe und Backfills ohne Doppelzählung

Ziel

Jede geplante Aufgabe so gestalten, dass ein zweifacher Lauf gefahrlos ist, sodass Wiederholungen, manuelle Neuläufe und historische Backfills nie Zeilen duplizieren oder verlieren, und sodass «letzten Monat neu verarbeiten» ein Befehl ist statt ein Projekt.

Voraussetzungen

Ein Scheduler, der jedem Lauf ein Datenintervall zuordnet. Die Airflow-Dokumentation (zitiert) definiert das Intervall als den Zeitbereich, auf dem ein Lauf arbeitet, plant einen Lauf erst, nachdem sein Intervall geendet hat, damit alle Daten des Zeitraums erfasst werden können, und nennt das Ausführen eines Dags für einen bestimmten historischen Zeitraum einen Backfill. Ihre Seite zu bewährten Praktiken hält fest, dass Aufgaben, da sie wiederholt werden können, bei jedem erneuten Lauf dasselbe Ergebnis erzeugen sollten; sie rät bei einem Neulauf von einfachem INSERT ab (doppelte Zeilen), empfiehlt UPSERT und rät, in einer bestimmten Partition statt in «den zuletzt verfügbaren Daten» zu lesen und zu schreiben.

Schritte

1. Jede Aufgabe über das Intervall parametrisieren (data_interval_start, data_interval_end); nie über «jetzt». Die Auswahl der Eingabe filtert nach dem Intervall, sodass ein Neulauf dieselbe Eingabe sieht, sofern sich die Quelle selbst nicht geändert hat.
2. Die Ausgabe als Ersatz für den Ausschnitt des Intervalls schreiben: Löschen-dann-Einfügen innerhalb einer Transaktion bei einem relationalen Ziel, oder ein Partitions-Überschreiben bei einem dateibasierten Ziel. Sparks INSERT OVERWRITE mit partitionOverwriteMode=dynamic überschreibt nur die Partitionen, die im Lauf Daten erhalten (zitiert); im statischen Modus löscht es zuerst jede Partition, die der Partitionsangabe entspricht.
3. Wo Ersetzen nicht möglich ist (Ereignistabellen, die sich mit anderen Schreibern teilen), nach einem deterministischen, aus dem Datensatz abgeleiteten Schlüssel upserten, etwa der Quellkennung plus Intervall, sodass ein Neulauf aktualisiert statt anhängt.
4. Nachgelagerte Aggregate aus dem ersetzten Ausschnitt neu berechnen lassen statt Deltas zu addieren; ein Aggregat, das Zuwächse summiert, zählt eine per Backfill nachgetragene Partition doppelt.
5. Bei einem Backfill die Intervalle der Reihe nach mit begrenzter Parallelität ausführen und nach jedem Intervall die Zeilenzahl sowie eine Prüfsumme der Schlüsselspalten mit der vorherigen Version dieser Partition vergleichen; die Differenz protokollieren.
6. Abhängige Aufgaben für dieselben Intervalle erneut ausführen; ein Backfill einer Tabelle ohne ihre Konsumenten hinterlässt das Warehouse intern inkonsistent.

Erwartetes Ergebnis

Ein erneuter Lauf eines beliebigen Intervalls hinterlässt eine Ausgabe, die mit einem einzigen sauberen Lauf identisch ist. Ein Backfill über eine Zeitspanne erzeugt dieselben Tabellen, wie wenn der korrigierte Code planmässig gelaufen wäre.

Grenzen und Prüfbasis

Quellen, die die Historie überschreiben (veränderliche operative Tabellen), brechen den Determinismus des Intervalls; pro Intervall einen Snapshot erstellen oder Change Data Capture verwenden. Ein Backfill, der eine Schemaänderung überspannt, braucht für alle Intervalle das neue Schema. Die Methode ist ein aus der zitierten Dokumentation abgeleitetes Vorgehen; es wird keine Messung ihrer Wirkung behauptet.