Incubé au sein du Datalab Novagen, le projet Bestway est un condensé de Data Ingénierie et de Data Science : il permet de faire converger de nombreuses sources de données et des transformations complexes. Afin de modéliser et simplifier les 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 défi 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.
Bestway est une solution Saas permettant l'optimisation de la décote sur des produits. Le fournisseur Google Cloud Platform ayant été retenu, nous sommes tournés vers les services géré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 des grands volumes de données . Dans ce projet, ces requêtes avaient plusieurs objectifs :Demander les données collectées 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 :
Un nombre de lignes important (+ 500 lignes de SQL pour les plus grandes)Il y en a environ 25 au total dont plusieurs font référence au même codeElles doivent pouvoir être pilotées par un utilisateur (paramètres et contraintes)Nous souhaitons avoir une technologie qui nous permette d'aller vite et d'avoir des résultats fiables et testables qui s'intégreraient facilement avec BigQuery.
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 total d'ETL. Néanmoins, nous l'utilisons uniquement pour son 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 assez rapides). 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 :
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 :
Ce rôle à cheval entre l'ingénierie et l'analyse des données permet de concilier plus facilement les deux et de les regrouper dans un seul outil où un Data Analyst peut écrire directement les requêtes dont il a besoin.
DBT utilise une architecture de 'models' 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 sont comme 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'ordonner 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 :
La matérialisation des requêtes :
Il existe de multiples matérialisations que l'on peut créer et personnaliser et qui implique la manière dont va être enregistrée la table dans le datawarehouse de destination. On peut notamment choisir :Une table ou une vueLa stratégie d'incrémentation (on remplace ou ajoute les données)Le partitionnement et le clustering des données
L'utilisation de variables : On utilise ici ... qui fait référence à une de nos variables définies dans notre base de données PostgreSql.
L'utilisation des références : Avec la fonction ... on utilise directement les résultats d'une autre requête. 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.
DBT propose deux manières de rédiger des tests fonctionnels :
Des tests spécifiques qui sont des requêtes SQL détaillées qui recherchent à vérifier une ou plusieurs conditions particulières.
Des tests génériques qui sont des requêtes SQL que l'on variabilise et qui prennent comme arguments la colonne et le nom de du modèle par exemple.
DBT propose également 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éduire considérablement la quantité de code à écrire pour les développeurs.
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 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 satisfaisant.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 que l'on aurait moins en utilisant d'autres langages.Pour en savoir plus sur DBT et son fonctionnement : https://docs.getdbt.com/DBT propose également 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éduire considérablement la quantité de code à écrire pour les développeurs.
Edouard CALLET , Ingénieur Data @ Novagen
« Novagen, créateur de solutions Data innovantes pour développer votre Business. »
N'hésitez pas à nous contacter pour tirer le meilleur parti possible de vos données !
contact@novagen.tech
