Aller au contenu

Backfill

Status: TARGET

À quoi sert un Backfill Write Service ?

Un Backfill Write Service complète des données déjà existantes lorsque de nouvelles règles, colonnes, projections ou enrichissements doivent être appliqués à l'historique.

Le backfill sert donc à remettre l'ancien stock de données au niveau du modèle courant. Il ne remplace pas le Pipeline normal : si une donnée doit être produite à chaque nouvelle ingestion, la règle doit exister dans le flux normal et le backfill ne sert qu'à traiter l'historique.

Règle désormais disponible
          ↓
Population historique à compléter
          ↓
Backfill ciblé
          ↓
Contrôles et audit après écriture

État documentaire

Cette page décrit la cible d'architecture de la famille Backfill.

Elle ne prouve pas qu'un backfill générique est actuellement actif dans le Runtime. Avant toute exécution, vérifier le service, la commande et le périmètre réellement implémentés dans le dépôt.

Entrées attendues

Un backfill doit identifier explicitement :

  • le champ, la projection ou l'information à compléter ;
  • la population cible ;
  • le run, feed, verticale ou intervalle concerné ;
  • la règle source qui produit la nouvelle valeur ;
  • les préconditions ;
  • les exclusions ;
  • la stratégie de reprise.

Un backfill sans périmètre borné est une opération à haut risque.

Sorties attendues

Le rapport d'exécution doit distinguer au minimum :

  • lignes examinées ;
  • lignes déjà complètes ;
  • lignes enrichies ;
  • lignes ignorées ;
  • lignes en échec ;
  • raisons d'ignorance ou d'échec ;
  • progression du batch ou offset lorsque l'opération est volumineuse.

Les compteurs doivent être réconciliables.

Ce qu'un backfill ne doit jamais faire

Un backfill ne doit jamais :

  • corriger silencieusement une autre anomalie au passage ;
  • inventer une valeur lorsque l'information source manque ;
  • transformer unknown, ambiguous ou conflict en valeur certaine sans preuve ;
  • modifier une identité métier si son objet est seulement de compléter une projection ;
  • dépendre d'un ordre SQL accidentel ;
  • relancer toute la plateforme sans nécessité ;
  • être confondu avec une migration de schéma.

Idempotence et reprise

Un backfill industriel doit pouvoir être interrompu puis repris.

Le rejeu d'un même lot ne doit pas dupliquer les effets. Il faut pouvoir distinguer :

examined
= already_complete
+ changed
+ skipped
+ failed

Pour les gros volumes, utiliser un identifiant de batch, un offset, une clé métier ou un autre mécanisme stable de reprise.

Intervention sans risque

Avant exécution :

  1. auditer la population à compléter ;
  2. mesurer combien de lignes sont réellement éligibles ;
  3. tester un petit périmètre représentatif ;
  4. vérifier le dry-run s'il existe ;
  5. prévoir reprise et rollback ;
  6. annoncer clairement l'opération comme écriture.

Après exécution, mesurer la complétude et vérifier qu'aucune population non ciblée n'a changé.

Erreurs fréquentes

Les erreurs les plus dangereuses sont :

  • utiliser NULL comme seul critère sans vérifier sa sémantique ;
  • recalculer une valeur avec une règle différente de celle du Pipeline courant ;
  • écraser une valeur existante au lieu de compléter seulement les absences ;
  • ne pas différencier « impossible à calculer » et « erreur technique » ;
  • exécuter le backfill sans connaître le nombre de lignes attendu.

Tests attendus

Une implémentation concrète doit tester :

  • les lignes déjà complètes ;
  • les lignes éligibles ;
  • les données insuffisantes ;
  • l'idempotence ;
  • la reprise ;
  • le respect du périmètre ;
  • la réconciliation des compteurs ;
  • l'absence d'écrasement d'une donnée valide.

Invariants

  1. Le backfill traite l'historique ; le flux normal reste responsable des nouvelles données.
  2. Aucune valeur n'est inventée faute de preuve.
  3. Le périmètre et les critères d'éligibilité sont explicites.
  4. Le rejeu ne doit pas dupliquer les effets.
  5. L'opération est mesurable, reprenable et vérifiée après exécution.

Voir aussi