CommunityRecherche & Datenanalysegithub.com

Backfills und Replays entwerfen

Plane und führe sichere Daten-Backfills und Replays durch – idempotente Neuverarbeitung historischer Fenster, partitionenweise Ausführung, Isolierung der Backfill-Infrastruktur von der Produktion, Verifikation der Ergebnisse und Vermeidung von Doppelzählungen oder geänderter Historie. Verwende dies, wenn ein neues oder korrigiertes Modell befüllt, nach einem Fehler erneut verarbeitet, Events wiederholt oder die Historie für eine neue Pipeline geladen wird, ohne bestehende Daten zu korrumpieren.

Was ist Backfills und Replays entwerfen?

Diese Fähigkeit beschreibt eine methodische Vorgehensweise für Backfills und Replays in der Datenverarbeitung. Sie betont unbedingte Idempotenz als Grundvoraussetzung: Ein erneutes Ausführen darf nicht zu anderen Ergebnissen führen als eine einmalige Ausführung. Der Workflow ist partitionenweise, mit strikter Isolierung der Ressourcen (eigener Warehouse/Cluster), um Produktions-SLAs nicht zu beeinträchtigen. Die Unterstützung umfasst generische Skripte sowie spezifisch Airflow (catchup/backfill mit idempotenten Tasks) und dbt (inkrementelle Filter oder --full-refresh mit begrenztem Fenster). Typische Fallstricke wie Doppelzählungen, unbegrenzte Einzelläufe oder fehlende Downstream-Aktualisierung werden klar adressiert. Ziel ist ein langweiliger, wiederholbarer Prozess, der die Datenhistorie sicher und nachvollziehbar verändert.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Unknown-333/awesome-data-engineering-skills/tree/main/skills/designing-backfills-and-replays

Installed? Explore more Recherche & Datenanalyse skills: affaan-m/uspto-database, affaan-m/scholar-evaluation, affaan-m/literature-review · View all 6 →

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

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
  1. 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.
  2. Grenze präzise ein. Exakter Start/Ende und die Partitionseinheit (Tag/Stunde/Region).
  3. Führe einen Probelauf für eine Partition durch und gleiche mit der Quelle ab, bevor du skalierst.
  4. Teile den Lauf auf. Verarbeite Partitionen in begrenzten Batches, damit du überwachen, pausieren und fortsetzen kannst – niemals ein einziger riesiger, unbegrenzter Job.
  5. Isoliere die Infrastruktur. Verwende einen separaten Warehouse/Cluster/Pool, damit der Backfill keine Produktions-SLAs aushungert.
  6. Ü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.

Individual skills in this repo

This repo contains 9 individual skills — each has its own dedicated page.

Unknown-333/authoring-airflow-dags

Write production-grade Apache Airflow DAGs using the TaskFlow API — idempotent tasks, correct scheduling and catchup, retries/SLAs, connections/variables, and avoiding top-level code. Use when creating or reviewing Airflow DAGs, scheduling pipelines, wiring task dependencies, configuring retries/backfills, or fixing non-idempotent tasks.

Unknown-333/building-dagster-assets

Build Dagster pipelines using software-defined assets — asset dependencies, partitions, resources and IO managers, asset checks, and schedules/sensors. Use when creating Dagster assets or jobs, modeling data as assets, adding partitions or backfills, wiring resources/IO managers, or migrating from task-based orchestration to assets.

Unknown-333/building-dbt-models

Build well-structured dbt models — staging/intermediate/marts layers, ref() and source(), materializations, and incremental models with the right strategy. Use when creating or refactoring dbt models, choosing table vs view vs incremental, structuring a dbt project, or writing incremental logic.

Unknown-333/building-feature-pipelines

Build ML feature pipelines and feature stores — point-in-time-correct joins to avoid label leakage, offline/online parity, feature freshness and backfills, and materialization with tools like Feast. Use when engineering features for ML, preventing train/serve skew or data leakage, building a feature store, or backfilling historical features for training.

Unknown-333/building-iceberg-tables

Design and operate Apache Iceberg tables — partitioning and hidden partitioning, partition/schema evolution, snapshots and time travel, compaction and small-file cleanup, and MERGE/upsert for lakehouse tables on Spark, Flink, Trino, or Snowflake. Use when creating or maintaining Iceberg tables, choosing partitioning, evolving schema/partitions, or fixing small-file and metadata bloat.

Unknown-333/building-ingestion-pipelines

Build batch and incremental data ingestion (extract-load) pipelines — full vs incremental extraction, change data capture (CDC), watermarks and high-water marks, API pagination and rate limits, and choosing managed EL tools (Fivetran, Airbyte) vs custom code. Use when ingesting data from databases, APIs, files, or SaaS into a warehouse/lake, or designing incremental extraction and CDC.

Unknown-333/building-kafka-consumers

Build reliable Apache Kafka consumers and producers — consumer groups and partition assignment, offset commit strategy, at-least-once vs exactly-once, idempotent/transactional producers, rebalancing, and dead-letter handling. Use when writing Kafka consumers/producers, configuring offset commits or consumer groups, tuning throughput, or handling rebalances and poison messages.

Unknown-333/debugging-data-pipelines

Systematically root-cause data pipeline failures and data incidents — job errors, wrong or missing data, duplicates, and freshness misses — by tracing lineage upstream, isolating the failing stage, reconciling against source, and planning a safe fix and backfill. Use when a pipeline fails, numbers look wrong, data is missing or duplicated, a dashboard is stale, or a stakeholder reports a data discrepancy.

Unknown-333/designing-data-contracts

Define and enforce data contracts between producers and consumers — explicit schema, semantics, ownership, SLAs, and versioning — to prevent silent upstream changes from breaking downstream pipelines. Use when a producer schema change could break consumers, defining an interface between teams/services and the warehouse, or adding schema enforcement at ingestion.

Verwandte Skills