Lorsque j’accompagne mes clients dans la mise en place de dbt dans leur entreprise, il y a une question qui revient tout le temps qui est de savoir quelle version de l’outil adopter : dbt Cloud ou dbt Core ?

Dans cet article, je vous propose de vous partager les différents éléments qui m’aident à choisir entre l’une ou l’autre version. Mais commençons par rappeler ce qu’est dbt.

dbt : le couteau suisse des transformations

dbt est un outil qui nous permet de mettre en place les transformations de données dans nos projets Data : passer de données brutes à des données transformées pour qu’elles puissent être exploitables dans les dashboards ou les analyses.

Pour cela, dbt offre de nombreuses fonctionnalités, comme :

• Le référencement de modèles afin de structurer son code et de favoriser le principe DRY (Don’t Repeat Yourself)
• La visualisation du Data Lineage afin d’avoir une vision claire des transformations
• La facilité de développer des tests
• La génération automatique de documentation
• etc.

C’est donc devenu un outil très populaire pour la transformation de données avec une communauté grandissante.

Toutes ces fonctionnalités que j’ai listées, nous allons les retrouver dans les deux versions de dbt. Il s’agit d’ailleurs de toutes les fonctionnalités de dbt Core, version open source sur laquelle s’appuie dbt Cloud pour l’enrichir de nombreuses fonctionnalités très utiles voire même essentielles dans certains cas.

dbt Cloud : dbt Core managé

dbt Cloud va s’appuyer sur dbt Core mais va proposer beaucoup de fonctionnalités qui vont grandement faciliter son utilisation :

• Environnement cloud : dbt Cloud va directement exécuter les transformations dans le cloud
• Environnement de développement intégré : un éditeur de code qui facilite le développement de nouveaux modèles et facilite également le versionning du code
• Programmation des transformations : il sera possible de programmer l’exécution des différentes transformations
• Interface utilisateur d’administration : facilite l’administration et le monitoring des différents jobs de transformation
• Les accès API : la possibilité d’interagir avec notre projet via les APIs (exécution des jobs, visualisation des logs, interfaçage avec d’autres outils, …)
• Hébergement de la documentation générée automatiquement
• L’utilisation du Semantic Layer (un article est en cours de préparation pour présenter cette fonctionnalité)

Et ces différents ajouts sont autant de choses qui devront être implémentées de notre côté si on souhaite utiliser dbt Core seulement.

Interface d'administration dans dbt Cloud

Comment choisir ?

Il y a, selon moi, trois premières questions à se poser qui nous permettront de nous aiguillier sur la solution à adopter.

Le coût

Le premier critère de décision va être le coût. Pour ce point, c’est assez simple à appréhender : la version open source est gratuite contrairement à dbt Cloud. Un plan gratuit existe néanmoins pour ce dernier.

Attention : soyez vigilant à la petite ligne “15,000 successful models built per month” ! Cela signifie que dans des gros projets qui ont besoin d’exécuter régulièrement de nombreux modèles, le prix peut encore grimper (0,01€ par modèle au-delà des 15000).

Je dis que la version open source est gratuite mais ça n’est pas réellement le cas. Il faut compter les coûts d’hébergement de la solution et également prendre en compte le gain de temps (et donc d’argent) qu’apporte la version cloud si on est amené à utiliser ses différentes fonctionnalités.

La maturité technique de l'entreprise

Le deuxième critère va être la maturité technique de l’entreprise. Si l’entreprise n’a pas d’équipe technique en interne capable de déployer et de maintenir dbt, la question ne va pas trop se poser, dbt Cloud semble être tout indiqué.

Par contre, si des profils techniques sont présents et sont assez à l’aise avec ce genre de sujets, alors on pourra se poser la question d’utiliser dbt Core et le troisième critère de décision va vous aider à trancher.

Nos besoins

Ce troisième critère concerne nos besoins vis-à-vis de l’outil. Si nos besoins se limitent aux fonctionnalités que j’ai listées plus haut (qui correspondent à une utilisation standard de dbt) alors l’intérêt de mettre en place dbt Core va moins se justifier car il faudra remettre en place toutes ces fonctionnalités.

Par contre, pour des besoins beaucoup plus spécifiques, l’utilisation de dbt Core va s’imposer car nous pourrons en faire ce que nous voulons et l’adapter réellement à nos besoins.

Ces besoins spécifiques peuvent être :

• Pipeline CI/CD custom
• Faciliter la gestion des multi-projets
• De très gros besoins en termes de transformations qui coûteront très cher sur le long terme (la fameuse limite de 15000 modèles par mois)

J’espère que vous y voyez plus clair dans ce choix entre dbt Cloud et dbt Core. Et si ça peut vous rassurer, le choix n’est pas définitif. Il sera possible de switcher de l’un à l’autre sans soucis car les deux se basent sur le repo git de notre projet dbt.

Si vous continuez de vous poser des questions sur les outils Data à utiliser dans votre organisation. N’hésitez pas à me contacter afin d’échanger plus en détail sur vos besoins, ça sera un plaisir de vous aiguiller dans vos choix.