DBT - une nouvelle modélisation agile et orientée métier

Dans le monde de la data, la modélisation est un pilier essentiel pour transformer les données brutes en informations exploitables. Longtemps dominée par les approches classiques comme Kimball, Inmon ou Data Vault, la modélisation des données connaît une profonde mutation avec l’émergence d’outils modernes comme dbt (Data Build Tool). Ce dernier propose une approche agile, modulaire et orientée métier, parfaitement adaptée aux exigences actuelles de rapidité et d’évolutivité. Au cours de cet article, nous verrons comment mettre en application ces bonnes pratiques de modélisation dans vos missions en entreprise.

Kimball

La modélisation Kimball est une approche méthodologique créée dans les années 1990 dans laquelle les datamarts sont d'abord constitués sur la base des besoins de l'entreprise et centrée sur l’analyse métier. En effet, on parle généralement de schémas en étoile (star schéma) ou en flocon pour représenter cette modélisation dimensionnelle. Cette approche repose sur la dénormalisation des données, c’est-à-dire avoir de la redondance pour faciliter le requêtage, l’exploitation des données et donc les performances. Cela se représente avec une table de faits (eg. une table de transactions, de mesures etc.) qui est généralement définie par un verbe et des tables de dimensions (comme des clients, des commandes, des articles etc.) qui gravitent autour, définies par des noms. Ainsi, la table de faits contient principalement des identifiants (clés étrangères) permettant de faire les jointures avec les différentes dimensions. En reliant ces deux concepts de faits et de dimensions, on obtient une modélisation facilement compréhensible par les utilisateurs métiers mais qui peut s'avérer complexe en cas de changements structurels ou même dans une architecture Big Data nécessitant une historisation de la donnée.

Représentation de la modélisation Kimball

Inmon

La modélisation Inmon, créée dans les années 1990 elle aussi, est une approche structurée dans laquelle le Data Warehouse est construit à partir d’un modèle d’entreprise centralisé et normalisé en 3ème forme normale (3NF). Autrement dit, cette méthode vise à réduire les redondances des données et permet d'éliminer les dépendances entre les attributs n'appartenant pas à une clé. Contrairement à la méthodologie Kimball, cette approche est moins orientée métier mais favorise la gestion des métadonnées, le contrôle de la qualité et une meilleure gouvernance de la donnée à long terme. En revanche, cette philosophie de pensée est faite pour conserver les états successifs de la donnée avec des règles métiers complexes et prend généralement des mois à être créée entièrement car cela nécessite une grande phase de planification, d’architecture et donc retarde la livraison de valeur aux métiers.

Représentation de la modélisation Inmon

Data Vault

La modélisation Data Vault a été développée dans les années 2000 pour répondre aux limites des deux approches classiques présentées juste avant, notamment dans des environnements où les données évoluent constamment, où les sources proviennent de différents outils et où la traçabilité des données est cruciale. Dans cette approche, on parle généralement de Hubs qui sont des entités métier uniques (comme un client, un produit etc.), des Links qui sont des relations entre les Hubs (un client qui passe une commande) et des Satellites qui sont des informations contextuelles historisées dans le temps. Malgré ces nombreux avantages et les réponses des problématiques soulevées par les deux autres méthodes classiques, cette méthodologie est non adaptée pour une consommation directe par des analystes métier sans couche de transformation supplémentaire et est beaucoup moins intuitive que Kimball et Inmon.

Représentation de la modélisation Data Vault

Tableau comparatif des trois méthodes présentées

Propriétés	Kimball	Inmon	Data Vault
Modélisation	Datamarts	DWH centralisé	Données brutes historisées
Approche	Bottom-up	Top-bottom	Hybride
Modèle	Dimensionnel	Relationnel normalisé (3NF)	Fortement normalisée (Hubs, Links, Satellites)
Mise à l’échelle	Bonne	Moyenne	Très bonne
Mise en place	Rapide (projets ciblés)	Longue (vision complète)	Moyenne (selon l’automatisation)
Complexité	Facile	Difficile	Moyenne

L’approche OBT (One Big Table) est un concept utilisé dans le domaine de la modélisation des données, qui consiste à regrouper toutes les informations pertinentes dans une seule et unique table. Contrairement aux modèles normalisés traditionnels, qui fragmentent les données en plusieurs entités interconnectées par des relations, l’OBT vise la simplicité et la performance de lecture, souvent au détriment de la flexibilité ou de l’optimisation de l’espace. L’idée centrale de l’OBT est de pré-joindre les différentes sources de données — par exemple, des données transactionnelles, des dimensions client, produit ou temps — pour offrir une vue consolidée, prête à être interrogée. Cette approche est particulièrement prisée dans les environnements orientés analyse ou reporting, où les utilisateurs ont besoin de requêtes rapides, simples et lisibles.

