Contrôles de qualité des données : fraîcheur, volume, valeurs nulles et unicité comme ensemble de tests minimal

Objectif

Détecter un chargement défaillant ou partiel avant que quiconque ne construise un rapport dessus, avec des contrôles assez peu coûteux pour être exécutés à chaque intervalle, et assez précis pour qu'un échec nomme la table et la règle en cause.

Prérequis

Chaque table a un grain déclaré (ce que représente une ligne) et une colonne d'horodatage de chargement ou une partition. La documentation de dbt (citée) modélise un contrôle comme une instruction select qui renvoie les enregistrements en échec : zéro ligne signifie que l'assertion tient. Prêts à l'emploi, elle propose des contrôles not-null, unique, accepted-values et de relation (clé étrangère) par colonne, ainsi qu'une configuration de fraîcheur de source avec des seuils warn_after et error_after calculés à partir d'un loaded_at_field ; si aucun des deux seuils n'est fourni, la fraîcheur n'est pas calculée. Les quatre mêmes règles peuvent être écrites en SQL brut dans n'importe quel ordonnanceur.

Étapes

1. Fraîcheur : pour chaque table source, consigner la cadence de chargement attendue et fixer un seuil d'avertissement légèrement au-dessus, ainsi qu'un seuil d'erreur au point où le rapport en aval serait faux. Comparer max(loaded_at) à l'horloge au moment de l'exécution.
2. Volume : pour l'intervalle qui vient d'être chargé, compter les lignes et comparer avec le même intervalle des périodes précédentes (même jour de la semaine pour des chargements quotidiens). Stocker les comptages dans une petite table d'historique et signaler les comptages hors d'une bande définie à partir de cet historique ; commencer avec une bande large et la resserrer après quelques semaines d'observation.
3. Valeurs nulles : imposer la non-nullité sur les clés primaires et étrangères, sur l'horodatage utilisé pour le partitionnement, et sur les mesures que les rapports agrègent par somme. Ne pas imposer la non-nullité sur les attributs facultatifs ; suivre plutôt leur taux de valeurs nulles dans le temps.
4. Unicité : imposer que les colonnes formant le grain soient uniques. Un doublon ici provient soit d'une nouvelle tentative en amont, soit d'une jointure qui a proliféré, soit d'une réexécution qui a ajouté au lieu de remplacer.
5. Ordonner les contrôles après le chargement et avant l'étape qui publie la table aux consommateurs (échange de vue, promotion de partition), afin qu'un contrôle en échec au niveau erreur bloque la publication.
6. Acheminer chaque échec vers le propriétaire de la table, en joignant les lignes en échec, et consigner chaque résultat, y compris les réussites, afin de pouvoir identifier les contrôles instables (flapping).

Résultat attendu

Un chargement arrivant en retard, à moitié complet, doublé ou avec des clés perdues est signalé au niveau de la table défaillante, en l'espace d'un intervalle d'ordonnancement, avant de se propager.

Limites et base de vérification

Ces contrôles détectent des ruptures structurelles, pas des valeurs erronées mais bien formées ; les contrôles de règles métier (les totaux se recoupent avec le système source) viennent ensuite. Les bandes de volume ont besoin d'une prise en compte de la saisonnalité, sous peine de déclencher une alerte à chaque jour férié. Cet ensemble est un protocole proposé, dérivé de la documentation citée ; aucun taux de détection n'est revendiqué.