Was macht Backfills und Replays entwerfen?
Verwendungszweck
- Historie für ein neues Modell/eine neue Pipeline laden.
- Vergangene Fenster nach der Behebung eines Transformationsfehlers erneut verarbeiten.
- Ereignisse wiederholen oder eine Tabelle aus Rohdaten neu ableiten.
- NICHT verwenden für normale inkrementelle Läufe (verwende
building-dbt-models/authoring-airflow-dags).
Warum dies Aufmerksamkeit verdient
Backfills sind die gefährlichste Routineoperation im Data Engineering: Sie überschreiben die Historie. Falsch durchgeführt, führen sie zu Doppelzählungen, ändern die Zahlen von gestern oder überlasten die Produktion. Richtig durchgeführt, sind sie langweilig und wiederholbar. Voraussetzung ist Idempotenz (siehe writing-idempotent-transformations).
Arbeitsablauf
- [ ] BESTÄTIGE, dass die Transformation idempotent ist (erneutes Ausführen == einmaliges Ausführen), BEVOR der Backfill startet
- [ ] DEFINIERE das exakte Fenster und die Partitionsgranularität
- [ ] FÜHRE EINEN PROBELAUF für eine Partition durch; überprüfe Zählwerte/Summen mit der Quelle
- [ ] FÜHRE Partition für Partition aus (begrenzte Parallelität), nicht alles auf einmal
- [ ] ISOLIERE die Backfill-Infrastruktur von Produktions-Workloads
- [ ] ÜBERPRÜFE Gesamtsummen und gleiche ab; setze dann die normale Planung fort
- Beweise zuerst die Idempotenz. Wenn erneutes Ausführen eines Fensters die Ergebnisse ändern kann, behebe dies, BEVOR du die Historie berührst. Ein Backfill eines nicht-idempotenten Jobs vervielfacht die Daten.
- Grenze präzise ein. Exakter Start/Ende und die Partitionseinheit (Tag/Stunde/Region).
- Führe einen Probelauf für eine Partition durch und gleiche mit der Quelle ab, bevor du skalierst.
- Teile den Lauf auf. Verarbeite Partitionen in begrenzten Batches, damit du überwachen, pausieren und fortsetzen kannst – niemals ein einziger riesiger, unbegrenzter Job.
- Isoliere die Infrastruktur. Verwende einen separaten Warehouse/Cluster/Pool, damit der Backfill keine Produktions-SLAs aushungert.
- Überprüfe + setze fort. Gleiche Gesamtsummen über den Backfill-Bereich ab, übergib dann an den normalen Plan.
Muster
Idempotenter, partitionsweiser Backfill – jede Partitionsüberschreibung ist unabhängig und sicher wiederholbar:
# Begrenzte Parallelität, ein Tag nach dem anderen; jeder Tag überschreibt seine eigene Partition.
for day in $(seq_dates 2026-01-01 2026-01-31); do
run_transform --run-date "$day" # delete-insert / MERGE nur für diesen Tag
done
Airflow – catchup/backfill wiederholt Intervalle; nur sicher, wenn Tasks idempotent und durch das Datenintervall parametrisiert sind. dbt – filtere das inkrementelle Modell auf das Zielfenster oder führe --full-refresh für ein begrenztes Fenster durch.
Isolieren + drosseln – dedizierter Warehouse/Cluster und eine Nebenläufigkeitsbegrenzung, damit der Backfill keine Live-Dashboards beeinträchtigen kann.
Häufige Fallstricke
- Backfill eines nicht-idempotenten Jobs – Duplikate oder verschobene Summen; mache ihn zuerst idempotent.
- Ein riesiger, unbegrenzter Lauf – kein Überwachen oder Fortsetzen möglich und überlastet die Produktion; gehe Partition für Partition vor.
- Gemeinsame Nutzung der Produktionsinfrastruktur – Backfills verursachen Lastspitzen und verletzen SLAs; isolieren.
- Keine Überprüfung – Annahme des Erfolgs; gleiche Zählwerte/Summen über den Bereich ab.
- Änderung der Logik während des Backfills – inkonsistente Historie; fixiere die Code-Version für den gesamten Lauf.
- Vergessen nachgelagerter Prozesse – Backfill einer Basistabelle ohne Aktualisierung abhängiger Data Marts/Aggregationen hinterlässt Inkonsistenzen.