Parmi les avantages majeurs de l’OBT, on retrouve une réduction significative de la complexité des requêtes SQL, une meilleure compatibilité avec les outils de visualisation de données (comme Tableau par exemple) et une performance améliorée sur certaines plateformes cloud, notamment lorsqu’il s’agit de scans en lecture. Cependant, l’approche OBT présente également ses limites. Elle peut entraîner une duplication importante des données, une augmentation des coûts de stockage, et des temps de traitement plus longs lors des mises à jour. De plus, elle n’est pas toujours adaptée aux cas d’usage transactionnels ou évolutifs, car chaque modification peut nécessiter la reconstruction complète de la table.

En somme, le modèle One Big Table représente un compromis pragmatique entre performance analytique et rigueur de modélisation. Bien utilisée, notamment en complément d’un modèle en couches (comme le modèle en étoile ou l’approche modulaire avec dbt), elle peut considérablement accélérer la mise à disposition de la donnée pour les équipes métiers et décisionnelles.

Data Build Tool (dbt) est un outil open-source qui révolutionne la façon dont on pense la modélisation des données dans les entrepôts cloud (BigQuery, Snowflake, Redshift, etc.). Cet outil s’intègre parfaitement dans les architectures modernes ELT et introduit un paradigme agile et orienté développement logiciel à la modélisation. L’un des grands avantages de dbt réside dans sa philosophie de modélisation déclarative où chaque transformation est décrite comme une vue ou une table en s’appuyant sur le langage SQL. Il devient donc possible de modulariser les transformations de données, de les organiser en couches logiques (staging, intermediate et marts), et de créer des dépendances claires entre les modèles. Cette approche favorise une meilleure collaboration au sein des équipes data et une plus grande transparence dans les traitements. Ces transformations peuvent aussi être combinées à des fichiers .yml servant de documentation mais aussi à l’automatisation des tests de qualité (unicité, non nullité, relations et pleins d’autres). En combinant ces fonctionnalités avec le versionning avec Git ou encore l’exécution incrémentale des modèles, dbt se positionne comme un pilier de la modern data stack.

Aujourd’hui, en appliquant les préceptes de la méthodologie agile en entreprise et en arrivant dans un nouveau contexte Data, il est parfois compliqué d’avoir une vision d’ensemble du besoin, de lister exhaustivement les sources et modèles qu’on va devoir concevoir pour répondre aux problématiques métiers. Pour cela, il faut garder en tête que chaque modélisation possède ces propres avantages et inconvénients et qu’il n’existe pas de solution miracle. En revanche, certaines modélisations répondent à des problématiques très fréquentes qui peuvent facilement être mises en place, que ce soit dans une nouvelle stack ou pour consolider et redonner une seconde vie à un existant.

En utilisant dbt, on pose déjà une base solide dans l'architecture de notre projet grâce à l’architecture en couches qu’on retrouve généralement sous le nom de staging, intermediate, mart côté dbt. En plus de cela, on peut ajouter une couche reporting pour pouvoir directement brancher les dashboards des BI engineers dessus. Ainsi, vous devez vous demander quelle méthodologie choisir pour vos projets au quotidien ? Comme vous pouvez vous en douter suite aux présentations des différentes approches et de dbt, en réalité, aujourd’hui il ne s’agit plus d’une opposition de ces méthodes ni de choisir une école de pensée, mais de composer intelligemment grâce notamment aux différentes couches — dbt agit donc comme chef d’orchestre. Comme vous l’aurez compris, on peut parfaitement utiliser :

Comme dit précédemment, en arrivant dans une nouvelle mission, il est souvent difficile de percevoir l’ensemble des besoins et de trouver la bonne solution du premier coup. C’est pour cela qu’en étant agile et orienté métier, vous pouvez réaliser vos premiers modèles dbt pour répondre à une problématique précise et garder en tête les différentes informations et granularités dont vous avez besoin à chaque étape.

Par exemple, dans un contexte de Supply Chain, vous pouvez être sollicité pour obtenir des informations à l’article, à la commande, aux dates clés du transport ou encore à une granularité liée aux entrepôts. Assez naturellement, vous allez concevoir vos modèles staging qui récupèrent ces informations des tables mises à votre disposition en gardant des relations 1-1 avec ces dernières. Ensuite, vos modèles intermédiaires vont rassembler les blocs de construction atomiques qui résident dans la couche staging, de sorte que des modèles plus complexes et plus significatifs soient construits. À cette étape, vous pouvez donc avoir des modèles avec des logiques métiers et autres jointures complexes pour répondre à vos différentes problématiques. Enfin, votre couche mart avec vos tables de faits et de dimensions vont réunir les différentes entités métiers définies par l’entreprise. Cette dernière peut directement être mise à disposition des utilisateurs, via des tableaux de bord mais vous pouvez aussi rajouter une dernière couche de reporting spécialement dédiée à ce besoin.

Cette dernière couche peut permettre de regrouper des concepts différents dans une grande OBT pour simplifier le requêtage et peut aussi servir à renommer certains champs afin d’avoir une convention de nommage technique dans votre architecture Data et une autre convention pour les utilisateurs — universelle à l’entreprise. En agissant de la sorte, vous allez créer une architecture et une modélisation saine, qui pourra facilement évoluer à chaque nouveau besoin — soit directement dans vos modèles existant pour ajouter de nouvelles informations soit grâce à de nouveaux modèles pour de nouvelles granularités ou problématiques métier vraiment différentes.

