DBT en action : construire la couche de marts qui connecte tes données au business

Bienvenue dans le troisième et dernier article de cette série sur DBT. Dans les épisodes précédents, on a exploré en profondeur comment structurer la donnée dans les couches initiales d’un projet DBT : les modèles de staging pour unifier la donnée et les modèles intermédiaires qui appliquent la logique métier pour transformer ces données.

Dans cet article, on va voir le stade final de ces transformations : la couche de marts, l’endroit où la donnée est disponible pour être consommée, prête pour le business et utile pour faire de l’analytique avancée ou l’utiliser avec des outils de BI.

Qu’est-ce qu’un mart dans DBT ?

Un mart est la couche finale et curée de notre data warehouse, représentée, comme le reste des composants de notre projet, par un fichier .sql qui contient une sélection de colonnes. Son but est d’exposer des datasets propres, fiables et orientés business que les analystes et les utilisateurs métier peuvent consommer directement.

Contrairement aux modèles de staging et intermédiaires qui se concentrent sur l’intégrité de la donnée et les transformations logiques, les marts se concentrent sur l’utilisabilité.

C’est pour cela qu’ils représentent l’aboutissement de tout le travail de modélisation fait jusqu’ici. C’est là où nos transformations cessent d’être de simples décisions de structures de données et deviennent des supports pour la prise de décision, le suivi de performance, le monitoring du risque ou l’analyse de résultats business.

Les marts sont typiquement dénormalisés, c’est-à-dire qu’ils consolident l’information issue de plusieurs intermédiaires dans une unique table de plus grande taille. Chaque enregistrement représente une entité métier claire (comme un prêt, un client ou une transaction) enrichie de KPIs ou de métriques agrégées et prête à être visualisée dans un dashboard BI ou consommée par un modèle de machine learning.

C’est pour cela qu’un mart bien conçu ressemble souvent davantage à un document business qu’à un artefact technique. Une personne qui ne connaît pas SQL ne pourra sûrement pas interpréter en profondeur un intermédiaire, mais un mart doit être clair et compréhensible. Les noms des colonnes doivent être lisibles et clairs (total_disbursed_amount au lieu de td_amt) et la table résultante doit s’aligner sur la façon dont le business pense à ses opérations. En essence, les marts transforment des pipelines de données complexes en datasets accessibles et fiables.

Regardons un exemple de mart simple :

Ce mart joint plusieurs sources de données intermédiaires pour produire une vision finale et unifiée de la performance d’un crédit d’une hypothétique fintech. Le résultat est ce dataset propre, net et prêt à servir pour faire de l’analytique, qui peut alimenter des rapports financiers, des analyses de risque et des dashboards opérationnels.

De gueux à KPI : le chemin du lineage des données

La couche de mart est la conclusion naturelle de la hiérarchie des modèles DBT, qui se présente ainsi :

Raw → Staging → Intermediate → Mart

Chacune de ces étapes dépend de la qualité de la précédente. Le staging gère les transformations essentielles, comme le nettoyage des colonnes, le casting des types de données et la suppression des doublons. Les modèles intermédiaires ajoutent la logique métier, comme les calculs de KPIs clés pour l’opération. Et enfin, la couche de mart unifie tout et le rend disponible.

Dans DBT, on peut visualiser ce lineage de sources et transformations grâce à la commande dbt docs generate. En l’exécutant, on verra quelque chose de similaire à ceci :

raw_customer_data → stg_customers → int_loans_data → mart_loans

Cette traçabilité visuelle, fortement simplifiée pour cet exemple, est l’une des caractéristiques les plus puissantes de DBT. Elle nous assure que chaque métrique business peut être parcourue de bout en bout, de sa source à son mart, et nous apporte tranquillité et transparence dans le processus d’analyse.

Qu’est-ce qui fait un bon mart ?

La conception des marts requiert une attention particulière sur des sujets comme la nomenclature, l’organisation des schemas et la définition des tests. Ce sont ces aspects qui séparent un modèle fonctionnel d’un modèle durable et prêt à partir en production.

Du point de vue de la nomenclature, les marts doivent être facilement identifiables, donc utiliser des suffixes ou préfixes comme mart ou mart aide à les distinguer clairement. En plus, ils devraient contenir quelque chose dans leur nom qui indique leur usage business. Un bon nom pourrait être mart_loan_performance.sql.

