dbt-expectations est un package communautaire (maintenu par Metaplane) qui apporte 50+ tests de qualité de données préconstruits à dbt. Il comble l’écart entre les quatre tests génériques intégrés de dbt et les outils de détection d’anomalies complets comme Elementary. Là où dbt natif gère la validation structurelle (unique, not_null, relationships, accepted_values), dbt-expectations gère la validation de domaine : correspondance de patterns, plages de valeurs, vérifications statistiques, fraîcheur sur n’importe quel modèle, assertions multi-colonnes, et complétude des séries temporelles.
Notes principales
-
Configuration de dbt-expectations — Installation via
packages.yml, la variable de fuseau horaire requise, les dépendances transitives (dbt-date, dbt-utils), le support des plateformes (BigQuery, Snowflake, Postgres, Redshift, DuckDB, Trino), et la vérification de l’installation. -
Référence des tests dbt-expectations — Référence catégorisée des tests à plus haute valeur avec des exemples YAML prêts pour BigQuery. Tests au niveau des tables (fraîcheur, nombres de lignes), validation de patterns (regex, LIKE), vérifications de plage de valeurs (au niveau des lignes et statistiques), validation multi-colonnes (clés composites, comparaisons inter-colonnes), et tests de complétude (détection de lacunes dans les séries temporelles).
-
Pattern row_condition de dbt-expectations — Le paramètre
row_conditionqui fonctionne dans presque tous les tests du package. Filtrage conditionnel pour les champs nullables, validation basée sur le statut, plages spécifiques aux segments, et optimisation des performances compatible avec les partitions. Un paramètre qui élimine le besoin de dizaines de tests singuliers personnalisés. -
Sévérité et optimisation des performances des tests dbt — Configuration de la sévérité
warnvserrorpar catégorie de test, optimisation des coûts spécifique à BigQuery (filtrage des partitions, tests prod uniquement, planification par tag), placement des tests par couche DAG, et un point de départ pratique de « trois premiers tests ». -
Patterns d’implémentation dbt-expectations sur BigQuery — Implémentation réelle avec YAML complet pour les événements GA4 et la performance publicitaire. Placement des tests par couche DAG (base, intermédiaire, mart), patterns compatibles avec les partitions pour le contrôle des coûts BigQuery, et une checklist d’expansion priorisée pour augmenter la couverture des tests.
-
Tests unitaires vs tests de données dans dbt — Le modèle à deux points de contrôle : les tests unitaires ferment les déploiements en vérifiant la logique de transformation avec des données simulées, les tests de données ferment la production en vérifiant la santé des données réelles. Pourquoi vous avez besoin des deux, ce que chacun capture que l’autre manque, et des orientations pratiques sur par où commencer.
Sujets connexes
-
Taxonomie des tests dbt — La taxonomie complète des types de tests dbt. dbt-expectations se situe aux côtés des tests génériques, des tests singuliers, des tests unitaires, des contrats de modèles, et d’Elementary dans une stratégie de test en couches.
-
Validation sémantique dans dbt — La catégorie plus large de validation des règles métier que dbt-expectations permet : patterns regex, vérifications de plage, logique inter-colonnes, et validation assistée par IA.
-
Couches de validation de la qualité des données — Le modèle à trois couches (contrats, tests, détection d’anomalies) où dbt-expectations occupe la couche de validation réactive aux côtés des tests natifs de dbt.
Connexions
dbt-expectations occupe la couche des « violations de domaine connues » dans une stratégie de qualité des données. Il capture les problèmes que vous pouvez anticiper et pour lesquels vous pouvez écrire des règles. Pour les problèmes que vous ne pouvez pas anticiper, Elementary fournit la détection d’anomalies. Pour les garanties structurelles au niveau du schéma, les contrats de modèles empêchent les changements cassants avant que les données ne soient matérialisées. Pour la validation de migration, dbt-audit-helper compare deux relations pour prouver leur équivalence.