Avouons-le immédiatement, malgré mes 15 ans d’expérience dans l’ingénierie logicielle, je n’ai réellement mouillé le maillot dans l’univers de la DATA qu’à partir de fin 2022, ce qui est relativement récent.

Mes repères ne sont pas ceux d’un data-analyst ou d’un data-engineer, ils sont ceux d’un décideur technique, CTO d’une petite société ou un ingénieur principal d’une plus grande dont les objectifs sont la productivité, la maintenance, la qualité des livrables et le travail en équipe.

Pour faire très court, je vais vous livrer immédiatement ma conclusion : si vous devez partir sur un nouveau projet, faites-le avec SQLMesh et non avec DBT.

Faire le bon choix avec SQLMesh

Historiquement, DBT est le premier projet qui a permis de résoudre d’anciennes problématiques telles que la fragmentation des modèles de transformation, l’ordonnancement des modèles en suivant leurs dépendances, ainsi que la documentation.

Mais comme jQuery à l’époque, où le développement front-end gagnait en maturité, une utilisation professionnelle et à grande échelle ont mis en lumière de nouvelles problématiques non couvertes par DBT.

Voir l’article DBT is jQuery, not Terraform.

D’aucuns vont me dire que grâce à son système modulaire, il existe des extensions DBT pour résoudre ces problèmes, mais chaque extension vient avec son lot de complexité ; et ces extensions ne peuvent répondre à l’ensemble des problématiques qui sont parfois les fondements de nos data-stack.

SQLMesh est arrivé récemment, avec une parfaite connaissance des lacunes et problématiques du secteur DATA. Il apporte un nouveau paradigme ainsi que des fonctionnalités de contrôle qualité qui sont nécessaires pour assurer la confiance des utilisateurs qui exploitent les dashboards et rapports finaux.

En effet, ce qui m’a le plus marqué dans DBT, c’est la difficulté de maintenir les modèles tout en contrôlant la qualité des données. Là où SQLMesh propose une intégration native à GitHub et des outils permettant de connaître les impacts d’une modification, DBT ne l’évoque même pas …

Si peu de points négatifs

SQLMesh est encore jeune par rapport à DBT. C’est sa plus grande faiblesse : les productions communautaires et les ressources humaines sont moins abondantes que pour DBT. Mais cela n’est pas un deal-breaker, car la société et l’équipe derrière ce projet sont très rassurantes et résolvent ce problème en produisant une documentation officielle de qualité ; l’équipe est disponible sur Slack et répond activement à ses utilisateurs.

Pour être totalement franc, l’autre point qui me pose des soucis c’est l’absence d’intégration avec les IDE. Là où DBT possède des plugins VSCode et presque rien sur IntelliJ ; SQLMesh ne possède qu’une interface WebUI. La WebUI de SQLMesh est suffisante à elle-même, elle propose tout ce que l’on peut souhaiter. Mais malgré tout, j’attends avec hâte l’intégration de SQLMesh au sein de IntelliJ ou VSCode.

Bref, en quelques bullet-points ce que SQLMesh a par rapport à DBT

  • Des tests unitaires portés par DuckDB pour valider vos modèles
  • Des outils de contrôle qualité permettant de connaître les impacts d’une modification 🔥🔥🔥
  • La gestion d’environnement virtuel
  • Un column lineage
  • Une intégration de qualité avec GitHub CI

La notion d’environnements virtuels est très importante, elle n’apporte pas qu’une réduction des couts, c’est grâce à elle que vous pourrez optimiser vos processus de déploiement et avoir un contrôle qualité de la DATA.

Il est évident que vos choix doivent se faire en fonction de vos connaissances et de celles de votre équipe. Parcourez la documentation sans préjugé et faites-vous un avis avec un proof-of-concept sur les deux technologies.