Votre facture dbt augmente-t-elle en licences, ou en ingénieurs ?

dbt, désormais réuni avec Fivetran au sein d’une même entreprise, a donné au SQL ce que le génie logiciel avait depuis des années : le contrôle de version, les tests, la modularité. C’est pour cela que les équipes l’adoptent. La conversation sur le coût arrive plus tard, et elle se pose sur les deux voies que dbt propose.

Pourquoi la couche coûte plus que la licence

• dbt Core est gratuit à télécharger, pas gratuit à exécuter. Quelqu’un met en place l’orchestrateur, le pipeline CI, le stockage des artefacts et le state deferral, puis les maintient en fonctionnement. Ce quelqu’un est un ingénieur qui a été recruté pour modéliser des données.
• dbt Cloud est tarifé par développeur, plus l’usage. Le nombre de licences suit la taille de l’équipe, et comme l’usage est mesuré, la facture suit la fréquence de construction des modèles. Prévisible sur un mois calme, moins sur un mois chargé.
• Les deux voies paient en plus la puissance de calcul de l’entrepôt. Chaque exécution tourne dans Snowflake, BigQuery ou Databricks, et cette facture est distincte des licences comme des coûts de personnel.
• Les deux voies assument le support. dbt Core bénéficie d’un support communautaire ; dbt Cloud ajoute un support fournisseur pour la plateforme, pas pour les patterns de votre projet.
• Les deux voies assument les patterns. Quand la base de données sort une nouvelle fonctionnalité, quelqu’un met à jour les macros, les teste, écrit des scripts de migration pour chaque structure existante et les teste aussi. Ce travail n’a de ligne sur aucune des deux factures, et sur la durée de vie d’un entrepôt c’est le plus gros coût de maintenance de la couche.
• L’ouverture est l’avantage, et le coût. C’est à vous de choisir chaque pattern et chaque convention, ce qui fait l’attrait, et à vous de les construire, de les tester et de les tenir à jour, ce qui fait la facture.
• Le choix est présenté comme l’un ou l’autre. Soit des abonnements, soit de l’ingénierie de plateforme. L’option que personne ne présente est une couche de transformation qui a besoin de moins de code écrit à la main dès le départ.

Où le coût se situe réellement

• La majeure partie d’un projet dbt est le même pattern répété. Les modèles de staging, la gestion des clés, le dédoublonnage et la logique d’historique sont écrits source par source et réexécutés à chaque planification.
• Les patterns répétés sont exactement ce pour quoi les générateurs existent. Une plateforme pilotée par le modèle dérive ce code du modèle, donc il n’est ni écrit ni maintenu à la main.
• La logique personnalisée est la petite partie. Les règles métier et les métriques qui ont réellement besoin de SQL sur mesure sont une fraction de la base de code, et c’est la partie où dbt excelle.

Ce qui change avec Datavault Builder

Datavault Builder génère les couches staging, Raw Vault et Business Vault à partir d’un modèle visuel, avec orchestration, déploiement, documentation et lineage dans la même plateforme.

• La partie générée disparaît de la base de code. Pas de modèles de staging à écrire, pas de macros incrémentales à maintenir, pas de logique d’historisation à retester pour chaque source.
• L’orchestration et la CI sont fournies. Le support de Git et Gitflow, les scripts de déploiement et de rollback et le lineage font partie de la plateforme, pas d’une seconde pile à exploiter.
• Idem pour les mises à jour de patterns, les mises à jour de base de données et le support. Les nouvelles fonctionnalités de base de données arrivent sous forme de patterns de chargement mis à jour, scripts de migration des structures existantes inclus, et le support fait partie de la licence plutôt que d’un forum.
• La couche de livraison est elle aussi pilotée par le modèle. Les marts et les produits de données s’assemblent par glisser-déposer sur la couche sémantique, avec des règles métier 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 sans développeur dbt dans la boucle.
• dbt est optionnel, pas supprimé. Les équipes qui veulent garder l’exploitation dans dbt obtiennent les modèles dbt générés à partir du même modèle. Le processus reste piloté par le modèle, et un changement est une mise à jour du modèle et une régénération, pas une édition à la main.
• Le coût est prévisible. Une licence serveur, à choisir parmi trois tailles, plus le nombre de développeurs, et rien qui soit mesuré par exécution ou par chargement. Pas de cluster d’orchestration à exploiter, et pas de ligne de facture qui bouge avec la fréquence de construction des modèles.

Ce qu’il faut décider

Auditez le projet et comptez les modèles qui n’existent que pour mettre en staging, dédoublonner, gérer les clés ou historiser une source. Cette part du projet est ce que vous payez deux fois, une fois pour l’écrire et une fois pour l’exécuter. C’est la partie qu’un générateur devrait prendre en charge.