Maintenant que vous avez une première modélisation, vous pouvez réfléchir à chaque nouveau besoin et voir comment cela s'intègre avec votre existant. Est-ce que ce sont des informations similaires qui vont faire part à vos modèles existant ou est-ce que c'est un sujet presque indépendant du reste. En se questionnant à chaque fois, vous allez naturellement vous rendre compte que des besoins différents vont quand même avoir une base commune, que ce soit en termes de données source ou en termes de granularité. En reprenant l'exemple de la Supply Chain, vous pouvez construire des modèles transverses qui vont servir de socle à votre équipe comme les données clés des commandes, des ventes ou encore un transport avec ces différentes étapes et dates associées. Avec cette approche itérative, votre architecture va s'améliorer sujet après sujet et couvrir l'ensemble du périmètre de votre équipe et les nouveaux sujets pourront être livrés de plus en plus rapidement sans que ce soit au détriment de la qualité de la modélisation. Au-delà de dbt ou des tableaux de bord, ces modèles transverses peuvent aussi servir comme base à des Data Scientists ou Data Analyst pour leurs besoins — quitte à profiter de leur expertise pour challenger ces nouveaux modèles et leur qualité. Comme tout développement peut générer de la dette technique, il ne faut pas hésiter à refactoriser certains concepts et à reprendre un peu de recul quand les sujets s'accumulent et que l'expérience s'agrandit pour s'assurer que cela reste compréhensible, maintenable et en phase avec les besoins de l'équipe.

Pour suivre ces évolutions, dbt offre quelques fonctionnalités très puissantes comme le versioning des modèles (ici) pour pouvoir suivre les évolutions et avoir un fonctionnement itératif sans impacter tout le monde à chaque développement. Une autre force est l'utilisation de la stratégie incrémentale (ici) dans vos modèles pour pouvoir insérer, fusionner et fonctionner par batch pour vos nouvelles données — avec la possibilité de rejouer en cas de nouvelles fonctionnalités. Enfin, vous pouvez aussi mettre en place des contrats de données, appelées model contracts dans dbt (ici), pour définir avec vos personna le schéma et les colonnes de vos modèles mais aussi leurs contraintes de qualité ou business qui peuvent être liées. Ainsi, dbt va comparer vos modèles SQL ou Python avec le contrat .yml défini pour détecter les incohérences.

Vous allez me dire que toute cette architecture c’est bien beau mais qu’apporte dbt dans l’histoire ? Si les avantages liés à l'évolution du besoin métier présentés précédemment ne vous ont pas convaincu, d'autres fonctionnalités et outils qui gravitent autour de dbt, vous permettront de vous simplifier la vie et d’avoir une stack Data encore plus robuste. En présence de dimension à évolution lente, dbt propose un mécanisme de snapshot (ici) qui enregistre les modifications apportées à une table au fil du temps et permet donc de regarder les différents états antérieurs.

En plus de ces derniers et des contrats de données, vous pouvez utiliser dbt-checkpoint (ici) qui offre des pre-commit, c’est-à-dire un script qui va se lancer avant de faire votre commit, pour comparer vos modèles SQL ou Python avec vos fichiers .yml. Grâce à ce hook, vous pouvez vérifier que chaque description de vos champs sont bien les mêmes et vous forcer à avoir une bonne convention de nommage mais aussi s’assurer que chaque modèle possède des tests, des descriptions ou encore les mêmes colonnes. Ce dernier vous évitera de renommer ou de supprimer une colonne dans votre modèle sans modifier la documentation associée. De plus, le fichier .yml ne permet pas uniquement de faire votre documentation, il vous permet aussi de faire des tests d’unicité, de non-nullité, de déclarer vos clés primaires (qu’elles soient naturelles ou via des clés de substitution), vos clés étrangères mais aussi de définir des tests plus complexe basé sur une liste de valeurs acceptables ou même d’expressions régulières. Enfin, pour éviter de tout reconstruire et ré-inventer à chaque nouveau besoin, l’utilisation de macro (ici) peut vous permettre d’avoir un code plus digeste et réutilisable — que ce soit pour un concept métier précis, pour répéter une opération sur plusieurs pays ou même pour un calcul complexe. Pour exploiter plus en détail les macros et les tester, vous pouvez aller jeter un coup d'œil sur cet article.

En conclusion, de nombreuses méthodologies de modélisation se sont développées au cours des dernières décennies avec leurs propres avantages et inconvénients. Avec dbt comme chef d’orchestre, vous pouvez bénéficier des avantages de chacune des méthodes en fonction de la couche dans laquelle vous vous situez. Cela permet donc une modélisation moderne et modulaire en phase avec les principes d’agilité présents dans de nombreuses entreprises. Au-delà de la modélisation, dbt fonctionne comme une surcouche qui possède pléthore de fonctionnalités qui peuvent faciliter le quotidien, rendre votre architecture encore plus robuste et faciliter les évolutions successives des besoins métiers.