Votre projet dbt compte-t-il plus de modèles que quiconque ne peut expliquer ?

dbt, désormais une seule entreprise avec Fivetran, a rendu la création d’un modèle triviale. select * from ref('...') et un nouveau nœud existe. C’est justement l’intérêt de l’outil, et sur deux ou trois ans c’est aussi ainsi qu’un projet grandit jusqu’à des centaines de modèles avec un lineage que personne ne peut garder en tête. Quand créer du code ne demande aucun effort, l’accumulation est le résultat par défaut.

Pourquoi les projets prolifèrent

• Forker coûte moins cher que changer. dbt a des macros et des packages pour les patterns standard, mais n’importe quel développeur peut les modifier, et changer proprement un pattern partagé implique des tests de régression et des scripts de migration. On crée donc une seconde version du pattern qui ne convient pas tout à fait.
• La structure et la logique cohabitent dans les mêmes fichiers. Un modèle qui met une source en staging, un qui gère l’historique, et un qui calcule la marge se ressemblent tous dans le DAG.
• Les dépendances sont déclarées, pas conçues. ref() enregistre qu’un modèle en lit un autre ; il ne dit pas pourquoi, ni ce qui casse si la clé en amont change.
• La gouvernance arrive après coup. Les conventions de nommage, les dossiers et les tests sont appliqués à un projet déjà volumineux au moment où quelqu’un les a formalisés.

L’outillage n’est pas en cause. Un framework qui rend le SQL modulaire sera utilisé pour écrire beaucoup de SQL modulaire.

Où la structure devrait se situer

• La plupart des modèles sont structurels. Le staging, le dédoublonnage, la génération des clés, le suivi de l’historique : c’est le même pattern par source, qui ne diffère que par les noms de colonnes.
• Le code structurel devrait être généré, pas accumulé. Déclarez la clé métier, les relations et les attributs une seule fois, et dérivez le code de chargement d’un pattern qu’aucun projet ne modifie.
• La logique est la partie qui mérite d’être écrite à la main. Les règles métier, les métriques et la structure des marts sont une petite part du projet et la partie qui mérite une revue de code.

Ce qui change avec Datavault Builder

Datavault Builder conserve la structure dans un modèle visuel et en génère les hubs, links, satellites et leurs chargements, donc la partie répétée du projet n’existe plus sous forme de fichiers.

• Une définition par concept. Un hub client avec cinq sources est un hub et cinq mappings dans le modèle, pas quinze modèles dans un dossier.
• Les dépendances sont dérivées. L’ordre de chargement et le lineage découlent du modèle, donc un changement de clé en amont est visible avant le déploiement, pas après.
• Les métadonnées traversent les couches. Les types, les clés et les descriptions sont déclarés une fois et propagés du staging jusqu’aux marts, au lieu d’être répétés dans chaque fichier de modèle.
• Le refactoring est une édition du modèle. Changez le mapping, régénérez, et chaque structure dépendante est reconstruite de manière cohérente.
• La documentation est le modèle. Le lineage, les définitions et les règles d’historique se lisent en un seul endroit, sans build de documentation.
• Les règles métier sont gérées dans le modèle, avec des versions. La couche de livraison se construit par glisser-déposer sur la couche sémantique, donc les règles et les produits de données sont regroupés au même endroit, avec un historique.
• dbt peut rester, sous forme générée. Si l’exploitation reste dans dbt, les modèles dbt sont générés à partir du même modèle et régénérés à chaque changement, ce qui est une façon bien plus simple de les mettre à jour que d’éditer des centaines de fichiers.

Ce qu’il faut décider

Auditez le projet et classez chaque modèle selon ce qu’il fait : staging, clés, historisation ou calcul. Si les trois premiers constituent l’essentiel de la liste, c’est la part structurelle, et c’est la part qu’un générateur devrait prendre en charge.