Débogage de Pipelines de Données

Que fait Débogage de Pipelines de Données ?

Quand l'utiliser

• Un job de pipeline a échoué, ou les données de sortie sont erronées/manquantes/dupliquées.
• Un tableau de bord est obsolète ou une métrique ne correspond pas à la source.
• Une partie prenante signale une divergence et vous devez en trouver la cause.
• NE PAS l'utiliser pour les erreurs d'exécution spécifiques à un outil déjà couvertes par debugging-dbt-runs / debugging-airflow-pipelines (commencez par celles-ci, puis utilisez celle-ci pour les incidents de correction des données).

Workflow

- [ ] Définir précisément le symptôme (quelle table, colonne, lignes, fenêtre temporelle)
- [ ] Retracer la lignée en amont pour trouver la première étape où les données sont erronées
- [ ] Isoler : est-ce un bug de code, une mauvaise entrée, des données tardives, ou un échec d'exécution ?
- [ ] Rapprocher l'étape suspecte de sa source (comptages/sommes)
- [ ] Corriger la cause racine, puis planifier un rattrapage idempotent des fenêtres affectées
- [ ] Ajouter une vérification pour que cela ne puisse pas se reproduire silencieusement

1. Identifier le symptôme. « Le revenu du 2026-01-15 est ~30 % plus bas dans fct_orders » est débogable ; « les nombres semblent erronés » ne l'est pas. Obtenez la table, la colonne, les lignes et la fenêtre.
2. Retracer la lignée en amont. Parcourez la sortie erronée en arrière à travers les modèles/ tâches pour trouver la première étape où les données sont déjà erronées. Recherchez binairement le DAG plutôt que de lire chaque étape.
3. Classifier la cause : changement de code, données source erronées/tardives, échec d'exécution partiel, ou doublon non idempotent.
4. Rapprocher l'étape suspecte de son entrée (comptages de lignes, comptages de clés, sommes) pour confirmer où apparaît l'écart.
5. Corriger + rattraper les fenêtres affectées de manière idempotente (voir designing-backfills-and-replays).
6. Prévenir la récurrence avec une vérification ciblée de la qualité des données.

Modèles

Recherche binaire de lignée — vérifiez une étape à mi-chemin du DAG : si ses données sont correctes, le bug est en aval ; si erronées, remontez plus haut. Répétez.

Rapprochement source vs cible pour la fenêtre affectée :

-- Les comptages/sommes correspondent-ils entre l'étape et son entrée pour la mauvaise fenêtre ?
SELECT 'source' AS couche, COUNT(*) n, SUM(montant) total
FROM staging.commandes WHERE date_commande = DATE '2026-01-15'
UNION ALL
SELECT 'cible', COUNT(*), SUM(montant)
FROM marts.fct_commandes WHERE date_commande = DATE '2026-01-15';

Un écart de comptage → lignes supprimées/filtrées ou un chargement partiel échoué. Un écart de somme avec des comptages égaux → un bug de transformation/logique. Un comptage cible plus élevé → duplication (chargement non idempotent).

Vérification temporelle — corrélez la fenêtre de l'incident avec les déploiements, les changements de schéma source et l'historique des exécutions ; la plupart des incidents commencent par un changement.

Pièges courants

• Corriger les symptômes en aval — corriger la vue matérialisée alors que le bug est dans la préparation signifie qu'il se reproduira ; corrigez la première étape erronée.
• Correctifs manuels uniques aux données de production — non vérifiables et non reproductibles ; corrigez le code et réexécutez de manière idempotente.
• Lire le DAG entier linéairement — utilisez plutôt la recherche binaire de lignée.
• Sauter le rapprochement — deviner où les données divergent fait perdre du temps ; mesurez les comptages/sommes par étape.
• Aucune vérification préventive après la correction — la même classe de bug revient incognito.