DBT fait partie de ces outils qui peuvent faire gagner beaucoup de temps sur un projet Data. Nous vous proposons de le découvrir dans cet article.

Introduction

Data build tool aka DBT est un excellent outil pour orchestrer des transformations de données en SQL.

C’est un outil de la famille des ELT (Extract, Load and Transform). Mais attention, DBT ne s’occupe que du T, c’est-à-dire que DBT exécute des requêtes SQL dans un Data Warehouse.

Il faut que l’extraction des données et le chargement du Data Warehouse aient été faits auparavant à l’aide d’autres outils.

DBT a été créé par la société Fishtown Analytics qui le propose en version open-source mais aussi en version hébergée avec DBT cloud.

La documentation est particulièrement bien faite : https://docs.getDBT.com/.

Vous avez aussi accès à un Slack ou un Discourse pour interagir directement avec la communauté (liens sur la page doc).

En quoi consiste un projet DBT ?

Un projet DBT est composé d’un fichier de configuration et de modèles.

Chaque modèle est un fichier .sql qui contient une seule requête SELECT.

Chaque requête peut se baser sur :

• des tables ou des vues existantes,
• une CTE (Common Table Expression) avec le mot clé “with”,
• un autre modèle avec le mot clé “ref”.
  

C’est là que la magie opère : le moteur de DBT va analyser tous vos modèles pour détecter les dépendances et jouer les requêtes dans le bon ordre.

Grâce à DBT, on pourra facilement automatiser des tests unitaires pour vérifier la cohérence d’un schéma ou tester des résultats de requête comme expliqué ici.

Vous disposez de 4 assertions pour tester les résultats d’une requête, qui couvrent les domaines suivants:

• l’unicité,
• la non nullité,
• la plage de valeurs acceptée,
• les relations entre les tables (est-ce qu’une clé étrangère pointe sur une clé primaire existante).

Pour aller plus loin, on peut coder soit même ses data tests et utiliser les seeds pour injecter des données.

On trouve aussi des macros, qui sont des requêtes qu’on peut étendre avec la librairie Jinja qui permet d’utiliser des templates pour ajouter des boucles et des conditions au SQL natif.

Enfin on peut avoir la bonne idée de documenter son projet mais aussi stocker des requêtes qui ne seront pas jouées à chaque exécution (appelée analysis).

Voici un exemple d’arborescence de projet :

Pourquoi DBT est-il si cool ?

Pour commencer, utiliser l’approche ELT quand il s’agit de manipuler des données structurées ou semi-structurées est déjà un bon côté de DBT. Dans cette approche, on n’a pas besoin de gérer des noeuds de calcul indépendamment des nœuds de stockage et on utilise la puissance et la popularité du langage SQL pour transformer les données.

DBT détecte les dépendances entre les modèles par introspection pour construire et exécuter un DAG (Direct Acyclic Graph).

Par exemple la requête suivante du modèle "orders.sql" :

select 
   orders.id, 
   orders.status, 
   sum(payments.amount) as total_amount
   from {{ ref('base_orders') }} as ordersleft 
   join {{ ref('base_payments') }} as payments on payments.order_id = orders.id

conduit au graphe suivant dans lequel on voit clairement le “data lineage” :

DBT va déterminer tout seul qu’il faut d’abord exécuter les modèles “base_orders” et “base_payments” avant le modèle “orders”.

On peut choisir comment les résultats des requêtes seront persistés : vue (non matérialisée), table, CTE, table incrémentale ou encore éphémère.

Les moteurs SQL supportés sont Redshift, BigQuery, Snowflake, PostgreSQL, Presto et Spark. Ces deux derniers étant en support partiel.

Dans quelles situations DBT est-il une bonne solution ?

Plusieurs critères sont à considérer avant d’utiliser DBT.

D’une part,  il faut pouvoir se contenter du SQL pour toutes les transformations de données. Cela veut dire que vous ne devrez pas utiliser de librairies comme par exemple des librairies de Machine Learning. Et il sera préférable que vos analystes métiers soient capables de lire du code SQL pour collaborer avec vous.

D’autre part, il faut que la chaîne d’ingestion vers le data warehouse soit déjà en place. Comme vous l’aurez compris, DBT ne fournit pas de connecteurs pour charger les données.

Il existe des outils très pratiques pour réaliser cette alimentation comme par exemple Matillion Data Loader présenté sur le blog Ippon dans cet article, Fivetran  ou Hevo.

Si ces deux conditions sont réunies, comme c’est souvent possible pour l’informatique de gestion en général et la B.I. en particulier qui ne manipulent que des données structurées, DBT est un excellent outil à avoir dans sa Data Platform.

Comment exécuter un workflow DBT en production ?

La solution la plus simple, c’est DBT cloud qui vient avec son propre IDE pour développer, planifier et administrer ses projets DBT.

Pour un développeur seul, c’est gratuit si on se contente d’avoir un seul job en exécution concurrent. Ce sera limitant dès que vous aurez besoin de paralléliser vos requêtes mais ça permet déjà de bien avancer.

La version Team est facturée 50$ par développeur par mois et la version Enterprise est sur devis. La page avec les tarifs est ici : https://www.getDBT.com/pricing/

On peut utiliser DBT en ligne de commandes et dans ce cas orchestrer ses jobs avec son orchestrateur préféré. Mais on peut aussi intégrer DBT avec GitLab CI et dans ce cas ce sont les GitLab runners qui vont exécuter DBT.

Enfin, si vous avez déjà un workflow de jobs data en place comme Apache Airflow ou Prefect, dont on parle dans cet article sur le blog Ippon, vous pouvez les utiliser pour lancer vos flux DBT.

La preuve par l’exemple

Je ne vais pas réécrire un tutoriel d’utilisation de DBT. Par contre, je peux vous orienter vers quelques-uns qui sont excellents :

Pour commencer à utiliser DBT CLI, rien de tel que le tutoriel proposé sur le site de DBT.

Pour comprendre les bonnes pratiques de modélisation, ce post discourse est à lire absolument.

L'équipe Gitlab utilise DBT et donne plein de bons conseils ici.

Les concurrents de DBT

Avec la montée en puissance des Data Warehouses dans le cloud, Snowflake, Big Query, Amazon Redshift et Azure Synapse pour ne citer qu’eux, l’approche ELT a le vent en poupe.

De plus en plus d’outils se positionnent sur ce créneau et ce n’est pas toujours simple de s’y retrouver.

Voici des produits que nous vous recommandons :

• Matillion : outil graphique pour rapidement construire des flux de chargement et de transformation de données. Simple et efficace.
• Fivetran : c’est plutôt un data loader, mais il permet de coder des transformations en SQL et en DBT !
• dataform : un environnement complet de développement SQLX qui est une extension du SQL avec des metadata et du test unitaire.
  

Conclusion

DBT se positionne efficacement sur la partie Transformation de l’approche ELT. C’est un excellent outil pour automatiser vos traitements batchs sur un Data Warehouse moderne.

La génération automatique de DAG et la possibilité de coder des tests unitaires sont des améliorations bienvenues au langage SQL.

À moindre coût, vous pouvez démarrer le développement de votre Data Platform avec DBT si tant est que le langage SQL vous convienne pour exprimer votre logique métier. DBT cloud permettra de booster la productivité de votre équipe.

Comme toujours, rien ne vaut un essai pour se forger une opinion !