ARCHITECTURE

Data Build Tool (DBT) : de quoi parle-t-on ?

Marie de Vesvrotte
Responsable Marketing
21/12/2023
Sommaire

dbt (data build tool) est un outil open source de transformation de données qui permet de définir, tester et documenter des modèles SQL exécutés directement dans un entrepôt de données. Il ne stocke ni ne calcule les données lui-même : il pilote les transformations et en assure la traçabilité, la reproductibilité et le versionnage.

Qu’est-ce que Data Build Tool ?

DBT, ou Data Build Tool, est un outil open source utilisé dans le domaine de l'analyse de données et de la gestion des entrepôts de données. Il permet aux équipes d'analystes et de data scientists de structurer, documenter et exécuter des transformations de données de manière reproductible.

Les principales caractéristiques de dbt comprennent la possibilité de définir des modèles de transformation de données à l'aide de requêtes SQL, la gestion des dépendances entre ces modèles, la génération automatique de documentation basée sur le code, la modularité pour encourager la réutilisation des transformations, et la facilité de collaboration au sein des équipes travaillant sur des projets d'analyse de données. 

Il est souvent utilisé en conjonction avec des entrepôts de données modernes comme BigQuery, Snowflake, ou Redshift.

En utilisant dbt, il est possible de rationaliser le processus de construction de l’entrepôt de données (Data Warehouse), d’accélérer le développement de modèles analytiques et d'améliorer la cohérence et la qualité des données dans l'environnement d'analyse.

Comment fonctionne Data Build Tool ?

Data Build Tool (dbt) fonctionne en suivant un processus spécifique qui simplifie et organise les transformations de données dans un entrepôt de données. Voici un aperçu général du fonctionnement de dbt :

  • Modélisation des données : les transformations de données sont définies sous forme de modèles SQL. Ces modèles représentent des requêtes SQL qui transforment les données brutes en résultats souhaités, généralement stockés sous forme de tables ou de vues dans l'entrepôt de données.
  • Dépendances : dbt gère automatiquement les dépendances entre les différents modèles. Lorsqu'un modèle dépend d'un autre, dbt s'assure que les modèles sous-jacents sont exécutés en premier, garantissant ainsi l'ordre correct d'exécution des transformations.
  • Exécution : les modèles sont exécutés à l'aide de la commande dbt Run. Lorsque cette commande est lancée, dbt exécute les requêtes SQL correspondantes pour construire les tables ou les vues résultantes dans l'entrepôt de données.
  • Documentation automatique : dbt génère automatiquement de la documentation à partir des métadonnées incluses dans les modèles SQL. Cette documentation inclut des informations sur les colonnes, les types de données, les sources, et d'autres détails pertinents, facilitant la compréhension des transformations effectuées.
  • Tests : dbt prend en charge la création de tests automatisés pour vérifier la qualité des résultats produits par les transformations. Ces tests permettent de s'assurer que les données traitées répondent aux critères définis, offrant ainsi une assurance qualité.
  • Orchestration : dbt n'orchestre pas lui-même les flux de données. Il s'intègre à des orchestrateurs comme Airflow, Dagster ou Prefect, ou s'appuie sur les planifications natives de dbt Cloud, pour exécuter les modèles à intervalles définis.
  • Intégration avec les Data Warehouse : dbt s'intègre de manière transparente avec divers entrepôts de données modernes tels que BigQuery, Snowflake, Redshift, etc. Les requêtes SQL générées par dbt sont optimisées pour ces plateformes, exploitant ainsi au mieux leurs performances.

Pourquoi utiliser Data Build Tool ?

