Les packages dbt : installer dbt_utils et réutiliser le code de la communauté

Dans l'article précédent, on a écrit nos propres macros, et on a fini sur le fait qu'il faut avant d'écrire une macro, vérifier si quelqu'un ne l'a pas déjà faite. C'est exactement le rôle des packages.

Un package, c'est du code dbt prêt à l'emploi, publié par la communauté et il y a des centaines de macros et de tests déjà écrits, testés et maintenus. On va voir comment, à commencer par le plus connu, dbt_utils.

C'est quoi un package dbt

Un package dbt, c'est un projet dbt qu'on importe dans le sien. Il apporte surtout des macros et des tests génériques réutilisables, parfois des modèles. C'est le même principe que pip pour Python ou npm pour JavaScript car on déclare une dépendance, l'outil la télécharge, et on l'utilise comme si c'était son propre code.

Installer ton premier package

Crée un fichier packages.yml à la racine de ton projet (au même niveau que dbt_project.yml) :

packages:
  - package: dbt-labs/dbt_utils
    version: [">=1.1.0", "<2.0.0"]

Puis télécharge la dépendance :

dbt deps

dbt récupère le package et le place dans le dossier dbt_packages/. À partir de là, toutes ses macros et ses tests sont disponibles dans ton projet.

le package dbt_utils

dbt_utils est le package que tout le monde installe en premier. Il regroupe les outils qui manquent à dbt en standard. Quelques classiques :

• generate_surrogate_key : Créer une clé technique stable à partir de plusieurs colonnes
• star : Sélectionner toutes les colonnes d'une table sauf celles qu'on exclut
• get_column_values : Récupérer les valeurs distinctes d'une colonne (utile dans une boucle)
• date_spine : Générer une table de dates continue
• union_relations : Empiler plusieurs tables de structures proches

Il apporte aussi des tests génériques qu'on n'a pas en standard, comme vérifier qu'une valeur est dans une plage, ou qu'une combinaison de colonnes est unique.

Utiliser une macro de package

Prenons generate_surrogate_key. Dans un DW, on veut souvent une clé technique unique par ligne, calculée à partir des colonnes métier. Plutôt que de trimballer une clé composite, on la hache en une seule valeur stable.

Dans mart_orders.sql, ajoute la clé en haut du select :

{{ dbt_utils.generate_surrogate_key(['order_id', 'customer_id']) }} as order_key

dbt compile ça en un md5(...) propre qui combine les deux colonnes. La clé est stable donc tant que order_id et customer_id ne changent pas, la clé reste la même d'une exécution à l'autre. On l'utilise comme identifiant technique de la ligne, sans s'embêter avec une clé sur plusieurs colonnes.

Utiliser un test de package

dbt_utils ne sert pas qu'aux macros, il apporte aussi des tests. Reprenons le fichier models.yml des tests. Au niveau de stg_orders on veut vérifier que le montant d'une commande n'est jamais négatif. Le test accepted_range de dbt_utils fait ça :

      - name: montant
        data_tests:
          - dbt_utils.accepted_range:
              arguments:
                min_value: 0

Au prochain dbt test, dbt va vérifier qu'aucun montant n'est en dessous de zéro.

Aller plus loin avec le package dbt_expectations

Si tu veux pousser la qualité de données, le package dbt_expectations est l'étape suivante. Inspiré de la bibliothèque Great Expectations, il apporte des dizaines de tests prêts à l'emploi pour vérifier par exemple qu'une valeur est entre deux bornes, qu'une colonne respecte un format, qu'une distribution reste dans des limites, etc... etc...

Il s'installe exactement comme dbt_utils, en l'ajoutant à packages.yml puis en relançant dbt deps.

Quelques bonnes pratiques

Trois réflexes pour ne pas transformer tes dépendances en problème et dette technique dans le futur

• N'installe pas tout ce qui brille. Chaque package est une dépendance à suivre et à mettre à jour. Installe dbt_utils les yeux fermés, mais le reste seulement quand un vrai besoin se présente et que ce n'est pas possible de faire autrement.
• Versionne avec une fourchette et relance dbt deps après chaque clone du projet et dans ta CI, sinon les macros des packages sont introuvables.
• Commit packages.yml et package-lock.yml, mais ne commit jamais le dossier dbt_packages/.

La suite ?

Récap. de cet article

• Comprendre qu'un package, c'est du code dbt réutilisable publié par la communauté, façon pip ou npm,
• Installer dbt_utils avec packages.yml et dbt deps,
• Utiliser une macro de package, generate_surrogate_key, pour créer une clé technique stable,
• Ajouter un test de package, accepted_range, sur le montant,
• Voir que dbt_expectations prend le relais pour la qualité de données avancée.

Dans le prochain article, on monte d'un cran côté gouvernance avec les model contracts, les accès et les grants.

Aller plus loin

Cet article fait partie de la formation dbt complète, du premier modèle au déploiement en production.

👉 Suivre toute la formation dbt

dbt tourne sur Snowflake dans ce parcours. Pour maîtriser le socle (warehouses, rôles, ingestion) :

👉 Accéder à la Formation Snowflake

Et pour t'entraîner en conditions d'examen, la certification dbt Analytics Engineering teste précisément les packages et dbt_utils.

👉 Préparer la certification dbt sur DataCertification.fr

Tu veux que je t'accompagne sur ton projet data (Snowflake, dbt, modélisation, industrialisation) ?

👉 Réserver un appel de 30 minutes

Questions fréquentes