+33 146 372 242

Grâce à DBT, Faites du SQL l’arme absolue de votre transformation des données

DATA Factory

Incubé au sein du Datalab Novagen, le projet Bestway est un condensé de Data Ingénierie et de Data Science : il fait converger de nombreuses sources de données et des transformations complexes. Afin de modéliser et simplifier des requêtes SQL exécutées sur BigQuery, qui est notre socle de données, nous avons été amenés à utiliser Data Build Tool aka DBT.

Dans cet article, nous vous présentons notre challenge technique sous plusieurs dimensions: architecture, rapidité de développement et fiabilité. Puis dans un second temps, nous détaillerons notre choix de DBT et sa mise en œuvre.

 

[Notre Objectif / notre besoin]

 

Bestway est une solution Saas permettant l’optimisation de la décote sur des produits. Le fournisseur Google Cloud Platform ayant été retenu, nous nous sommes tournés vers les services managés de GCP pour arriver rapidement à des résultats. La partie stockage et transformation des données est assurée par BigQuery qui nous permet d’effectuer des requêtes SQL rapidement sur un grand volume de données. Dans ce projet, ces requêtes avaient plusieurs objectifs :

  • Requêter les données recueillies auprès du client et les adapter à notre modèle,
  • Transformer les données en prenant en compte des paramètres utilisateurs avant de les envoyer dans des modules de clustering et d’optimisation,
  • Préparer les données afin qu’elles soient utilisées par des outils de visualisation.

Ces requêtes ont trois particularités :

  1. Un nombre important de lignes (+ 500 lignes de SQL pour les plus grandes)
  2. Il y en a une trentaine et plusieurs font référence au même code
  3. Elles doivent pouvoir être paramétrables par un utilisateur

Nous souhaitions avoir une technologie qui nous permette d’aller vite et d’avoir des résultats fiables et testables, s’intégrant facilement avec BigQuery.

 

[Le choix]

Il existe un nombre important de solutions qui permettent de répondre plus ou moins à notre besoin. Nous nous sommes penchés notamment sur l’étude de deux services GCP, Dataproc et DataFlow.
Nous aurions pu utiliser du ‘Spark as a service’ avec DataProc que nous avons testé afin de répondre à notre besoin global d’ETL. Néanmoins, nous l’utilisons uniquement pour ses capacités ‘Extract’ and ‘Load’ lors de l’insertion d’un nombre important de données. Pour la transformation, notre utilisateur a besoin d’aller vite lors de ses exécutions (qui peuvent être des requêtes courtes). Une exécution avec Data Proc aurait nécessité plus de temps d’exécution notamment avec le provisionnement des clusters.
Dataflow ne répond pas à notre besoin de modularité / templates de nos requêtes SQL. Nous nous sommes donc penchés sur DBT afin de répondre à notre besoin.
Voici un schéma simplifié représentant les interactions entre les différents modules du projet:

 

[Présentation de DBT]

DBT est un projet qui a commencé en 2016 et qui est depuis ces cinq dernières années en adoption croissante au sein des architectures IT des entreprises. L’entreprise DBT Labs a levé ces 5 dernières années près de 200 millions de dollars et a déjà été valorisée à plus de 1,5 milliards de dollars, témoignant de la solidité et de la confiance en cette approche.

Quels en sont les concepts principaux ?

DBT, c’est le T de l’ETL ( Extract Transform Load ) : il permet de récupérer des données issues de Data Warehouses et de les transformer avec des simples requêtes SQL les données brutes (ou raw layer) sont transformées en données prêtes pour la consommation.

 

[La place de DBT dans une organisation Data]