L’organisation des schemas est tout aussi importante. Maintenir les marts dans un schema dédié (habituellement appelé, vous l’aurez deviné, marts) aide à maintenir l’organisation des composants de nos pipelines de données dans notre data warehouse. Cela simplifie aussi l’attribution des permissions, car les marts sont souvent le seul schema exposé aux analystes BI. Dans notre dbt_project.yml (qu’on a déjà vu dans les articles précédents), cela peut se configurer ainsi :

La qualité de la donnée doit toujours être dans nos têtes, d’autant plus quand on travaille avec des transformations aussi complexes. C’est pour cela que les tests sont un composant fondamental de tout projet DBT mature et bien conçu. Dans ce sens, on peut ajouter des tags à nos marts dans le .yaml du projet pour nous aider à distinguer les marts critiques pour chaque opération business :

Et on peut même continuer à définir des tests spécifiques qui garantissent la qualité des données et que les transformations qu’on a faites pour arriver ici ou qu’on réalisera à l’avenir continuent à respecter nos standards de données, afin d’éviter des erreurs coûteuses ou qui nous amèneraient à prendre de mauvaises décisions business.

Performance au point

Comme les marts gèrent et traitent de la donnée agrégée ou historique, l’optimisation de la performance de nos processus est fondamentale pour maintenir l’efficacité et la scalabilité de notre projet au fur et à mesure que notre flux de données augmente aussi. Heureusement, DBT propose plusieurs options de matérialisation qui déterminent comment nos modèles sont construits et stockés.

Par exemple, pour des marts petits ou moyens, la matérialisation de type table est souvent plus que suffisante. Ce qu’elle fait, c’est recréer la table à chaque fois et nous garantit la consistance du résultat final au prix de temps de construction un peu plus longs. En revanche, pour de gros datasets, il est préférable d’utiliser la logique incrémentale, car elle ne traite que l’information nouvelle ou mise à jour à chaque exécution du processus.

Une configuration typique de mart incrémental ressemble à ça :

Et même, si on travaille dans des data warehouses qui le permettent (comme Google BigQuery ou Amazon Redshift), on peut optimiser encore plus notre processus en définissant des stratégies de partitionnement et de clustering :

Ce type de configurations peut améliorer significativement la performance de nos requêtes, surtout pour les dashboards ou requêtes analytiques qui s’exécutent régulièrement. Le partitionnement aide à isoler la donnée la plus récente pour des mises à jour incrémentales plus rapides, tandis que le clustering améliore la performance du filtrage et des jointures.

Et la doc ?

Enfin, on arrive au point culminant de tout projet… la documentation ! Sans documentation, toute personne qui voudrait entrer sur notre projet et comprendre de quoi il s’agit, ou qui aurait simplement une question générale sur sa structure, va avoir de sérieux problèmes.

Dans DBT, la documentation est ce qui transforme un mart d’une simple table utilisable en un data asset partagé par toute l’organisation. Heureusement, elle nous facilite aussi énormément le processus de documentation, car elle est intégrée directement dans le projet. Cela nous garantit que le contexte métier est transmis en même temps que les définitions techniques.

À quoi je fais référence ? Chaque mart individuel devrait avoir un fichier schema.yml qui décrit son objectif, les colonnes qu’il contient et les métriques clés. Par exemple :

C’est déjà très utile en soi, mais on peut aller un cran plus loin : une fois ce fichier défini et la documentation en place, on peut générer un site interactif et navigable avec les commandes suivantes :

dbt docs generate
dbt docs serve

Cela crée, comme par magie du code, un catalogue de données avec des graphiques de lineage, la description des colonnes et leurs relations. Il va sans dire que c’est une ressource inestimable pour les analystes, les ingénieurs data et les utilisateurs métier : non seulement ça aide à comprendre ce que contient chaque mart, mais ça montre aussi comment on est arrivé aux chiffres finaux qu’on expose dans nos marts.

On en arrive là…

Ce furent trois articles avec beaucoup de développement conceptuel et technique, des démos et du code. Apprendre à utiliser un framework aussi flexible que DBT devrait faire partie de l’arsenal de tout data developer aujourd’hui : c’est du SQL simple, lisible, maintenable et scalable, et un outil fondamental dans l’écosystème data moderne.