Conception de backfills et replays

Que fait Conception de backfills et replays ?

Quand l'utiliser

• Charger l'historique pour un nouveau modèle/pipeline.
• Retraiter des fenêtres passées après avoir corrigé un bug de transformation.
• Rejouer des événements ou redériver une table à partir des données brutes.
• Ne PAS l'utiliser pour les exécutions incrémentales normales (utilisez building-dbt-models / authoring-airflow-dags).

Pourquoi il mérite de l'attention

Les backfills sont l'opération routinière la plus dangereuse en data engineering : ils réécrivent l'historique. Mal faits, ils doublent les comptes, changent les chiffres de la veille ou surchargent la production. Bien faits, ils sont ennuyeux et reproductibles. Le prérequis est l'idempotence (voir writing-idempotent-transformations).

Workflow

- [ ] Confirmer que la transformation est idempotente (relancer == exécuter une fois) AVANT le backfill
- [ ] Définir la fenêtre exacte et la granularité de partition
- [ ] Tester à sec une partition ; vérifier les comptes/sommes par rapport à la source
- [ ] Exécuter partition par partition (parallélisme borné), pas tout d'un coup
- [ ] Isoler le calcul de backfill des charges de travail de production
- [ ] Vérifier les totaux et réconcilier ; puis reprendre la planification normale

1. Prouver l'idempotence d'abord. Si relancer une fenêtre peut changer les résultats, corrigez cela avant de toucher à l'historique. Backfiller un job non idempotent multiplie les données.
2. Délimiter précisément. Date de début et de fin exactes, et l'unité de partition (jour/heure/région).
3. Tester à sec une partition et réconcilier avec la source avant de passer à l'échelle.
4. Découper l'exécution. Traiter les partitions par lots bornés pour pouvoir surveiller, mettre en pause et reprendre — jamais un seul job géant non borné.
5. Isoler le calcul. Utiliser un entrepôt/cluster/pool séparé pour que le backfill n'affame pas les SLA de production.
6. Vérifier + reprendre. Réconcilier les totaux sur la plage backfillée, puis rendre la main à la planification normale.

Patterns

Backfill idempotent par partition — chaque remplacement de partition est indépendant et sûr à relancer :

# Parallélisme borné, un jour à la fois ; chaque jour écrase sa propre partition.
for day in $(seq_dates 2026-01-01 2026-01-31); do
  run_transform --run-date "$day"   # delete-insert / MERGE pour ce jour uniquement
done

Airflow — catchup/backfill relance des intervalles ; sûr uniquement si les tâches sont idempotentes et paramétrées par l'intervalle de données. dbt — filtrer le modèle incrémental sur la fenêtre cible, ou --full-refresh une fenêtre bornée.

Isoler + limiter — entrepôt/cluster dédié et un plafond de concurrence pour que le backfill ne puisse pas dégrader les tableaux de bord en production.

Pièges courants

• Backfiller un job non idempotent — doublons ou totaux changeants ; rendez-le idempotent d'abord.
• Un seul job géant non borné — impossible à surveiller ou reprendre, et il surcharge la production ; allez partition par partition.
• Partager le calcul de production — les backfills font monter la charge et explosent les SLA ; isolez.
• Pas de vérification — supposer le succès ; réconciliez les comptes/sommes sur la plage.
• Changer la logique en cours de backfill — historique incohérent ; figez la version du code pour toute l'exécution.
• Oublier les avals — backfiller une table de base sans rafraîchir les marts/agrégats dépendants les laisse incohérents.