Data Build Tool (dbt) est utilisé pour simplifier et optimiser le processus de transformation des données. Son utilisation présente plusieurs avantages.

  • Reproductibilité des transformations : dbt permet de définir les transformations de données sous forme de modèles SQL, assurant ainsi une reproductibilité cohérente des résultats, ce qui est essentiel pour maintenir l'intégrité des analyses.
  • Gestion des dépendances : dbt permet de gérer les dépendances entre les différentes transformations de données. Cela signifie que si une transformation de base change, dbt peut automatiquement identifier et mettre à jour toutes les transformations qui en dépendent, simplifiant ainsi la maintenance du code.
  • Documentation automatique : dbt génère automatiquement une documentation à partir des modèles SQL, offrant une visibilité instantanée sur les transformations effectuées. Cela améliore la compréhension du code et facilite le partage des connaissances au sein de l'équipe.
  • Modularité et réutilisabilité : les transformations dans dbt sont structurées de manière modulaire, ce qui encourage la réutilisabilité du code. Les modèles peuvent être construits de manière à être utilisés dans différents projets, favorisant ainsi une approche cohérente et standardisée. 
  • Facilité de collaboration : en utilisant dbt, les membres de l'équipe peuvent collaborer plus facilement sur des projets d'analyse de données. La structure modulaire et la gestion des dépendances facilitent la collaboration entre les analystes et les data scientists.
  • Intégration avec les entrepôts de données modernes : dbt s'intègre généralement bien avec les Data Warehouse tels que BigQuery, Snowflake et Redshift, fournissant une interface optimisée pour les fonctionnalités spécifiques de ces entrepôts.
  • Amélioration de la qualité des données : en centralisant et standardisant les transformations de données, dbt contribue à améliorer la qualité des données dans l'entrepôt, ce qui est primordial pour des analyses fiables et précises.

Il faut noter que dbt n’est qu’un outil de supervision qui vient se greffer au Data Warehouse (tel que Snowflake, BigQuery, Redshift...) et c’est ce dernier qui effectue les calculs. dbt ne fait que fournir les instructions.

Un des avantages majeurs de dbt, c’est également l’ajout d’une connexion avec GitLab/GitHub qui permet de faire du versioning des transformations. Cela veut dire qu’on peut garder une trace de toutes les modifications qui ont été effectuées sur toutes les vues/tables. Cela facilite le travail en équipe sur un même projet grâce au système de branches notamment. 

dbt au service des équipes métier

Pour Limpida, l'intégration de Data Build Tool (dbt) offre une approche accessible et transparente pour la transformation des données. 

Sa facilité d’utilisation réside dans sa conception basée sur des requêtes SQL. Cette approche déclarative permet aux utilisateurs de définir intuitivement des modèles de transformation sans nécessiter une expertise technique approfondie. 

Cette approche simplifiée accélère le processus de modélisation des données et permet aux équipes métier de reprendre la main sur une partie technique dont elles étaient jusque-là dépendantes.

FAQ

Les questions fréquentes

Qu'est-ce que dbt (data build tool) ? +

dbt est un outil open source de transformation de données qui permet de définir, tester et documenter des modèles SQL exécutés directement dans un entrepôt de données. Il occupe le T de l'approche ELT : les données sont d'abord chargées dans l'entrepôt, puis transformées sur place.

  • Les transformations sont écrites en SQL, enrichi du langage de templating Jinja.
  • dbt ne stocke ni ne calcule les données : c'est l'entrepôt qui exécute les requêtes.
  • Chaque modèle produit une table ou une vue dans l'entrepôt.
  • Le code des transformations est versionné dans Git au même titre que du code applicatif.
  • La documentation et le graphe de dépendances sont générés automatiquement.
Comment fonctionne dbt concrètement ? +

dbt lit un ensemble de fichiers SQL et YAML, en déduit l'ordre d'exécution, puis envoie les requêtes correspondantes à l'entrepôt de données. L'ordonnancement des transformations n'est pas déclaré manuellement : il est calculé à partir des références entre modèles.

  • Chaque modèle est un fichier SQL décrivant le résultat attendu, pas la procédure.
  • Les références entre modèles construisent automatiquement un graphe de dépendances.
  • La commande d'exécution construit les tables et vues dans le bon ordre.
  • Le mode de matérialisation (vue, table, incrémental) se paramètre modèle par modèle.
  • Les tests se déclarent en YAML et s'exécutent sur les données produites.
Quelle est la différence entre dbt Core et dbt Cloud ? +

