ServicesÀ proposNotesContact Me contacter →
EN FR
Note

Installation et configuration de dbt-expectations

Comment installer et configurer dbt-expectations — packages.yml, variable timezone, compatibilité des plateformes et gestion des dépendances.

Planté
dbtdata qualitytesting

dbt-expectations est un package communautaire qui apporte plus de 50 tests de qualité des données pré-construits à tout projet dbt. Il a été porté depuis la bibliothèque Python Great Expectations et est maintenant maintenu par Metaplane. Là où les quatre tests génériques natifs de dbt (unique, not_null, accepted_values, relationships) couvrent les bases structurelles, dbt-expectations comble les lacunes : correspondance de patterns, validation statistique, vérifications de fraîcheur sur n’importe quel modèle, tests multi-colonnes et filtrage conditionnel.

Installation

Ajoutez le package à votre packages.yml avec une plage de version épinglée :

packages:
- package: metaplane/dbt_expectations
version: [">=0.10.0", "<0.11.0"]

L’épinglage par plage de version (>=0.10.0, <0.11.0) est important. Épingler à une version exacte signifie manquer les corrections de bugs. Utiliser une plage non bornée risque d’introduire des changements incompatibles. La plage épinglée vous permet d’obtenir les patches tout en vous protégeant contre les changements de version majeure.

Configuration du fuseau horaire

dbt-expectations nécessite une variable de fuseau horaire pour tout test basé sur les dates. Sans cela, les tests comme expect_row_values_to_have_recent_data échoueront avec une erreur de compilation obscure plutôt qu’un message clair indiquant une variable manquante.

Ajoutez ceci à votre dbt_project.yml :

vars:
'dbt_date:time_zone': 'Europe/Paris'

Utilisez le nom de fuseau horaire IANA correspondant à votre contexte métier. Pour une entreprise basée aux États-Unis, 'America/New_York' ou 'America/Los_Angeles'. Pour les équipes qui travaillent en UTC, 'UTC'. Cette variable alimente le package dbt-date sous-jacent, dont dbt-expectations dépend pour toute la logique temporelle.

Dépendances

L’exécution de dbt deps après l’ajout du package récupère automatiquement deux dépendances transitives :

  • dbt-date — macros utilitaires de dates (date spines, gestion des fuseaux horaires, génération de calendrier)
  • dbt-utils — le package utilitaire dbt standard (si vous ne l’avez pas déjà)

Il n’est pas nécessaire de les déclarer séparément dans votre packages.yml. Si vous avez déjà dbt-utils épinglé à une version spécifique, vérifiez que la plage de version est compatible avec ce que dbt-expectations requiert. Les conflits de version entre les plages de dbt-utils sont la cause la plus fréquente d’échec de dbt deps lors de l’ajout de dbt-expectations à un projet existant.

Support des plateformes

dbt-expectations requiert dbt 1.8 ou supérieur et supporte entièrement :

  • BigQuery
  • Snowflake
  • Postgres
  • Redshift
  • DuckDB
  • Trino

La plupart des tests fonctionnent de manière identique sur toutes les plateformes. Les exceptions concernent les tests de gestion des dates où les différences de dialecte SQL (le DATE_SUB de BigQuery vs le DATEADD de Snowflake) sont abstraites par les macros internes du package. Vous écrivez le même YAML quel que soit l’entrepôt.

Vérification de l’installation

Après dbt deps, la manière la plus rapide de vérifier que tout fonctionne est d’ajouter un seul test à votre modèle le plus critique et de l’exécuter :

models:
- name: your_most_important_mart
columns:
- name: created_at
tests:
- dbt_expectations.expect_row_values_to_have_recent_data:
datepart: hour
interval: 48

Exécutez dbt test --select your_most_important_mart et confirmez que le test se compile et s’exécute. Si vous obtenez une erreur de compilation à propos de variables manquantes, la configuration du fuseau horaire est absente. Si vous obtenez une erreur de dépendance, relancez dbt deps.

Ce que vous obtenez

Avec le package installé, vous avez accès à des tests dans plusieurs catégories :

  • Tests au niveau de la table — validation du nombre de lignes, vérifications de fraîcheur, comparaisons inter-tables
  • Validation de patterns — correspondance regex et LIKE pour l’application des formats
  • Validation des plages de valeurs — bornes individuelles et vérifications de distribution statistique
  • Validation multi-colonnes — unicité de clé composite et règles métier inter-colonnes
  • Tests d’exhaustivité — détection de lacunes dans les séries temporelles et vérification de couverture des données

Consultez la référence des tests dbt-expectations pour le catalogue complet avec des exemples de code, et le paramètre row_condition pour le filtrage conditionnel qui fonctionne sur presque tous ces tests.

La place de dbt-expectations

dbt-expectations occupe la couche « violations de domaine connues » dans une stratégie de qualité des données. Il détecte les problèmes que vous pouvez anticiper et pour lesquels vous pouvez définir des règles. Il ne remplace pas les tests génériques natifs (qui gèrent la validation structurelle) ni Elementary (qui gère la détection d’anomalies). Les trois fonctionnent ensemble :

CoucheOutilQuestion à laquelle il répond
Validation structurelleTests génériques dbtLes clés primaires sont-elles uniques ? Les clés étrangères sont-elles valides ?
Validation de domainedbt-expectationsLes valeurs sont-elles dans les plages attendues ? Les formats correspondent-ils ? Les données sont-elles fraîches ?
Détection d’anomaliesElementaryQuelque chose a-t-il changé de manière inattendue par rapport aux patterns historiques ?

En termes de séquence de mise en place : dbt-expectations est un ajout naturel après que les tests génériques de base sont en place, couvrant la validation de domaine que les tests génériques ne peuvent pas exprimer.