INCAYA

Pourquoi utiliser DBT pour préparer ses données

Dans la série des outils open-source pour le traitement de la donnée, DBT fait la différence avec comme principaux arguments : la simplicité et un minimum d'abstraction

Ce post fait suite à celui-ci, et nous vous proposons cette fois une focale sur le projet DBT. DBT s’attache à - très bien - faire le travail de transformation de données issues de sources hétérogènes dans le but, notamment, d’alimenter un entrepôt de données. Il repose sur le concept Extract Load Transform (ELT) qui, en opposition à l’ETL, fait porter le poids des transformations sur les moteurs de bases de données source et cible. Cela simplifie la pile logicielle et va souvent avoir un impact très positif sur les performances générales de la chaîne de traitement.

La puissance de la simplicité

Comme nous le disions implicitement en préambule, DBT n’est pas l’outil qui cherche à tout faire. Pour faire simple, voici ce qu’il permet :

  • vous avez des données hétérogènes qui proviennent de bases de données (ou SGBD) ou de fichier plat
  • vous souhaitez les stocker, au même endroit, en les associant et les transformant pour les nettoyer, faire des calculs, … C’est cet espace de stockage qu’on appelle entrepôt de données, dans lequel on construit des Datasets directement exploitables pour des outils de data visualisation ou autres outils d’exploration de données

SQL tout simplement

Comme on souhaite, basiquement, prendre des données à un endroit et les stocker à un autre, quoi de plus naturel que d’utiliser le langage SQL ! C’est le pari de DBT :

  • vous avez une base de données source (PostgreSQL, MySQL, Oracle, …) dans laquelle vous souhaitez piocher pour enrichir votre entrepôt de données ?

    -> décrivez vos sources, qui peuvent être une table, une vue ou plus généralement une requête SQL plus ou moins complexe

  • vous avez des sources de données fichiers à plat au format CSV dans lesquels vous souhaitez piocher également ?

    -> décrivez vos seeds, qui seront importés comme des tables dans votre entrepôt de données

Vous êtes prêt alors à décrire vos models, qui seront les tables ou vues (matérialisées ou non) stockées dans l’entrepôt de données, en précisant :

  • leur structure
  • la requête SQL à exécuter, dans laquelle vous pouvez faire référence à :
    • vos sources : {{ source(<nom de la source>) }}
    • vos seeds : {{ ref(<nom du seed>) }}
    • et même d’autres models {{ ref(<nom du model>) }} que DBT s’assurera d’avoir créé avant !

On y reviendra ensuite, mais l’exécution des traitements d’alimentation (appelé aussi DAG) peut se faire au travers d’une CLI très intuitive.

Jinja et Python

SQL, c’est la base, cela permet de faire énormément de traitements sur les données. Cela étant, pour aller plus loin, DBT propose l’utilisation du moteur de templating Jinja pour créer des macros qui seront autant de fonctions avancées réutilisables dans tous vos models.

Et quand SQL et les bases de données relationnelles standard s’avèrent trop limitées, il est possible avec certaines plateformes de données de créer des models avec Python. Vous l’aurez compris, cette solution se pose dans des cas de figure extrêmes, avec des flux de données complexes et nombreux.

Et les tests ?

C’est une question sensible chez Incaya, tant les tests sont selon nous un gage de qualité de toutes solutions. Et sur ce point, DBT n’est pas en reste puisqu’il est possible d’intégrer nativement des tests aux DAG permettant de s’assurer ainsi que toute la chaîne d’alimentation de l’entrepôt et chacune de ces composantes sont fonctionnelles.

Un Core open-source tout terrain

dbt-core est le moteur de DAG de DBT. Il est open-source, multi-plateforme et installable de plusieurs façons selon les envies et habitudes de chacun.

Soyons clair, si vous attendez un outil avec une interface graphique chiadée, une intégration continue gérée comme une fonctionnalité native, une gestion des droits pour chaque utilisateur des DAG, … passez au chapitre suivant !

Si au contraire, vous pouvez envisager une solution CLI-first, qui permette de créer les DAG, les tester, les orchestrer, dans un dépôt de code partagé, nous vous conseillons dbt-core.

Le cloud pour aller plus loin ….

dbt-cloud est la solution payante (sauf à être seul sur ses projets) proposant un large panel de fonctionnalités complémentaires à dbt-core. En bref, voici les principales fonctionnalités proposées :

Des alternatives open-source ?

Nous ne pouvions pas finir sans, malgré tout le bien que l’on pense de DBT, vous proposer une liste d’outils alternatifs - open-source - à dbt-core. Mais, force est de constater qu’il est difficile de trouver une pure alternative. On trouvera plutôt des outils complémentaires, avec lesquels DBT peut interagir, ou qui pourront être des alternatives à dbt-cloud :