Le compromis dbt : prolifération du code, TCO caché et les arguments en faveur de la modélisation automatisée

dbt, désormais une seule entreprise avec Fivetran, a mérité sa place. Git, les tests, le SQL modulaire et un vocabulaire partagé pour la transformation manquaient à l’ingénierie analytique, et dbt les a fournis. Le compromis qu’il demande apparaît plus tard, en quatre endroits qui ont chacun leur propre article dans cette série.

Le double modèle de coût

Les équipes sur dbt font face à une scission. dbt Core est gratuit à l’usage et laisse l’exécution, la planification, la CI et l’infrastructure à l’équipe, donc le coût est du temps d’ingénierie de plateforme. dbt Cloud fournit le planificateur, l’IDE, l’orchestration et la couche sémantique, tarifés par licence développeur plus l’usage, donc le coût est un abonnement qui grandit avec l’équipe et la fréquence des exécutions. Chaque voie a un coût. L’une en abonnements, l’autre en coûts de personnel. Le détail est dans l’article sur Core contre Cloud.

L’obstacle architectural

• La prolifération. ref() fait d’un nouveau modèle une décision d’une ligne, et les projets grandissent jusqu’à des centaines de fichiers sans règles de gouvernance claires. Changer une clé métier en amont revient à retrouver tout ce qui en a hérité. Voir l’article sur la prolifération des modèles.
• Le calcul. Tout tourne dans l’entrepôt, et une reconstruction complète là où un delta suffirait passe inaperçue et se répercute sur les coûts de calcul. La logique incrémentale est optionnelle et par modèle. dbt State saute désormais les modèles inchangés ; il ne change pas ce qu’un modèle fait quand il s’exécute. Voir l’article sur le calcul de l’entrepôt.
• La lacune d’ingestion. dbt ne fait que de la transformation. Charger les données est un second produit avec une seconde facture et un second schéma, même maintenant que c’est le même fournisseur. Voir l’article sur la lacune d’ingestion.

Liberté contre standardisation

Il y a une cinquième différence qui n’est pas un problème mais un choix de conception. dbt est ouvert, et c’est un avantage réel : n’importe quel pattern, n’importe quel package, n’importe quelle convention que l’équipe préfère. C’est aussi de là que vient le coût, parce qu’il vous revient de construire, de tester et de tenir à jour chacun de ces choix. L’ouverture sans standard signifie que deux projets dbt ne se ressemblent jamais : chacun est une pièce unique que seuls ses auteurs peuvent maintenir, et chaque nouvelle recrue l’apprend de zéro. Et un projet piloté par le code est façonné par le détail technique, table par table et macro par macro, pas par ce que le métier a besoin de voir. Datavault Builder est standardisé et piloté par le modèle : moins de choix, un coût de développement et de maintenance plus bas, et un modèle que les utilisateurs métier peuvent lire et auquel ils peuvent participer, parce qu’il décrit leurs concepts plutôt que le code.

Ces quatre points partagent une seule cause. L’essentiel d’un projet dbt est structurel : le staging, les clés, le dédoublonnage, l’historique. Pour être juste, dbt a des patterns pour cela, des macros et des packages qui encodent le standard. Mais chaque développeur peut les modifier ou les forker, et changer proprement un pattern partagé implique des tests de régression et des scripts de migration pour tout ce qui est construit dessus. Donc quand un pattern ne convient pas tout à fait, une seconde version apparaît, et le projet finit avec plusieurs versions de la même structure. La logique métier personnalisée est la plus petite partie, et elle peut résider dans le modèle ou, si vous préférez, dans dbt.

Ce que change la modélisation automatisée

Datavault Builder décrit la structure dans un modèle visuel et en génère les couches staging, Raw Vault et Business Vault, avec l’ingestion, l’orchestration, le déploiement et le lineage, dans une seule plateforme.

• La part structurelle quitte la base de code. Les hubs, les links, les satellites et leurs chargements delta sont générés, optimisés pour le moteur cible, et régénérés quand le modèle change.
• L’ingestion est dans le même outil. Batch, delta et CDC depuis des bases de données, des fichiers, des API REST, des sources NoSQL et Python, avec des flux comme Kafka qui arrivent en micro-batches. Pas de passage de relais.
• Le calcul suit le changement. Chaque chargement généré est un delta par construction, donc le coût nocturne suit l’ampleur des mouvements dans les sources.
• Les patterns suivent la base de données à votre place. Quand Snowflake, Databricks ou BigQuery sortent une nouvelle fonctionnalité, les patterns de chargement mis à jour et les scripts de migration des structures existantes font partie du produit. Dans dbt, c’est une mise à jour de macro, une série de tests, un script de migration par structure et une nouvelle série de tests, le tout à votre charge. Sur des années, c’est là que se situe l’essentiel du coût de maintenance.
• Le coût est prévisible. Une licence serveur disponible en trois tailles, plus les développeurs, et rien qui soit décompté à l’exécution ou au chargement. Pas de pile d’orchestration à exploiter pour les couches générées.
• La couche de livraison est elle aussi pilotée par le modèle. Marts et produits de données s’assemblent par glisser-déposer sur la couche sémantique, et les règles métier sont gérées et versionnées dans la plateforme, donc les profils orientés métier décident des données dont ils ont besoin.
• La migration d’un projet AutomateDV est pilotée par les métadonnées. Le Migration Vault est un modèle de données fait de hubs, de links, de satellites, de sources, de clés métier et d’attributs. Mappez-y ce que le projet dbt déclare déjà, et le package de déploiement est généré à partir de ce mapping. La même route fonctionne pour presque tout ce qui a une structure à décrire, y compris un entrepôt 3NF.
• dbt est optionnel, pas supprimé. Si l’exploitation reste dans dbt, Datavault Builder génère les modèles dbt à partir du même modèle. Le processus reste piloté par le modèle, et les modèles sont mis à jour par régénération, ce qui est bien plus simple que de les éditer à la main.

Par où commencer

Auditez le projet et classez chaque modèle selon ce qu’il fait : staging, clés, historisation ou calcul. Les trois premiers sont la part structurelle. Cette part, plus le produit d’ingestion devant elle, est ce qu’un entrepôt généré remplace. Il ne reste alors soit aucun projet dbt, soit un projet généré à partir du modèle et jamais édité à la main.