L’objectif de DBT est d’apporter toutes les meilleures pratiques du monde développement software à l’analyse de données. Ce rôle entre data engineering et data analyse permet à ses utilisateurs connaissant le SQL de développer des pipelines de transformation complètes (modulaires, portables, documentées et avec intégration et développement continu).
DBT utilise une architecture de ‘modèles’ et de ‘macros’ afin de structurer les requêtes que l’on souhaite exécuter :

    • Les modèles structurent les requêtes (fichiers ‘.sql’ ) par groupe, par niveau de transformation et par qualité des données.
 
  • Les macros s’apparentent à des fonctions dans d’autres langages et exécutent des petits bouts de code SQL ou Jinja qui sont injectés dans les requêtes.

Cette architecture offre une séparation simple et claire de toutes les étapes de transformation qui sont effectuées.
Les requêtes se référencent entre elles, cela permet à DBT d’ordonnancer l’exécution des requêtes en fonction de leurs dépendances. On lance l’exécution d’un modèle qui déclenche toutes les requêtes qui sont référencées, ce qui assure la fraîcheur et donc la véracité de nos résultats.

Ci-dessus, nous avons l’exemple d’une requête simple qui montre 3 fonctionnalités de DBT. Toutes ces fonctionnalités sont directement liées au code Jinja qui étend les possibilités du code SQL :

    1. La matérialisation des requêtes : Il existe de multiples matérialisations que l’on peut créer et personnaliser et qui définissent la manière dont va être enregistrée la table dans le datawarehouse de destination. On peut notamment choisir :
      a) Une table ou une vue
      b) La stratégie d’incrémentation (on remplace ou ajoute les données)
      c) Le partitionnement et le clustering des données
 
    1. L’utilisation de variables : On utilise ici {{ var(‘project_id’) }} qui fait référence à une de nos variables définie dans notre base de données PostgreSql.
 
  1. L’utilisation des références : Avec la fonction {{ref (‘pred_df’)}} on utilise les résultats d’une autre requête directement. DBT connaît grâce à cette fonction l’ordre d’exécution des requêtes.

Afin d’avoir une visualisation macro de nos requêtes et de leurs dépendances, DBT fournit une documentation générée automatiquement par les fichiers de configuration et les références créées dans nos requêtes. Le schéma ci-dessous montre les liens entre les requêtes dans le cadre de la requête que l’on a montrée plus tôt.

[Fiabilisation Résultats]

DBT propose deux manières de rédiger des tests fonctionnels.

  1. Des tests spécifiques qui sont des requêtes SQL détaillées qui cherchent à vérifier une ou plusieurs conditions particulières.
  2. Des tests génériques qui sont des requêtes SQL que l’on variabillise et qui prennent comme arguments la colonne et le nom de du modèle par exemple.


DBT propose aussi des tests unitaires de non régression qui comparent les résultats d’un fichier du projet et le résultat d’une requête.
Tous les tests sont écrits sur un fichier de configuration à l’intérieur du modèle. Ils peuvent s’écrire assez rapidement et réduisent considérablement la quantité de code à écrire pour les développeurs.

[Conclusion]

L’intégration de DBT au sein du projet Bestway a été simple et rapide. Les développements étant en SQL, cela a permis une montée en compétence rapide sur l’outil sans pour autant que nous soyons limités par le langage grâce à l’utilisation du Jinja.En le combinant avec Flask et Cloud run, nous avons pu automatiser les exécutions et l’intégrer facilement à notre architecture.

La simplicité de tester et de documenter le code s’avère très utile pour comprendre, expliquer et fiabiliser des requêtes SQL complexes et nombreuses.

DBT est un outil efficace qui permet de se concentrer sur les développements à valeur ajoutée ce qui est appréciable.

Il reste néanmoins un petit bémol: débugger une requête SQL de 500 lignes est plus rapide avec DBT mais cela reste tout de même un processus très chronophage qui serait facilité par des approches ETL classiques.
Pour en savoir plus sur DBT et son fonctionnement :
https://docs.getdbt.com/
Edouard CALLET, Data Ingénieur @ Novagen

 

EXPERTS & CONSEILS
La technologie au service des besoins métiers.

DATA FACTORY
Expérimentation, Méthode et Industrialisation.

Pin It on Pinterest