dbt Core est la version open source, gratuite, qui s'utilise en ligne de commande. dbt Cloud est l'offre commerciale managée qui ajoute une interface web, une planification intégrée et l'hébergement de la documentation. Les deux exécutent la même logique de transformation.

  • dbt Core suppose de gérer soi-même l'environnement d'exécution et la planification.
  • dbt Cloud fournit un IDE web, un ordonnanceur et un hébergement de la documentation.
  • Le code des modèles est identique et transférable de l'un à l'autre.
  • dbt Core convient aux équipes disposant déjà d'un orchestrateur et de pratiques DevOps.
  • dbt Cloud réduit le travail d'infrastructure au prix d'un abonnement.
Avec quels entrepôts de données dbt est-il compatible ? +

dbt s'appuie sur des adaptateurs qui traduisent ses instructions dans le dialecte SQL de chaque entrepôt. Les principales plateformes analytiques du marché sont couvertes, par des adaptateurs officiels ou maintenus par la communauté.

  • Snowflake, BigQuery, Redshift et Databricks sont les cibles les plus répandues.
  • PostgreSQL est également supporté, y compris pour des environnements de test.
  • D'autres adaptateurs existent, avec des niveaux de maturité variables.
  • Le choix de l'adaptateur conditionne certaines fonctionnalités avancées.
  • dbt suppose un entrepôt existant : il ne remplace pas la plateforme de stockage.
dbt remplace-t-il un outil ETL ? +

Non. dbt ne couvre ni l'extraction ni le chargement des données : il intervient uniquement une fois que les données brutes sont présentes dans l'entrepôt. Il se combine donc avec un outil d'ingestion plutôt qu'il ne le remplace.

  • L'extraction et le chargement restent à la charge d'un outil d'ingestion dédié.
  • dbt prend le relais sur la transformation, une fois les données dans l'entrepôt.
  • Il n'orchestre pas non plus les flux : cela relève d'Airflow, Dagster ou Prefect.
  • Cette séparation des rôles caractérise l'approche ELT moderne.
  • Un outil ETL classique couvre les trois étapes dans un même produit.
Comment dbt améliore-t-il la qualité des données ? +

dbt intègre des tests qui s'exécutent sur les données produites, et non sur le code seul. Une transformation peut ainsi échouer explicitement lorsque le résultat ne respecte pas les règles attendues, au lieu de propager silencieusement une anomalie dans les tableaux de bord.

  • Des tests standards vérifient l'unicité, l'absence de valeurs nulles ou le référencement.
  • Des tests sur mesure permettent d'exprimer des règles métier spécifiques.
  • Les tests s'exécutent à chaque construction des modèles.
  • Le graphe de dépendances rend visible l'impact d'un changement sur les modèles aval.
  • La documentation générée réduit les écarts d'interprétation entre équipes.
Quelles compétences faut-il pour utiliser dbt ? +

dbt est accessible à toute personne maîtrisant SQL, ce qui élargit considérablement le nombre de profils capables de contribuer aux transformations. La marche à franchir ne porte pas sur le langage mais sur les pratiques d'ingénierie qui l'accompagnent.

  • Une bonne maîtrise du SQL analytique constitue le prérequis principal.
  • Des notions de Git sont nécessaires pour le versionnage et le travail en équipe.
  • La syntaxe YAML sert à déclarer les tests et la documentation.
  • Le templating Jinja devient utile dès que l'on cherche à factoriser du code.
  • Aucune compétence en langage de programmation n'est requise pour démarrer.
Quand faut-il envisager d'adopter dbt ? +

dbt prend tout son sens lorsque les transformations SQL se multiplient et deviennent difficiles à maintenir. À l'inverse, sur un périmètre très restreint ou sans entrepôt de données en place, l'outil ajoute une complexité que le contexte ne justifie pas encore.

  • Un entrepôt de données doit déjà être en place : dbt ne le remplace pas.
  • Le besoin apparaît quand les requêtes se dupliquent entre équipes et outils.
  • La traçabilité des règles de calcul devient un enjeu de gouvernance.
  • Les équipes doivent être prêtes à adopter le versionnage et la revue de code.
  • Sur quelques requêtes isolées, l'investissement n'est pas justifié.