Vérifications de qualité des données : fraîcheur, volume, valeurs nulles et unicité comme socle minimal

Objectif

Détecter un chargement incomplet, en retard, dupliqué ou dépourvu de clés au niveau de la table qui est défaillante — dans le délai d'un intervalle et avant que quelqu'un ne construise un rapport dessus.

Prérequis

Chaque table possède une granularité déclarée (ce que signifie une ligne) et une colonne d'horodatage de chargement ou une partition. La documentation de dbt modélise une vérification comme un SELECT qui renvoie les enregistrements fautifs — zéro ligne signifie réussi — et fournit les tests génériques not_null, unique, accepted_values et relationships ; pour les sources, la fraîcheur peut se configurer via loaded_at_field avec les seuils warn_after et error_after. Qui travaille sans dbt écrit les quatre mêmes règles en SQL dans son propre ordonnanceur ; dans la base de données elle-même, les contraintes NOT NULL, UNIQUE et FOREIGN KEY documentées par PostgreSQL en couvrent une partie de façon durable.

Étapes

1. Fraîcheur : noter, pour chaque source, la cadence de chargement attendue, fixer un seuil d'avertissement juste au-dessus et un seuil d'erreur là où le rapport en aval deviendrait faux ; vérifier max(geladen_am) par rapport à l'horloge au moment de l'exécution.
2. Volume : comparer le nombre de lignes de l'intervalle qui vient d'être chargé avec les mêmes intervalles de périodes antérieures (pour des chargements quotidiens, le même jour de la semaine) ; stocker les valeurs de comptage dans une petite table d'historique, commencer avec une plage large et la resserrer après quelques semaines d'observation.
3. Valeurs nulles : NOT NULL sur les clés primaires et étrangères, sur le temps de partitionnement et sur les indicateurs que les rapports totalisent ; pour les attributs optionnels, suivre à la place le taux de valeurs nulles dans le temps.
4. Unicité : les colonnes de la granularité doivent être uniques. Un doublon est une répétition de la source, une jointure qui s'éparpille (fan-out), ou une nouvelle exécution qui a ajouté au lieu de remplacer.
5. Ordre : exécuter les vérifications après le chargement et avant l'étape qui rend la table visible (bascule de vue, libération de partition), afin qu'un échec de niveau « error » arrête la publication et que « warn » ne fasse que signaler.
6. Enregistrer chaque résultat — y compris ceux qui réussissent — avec un horodatage, et transmettre les échecs, avec les lignes concernées, à la personne responsable de la table ; les vérifications instables deviennent ainsi visibles.

Résultat attendu

Un chargement qui arrive en retard, à moitié, en double ou avec des clés perdues est signalé à l'endroit de la rupture, avant de se propager.

Limites et base de vérification

Les quatre vérifications trouvent des ruptures structurelles, pas des valeurs fausses mais bien formées ; les rapprochements avec le système source (les sommes concordent) viennent ensuite. Des bandes de volume sans connaissance de la saisonnalité se déclenchent à chaque jour férié. Cet ensemble est une proposition fondée sur la documentation citée ; aucun taux de détection n'est revendiqué.