SQL et dbt : L'avenir de la transformation moderne des données
- IA, BigQuery, intégration de données
- 9 min de lecture
Tobias Vogler
Cet article décrit le traitement des données dans les entreprises. Il aborde à la fois la technologie SQL (Structured Query Language) bien établie et l'outil moderne dbt (Data Build Tool) pour la modélisation des données. SQL est un langage permettant d'interroger des bases de données. dbt, quant à lui, est un outil qui optimise le processus de transformation des données dans les entrepôts de données en appliquant les pratiques du génie logiciel à l'analyse des données.
Introduction
Laissez-moi vous raconter une histoire. Il s'agit d'entreprises dont l'objectif est d'extraire de précieuses informations de leurs données. Depuis des décennies, il s'agit d'une lutte dont la situation est à la fois confuse et difficile, mais aussi prometteuse et passionnante. Nous avons une terre en friche qui s'est dégradée au fil du temps, où des batailles font rage pour un avenir incertain, qui déterminent des répartitions de ressources et des structures de pouvoir importantes. Pour ces batailles, il faut les chefs d'armée les plus expérimentés et les combattants les plus flexibles et désireux d'apprendre.
La bataille dans cette histoire concerne les précieuses données d'entreprise, profondément enfouies dans des plateformes de données historiques. Il s'agit également d'un hommage à l'un des généraux les plus légendaires, auteur d'innombrables victoires glorieuses, ainsi qu'à son novice et bras droit : SQL et dbt.
Table des matières
- 1. pourquoi SQL est "old but gold" ?
- 2. quelles sont les faiblesses du légendaire chef d'armée SQL ?
- 3. qui est ce jeune novice nommé dbt ?
- 4. comment et où s'inscrit dbt dans ce contexte ?
- 5. architecture et principe de fonctionnement de dbt
- 6. qu'est-ce qui fait de dbt le bras droit idéal de SQL ?
- 7. à quoi le dbt peut-il ne pas convenir ?
- 8. conclusion
1. pourquoi SQL est "old but gold" ?
SQL et les systèmes de gestion de bases de données relationnelles (SGBDR) sont établis sur le marché depuis plusieurs décennies. Cela ne signifie toutefois pas qu'ils sont obsolètes, bien au contraire.
Au fil des décennies, notre sage chef militaire a été confronté à d'innombrables critiques, rivaux et adversaires, qu'il a tous surmontés. Cet article résume les éléments essentiels d'un travail fondamental réalisé par Google. Il y est mentionné que le langage SQL a d'abord été déclaré« obsolète », avant de revenir en force au fil des ans.
Ce phénomène ne se limite toutefois pas à Google, comme le rapportent Michael Stonebraker (lauréat du prix Turing et créateur de Postgres) et Andrew Pavlo dans cet article, également disponible sous forme de présentation. Ils démontrent que les SGBDR et le langage SQL s'adaptent aux technologies, principes et idées émergents, ce qui permet d'améliorer continuellement le produit. On pourrait donc dire que notre chef militaire apprend quelque chose de chaque adversaire qu'il vainc et acquiert ainsi de plus en plus d'expérience.
Au fil des décennies, des systèmes ont vu le jour, qui n'ont cessé de gagner en maturité et ont ainsi connu d'immenses évolutions. Cependant, ce ne sont pas seulement les SGBDR qui ont évolué, leur lingua franca SQL s'est également améliorée en permanence. Ainsi, BigQuery permet par exemple de traiter nativement des données semi-structurées sous forme de JSON. De plus, les charges de travail d'apprentissage automatique peuvent également être exprimées en SQL dans BigQuery. Grâce à leur soutien, même les données non structurées peuvent être traitées directement dans BigQuery. Cerise sur le gâteau, même des charges de travail exotiques telles que le traitement de données géographiques sont possibles, et tout cela de manière native via SQL. C'est pourquoi Google ne qualifie plus BigQuery de simple entrepôt de données, mais de « plateforme autonome de données et d'IA ».
Ce projet passionnant illustre parfaitement le large éventail d'opérations pouvant être réalisées avec SQL. Le célèbre jeu Tetris est implémenté en SQL afin de démontrer la complétude de Turing de SQL. Il s'agit d'une démonstration qui ne change pas le monde, mais qui montre clairement que SQL est si flexible qu'il permet également de réaliser des opérations pour lesquelles il n'a jamais été conçu. On peut donc imaginer les possibilités qui s'offrent dans le contexte pour lequel SQL a réellement été conçu, à savoir la transformation de données relationnelles. J'irais même jusqu'à affirmer qu'il n'existe aucune transformation de données qui ne puisse être exprimée en SQL.
Outre les progrès graduels réalisés au fil des ans dans le domaine des langages, certains développements ont également permis de mettre en œuvre, ou du moins de proposer, des changements et des améliorations fondamentaux. Un exemple en est la refonte fondamentale de la syntaxe SQL avec des pipes, déjà disponible dans Databricks et BigQuery. Une autre idée fascinante est la proposition de ce travail. Il souhaite mettre fin à la règle immuable selon laquelle le résultat d'une requête SQL doit obligatoirement être une seule relation/table. Au lieu de cela, un modèle de données complet peut être fourni comme résultat.
Ces deux aspects soulignent les efforts d'innovation continus visant à améliorer le langage SQL. Dans l'ensemble, les années pendant lesquelles le langage SQL et les SGBDR se maintiennent dans l'industrie ne peuvent donc pas être considérées comme un signe de vieillissement, mais plutôt comme une supériorité incontestable.
2. quelles sont les faiblesses du légendaire chef d'armée SQL ?
Les projets de préparation des données sont souvent considérés comme un effort ponctuel important, que l'on pourrait maîtriser en investissant suffisamment d'efforts dans une phase initiale d'analyse et de conception. Cependant, il y a toujours certains aspects qui ne sont pas connus à l'avance ou qui n'ont pas été pris en compte, et les exigences évoluent avec le temps. Dans la pratique, cette approche est donc généralement moins efficace qu'une approche itérative. Ce constat fait l'objet d'un consensus dans d'autres projets de développement logiciel, mais pas toujours dans les cas d'utilisation analytiques. Cela se reflète également dans les outils de développement basés sur SQL. Il est donc souvent difficile d'appliquer les pratiques établies du développement logiciel aux processus de traitement des données. Il s'agit notamment des pratiques issues du DevOps (contrôle de version, intégration continue et déploiement dans des environnements multiples, Automatisation des tests-Automatisation) et développement de logiciels (séparation des préoccupations, principe de responsabilité unique, réutilisation (DRY), abstraction et encapsulation)
Il existe certes une norme officielle pour SQL, dont l'objectif est de garantir la compatibilité du même code SQL pour différentes plateformes, mais cette norme n'est mise en œuvre à l'identique par aucun fournisseur de plateforme. De ce fait, les différentes plateformes ont leurs propres nuances, ce qui donne naissance à différents dialectes SQL. Il n'est donc pas garanti que la même requête SQL puisse être exécutée sur différentes plateformes.
De plus, certaines transformations sont certes assez simples à exprimer en SQL, mais elles ne peuvent être représentées qu'à l'aide de nombreuses étapes répétitives. On dit également qu'il nécessite beaucoupde « code boilerplate », c'est-à-dire qu'il faut écrire beaucoup de code pour implémenter des fonctionnalités mineures. C'est pourquoi ces fonctionnalités linguistiques sont également qualifiées de verboses. Cet exemple montre à quel point les transformations courantes peuvent être verboses et répétitives en SQL :
Dans ce cas, une clé de hachage unique ("supply_sk") est générée à partir des attributs "id" et "sku" d'une table. Outre la verbosité, cette méthode est également sujette aux erreurs et très probablement incohérente entre les différentes applications. Imaginez par exemple que vous souhaitiez modifier l'algorithme utilisé dans un projet à chaque fois qu'une clé de substitution est générée de cette manière. Cela consommerait inutilement beaucoup de ressources.
3. qui est ce jeune novice nommé dbt ?
Pour clarifier cette question, une digression sur les pipelines de données ou les processus ETL ou ELT est nécessaire. Ces deux termes décrivent un objectif similaire, à savoir gérer la situation suivante :
La quantité de données D dans le système S présente au moins l'un des deux problèmes suivants : soit D, dans sa forme actuelle, est difficile, voire impossible à utiliser à des fins spécifiques, c'est-à-dire que l'on souhaite modifier la structure de D en D'. Ou bien D se trouve tout simplement au mauvais endroit ou dans le mauvais système, c'est-à-dire que l'on souhaite modifier S. Ou les deux. En résumé : le « comment » (structure) ou le « où » (système) des données ne convient pas à un cas d'utilisation spécifique.
C'est pourquoi les données sont extraites d'un système (Extract = E), chargées dans un autre système (Load = L) et, le cas échéant, transformées/restructurées (Transform = T). Selon le moment où la transformation est effectuée, les acronymes ETL ou ELT apparaissent. Ces termes sont plutôt utilisés lorsque les données doivent effectivement être transférées d'un système à un autre. Mais que se passe-t-il si le système source et le système cible sont les mêmes ou si aucune transformation n'est effectuée ?
Le terme « pipeline de données » est une généralisation du processus ETL. Il décrit simplement un processus automatisé qui transfère des données d'une source vers une destination. La transformation des données est facultative. La source et la destination peuvent également être le même système. Un autre aspect généralement utilisé pour faire la distinction est que les processus ETL sont généralement basés sur des lots, tandis que les pipelines de données peuvent également fonctionner en temps réel ou en fonction d'événements.
4. comment et où s'inscrit dbt dans ce contexte ?
En résumé, dbt est un outil open source basé sur Python qui permet de transformer D en D' dans un SGBDR à l'aide de SQL. Cependant, comment cela fonctionne-t-il exactement ?
Une requête SQL est simplement une chaîne de caractères (string) qui doit suivre une syntaxe spécifique pour qu'un système spécifique (SGBDR) puisse la traduire en étapes de traitement concrètes.
Cela s'applique également aux sites web. Ceux-ci sont toujours basés sur un document HTML et un système spécifique (navigateur web) sait comment le traiter ou l'afficher. Cependant, la plupart des sites web ne sont pas statiques, mais présentent des contenus dynamiques, tels que des contenus spécifiques pour l'utilisateur connecté, qui peuvent être modifiés ou mis à jour pendant l'utilisation (au moment de l'exécution). Pour cela, on peut utiliser des moteurs de modèles, qui permettent de générer par programmation des contenus de documents textuels. Le moteur le plus répandu dans le contexte Python est Jinja.
C'est la première particularité de dbt : dbt utilise Jinja pour générer dynamiquement des requêtes SQL à l'exécution. Pour reprendre l'exemple de la clé de hachage ci-dessus : Dans le contexte dbt, cela se résumerait à ce qui suit :
Ces contenus dynamiques peuvent être aussi complexes que souhaité et vont de fonctionnalités simples à la création de tableaux complets. Ces fonctionnalités encapsulées peuvent être réutilisées à différents endroits afin d'éviter les doublons de code nuisibles (copier-coller). Un autre avantage majeur de dbt est son écosystème complet, qui comprend de nombreuses fonctionnalités de haute qualité, disponibles immédiatement et regroupées dans le hub dbt-package.
Une autre fonction clé de dbt exploite la propriété déjà mentionnée selon laquelle chaque requête SQL peut avoir autant de relations que souhaité en entrée, mais génère toujours une seule relation en sortie. Cette sortie pourrait alors servir d'entrée pour une nouvelle requête.
Il en résulte un graphe acyclique orienté (en anglais : Directed Acyclic Graph, DAG) qui représente le flux de données. Chaque nœud de ce diagramme correspond à une requête SQL. Dans le jargon dbt, on parle de modèle dbt.
Le résultat de chaque modèle dbt est représenté sous forme d'artefact dans la base de données (au sens large, vue ou tableau). dbt résout les références du modèle en références concrètes de la base de données au moment de l'exécution.
Le DAG détermine également l'ordre d'exécution des requêtes SQL. Les requêtes indépendantes les unes des autres sont traitées en parallèle afin de garantir un flux de données aussi efficace que possible. Ainsi, dbt se charge également de l'orchestration du flux de travail.
Cependant, dbt ne contient pas uniquement des modèles qui deviennent des artefacts de base de données, mais également d'autres concepts/ressources. Vous trouverez ci-dessous un aperçu de tous les types de ressources dbt possibles. À ce stade, nous nous concentrerons uniquement sur la deuxième plus importante : les tests dbt. L'un des principaux défis lors de la création de pipelines de données est de maintenir une qualité adéquate des données et des processus. L'une des mesures les plus prometteuses pour l'assurance qualité dans le développement de logiciels et les domaines connexes est la réalisation de tests automatisés. Cela comprend à la fois des tests portant sur les logiques mises en œuvre (tests de code) et des tests de qualité des données dans le cas des pipelines de données, où les données elles-mêmes sont vérifiées pour s'assurer qu'elles présentent les caractéristiques requises. Dans dbt, ces tests sont pris en charge en tant que fonctionnalités natives sous la forme de data_tests et unit_tests. Ces tests sont appliqués aux modèles dbt et exécutés après ceux-ci, de sorte que ces vérifications sont effectuées à chaque exécution du pipeline. Cela conduit à une amélioration significative de la transparence de la qualité et permet le développement de solutions plus stables, adaptées à un développement itératif et rapide. C'est pourquoi les tests dans dbt doivent être considérés comme une fonctionnalité essentielle (tests en tant que citoyens de première classe).
5. architecture et principe de fonctionnement de dbt
dbt-core définit l'étendue des fonctionnalités et des configurations pouvant être mises en œuvre avec dbt. Cette zone est également appelée « Authoring Layer » (couche de création). Si dbt doit être utilisé en combinaison avec un SGBDR spécifique, il doit exister un « dbt-adapter » (adaptateur dbt). Celui-ci définit comment une fonctionnalité particulière est mise en œuvre ou implémentée dans le système spécifique. Vous trouverez ici une liste des adaptateurs disponibles. Cela permet une définition aussi indépendante que possible de la plateforme des pipelines de données basés sur SQL. Comme mentionné précédemment, différents systèmes ont différents dialectes SQL, de sorte qu'un modèle dbt peut ne pas être exécutable sur deux plateformes différentes. Pour remédier à ce problème, dbt dispose d'un « Adapter Dispatch ». Cela permet de modifier dynamiquement les définitions dépendantes du système pendant l'exécution. Voici un exemple :
La macro « cents_to_dollars » peut être facilement utilisée dans le modèle dbt, comme illustré dans la capture d'écran ci-dessus. Si le flux de travail dbt est exécuté sur postgres, BigQuery ou MS Fabric, les implémentations spécifiques sont utilisées. Pour tous les autres adaptateurs/plateformes, la version par défaut est utilisée.
6. qu'est-ce qui fait de dbt le bras droit idéal de SQL ?
Un bon bras droit connaît les faiblesses de son maître et les compense autant que possible. Les explications ci-dessus devraient vous donner une idée de la manière dont dbt peut éliminer ou au moins atténuer les faiblesses de SQL décrites ci-dessus.
dbt permet à SQL d'appliquer les pratiques établies mentionnées ci-dessus issues du DevOps et du développement logiciel aux processus de traitement des données basés sur SQL. Cela permet d'atteindre un niveau de maturité totalement inédit. De plus, dbt facilite le développement de composants réutilisables qui encapsulent des logiques verbose ou complexes ainsi que des fonctionnalités linguistiques spécifiques à la plateforme et les gèrent de manière dynamique pendant l'exécution.
Vous trouverez ci-dessous une liste des principales fonctionnalités de dbt :
- Génération dynamique de code SQL au moment de l'exécution
- Orchestration du flux de travail (DAG)
- Créer de la transparence en gérant les dépendances des modèles (Data Lineage)
- Mécanismes d'assurance qualité intégrés (tests de données et d'unités en tant que priorités absolues)
- Utilisation des meilleures pratiques établies en matière de génie logiciel
- Indépendance de la plate-forme grâce au dispatching de l'adaptateur
- Open source comme base d'un écosystème étendu (par exemple dbt Package Hub) et d'extensions spécifiques propres
7. à quoi le dbt peut-il ne pas convenir ?
Bien que la combinaison de dbt et SQL soit puissante, il s'agit uniquement d'un outil conçu pour un usage spécifique.
"Si tout ce que vous avez est un marteau, tout ressemble à un clou" - Abraham Maslow
dbt est particulièrement adapté aux transformations de données non interactives (asynchrones), par lots, idempotentes et basées sur SQL. Pour les cas d'utilisation qui ne correspondent pas à cette description, dbt peut toujours être une solution envisageable, mais on sort alors de la zone de confort de dbt et d'autres outils pourraient peut-être mieux répondre à l'objectif visé. Par exemple, si un utilisateur souhaite configurer/paramétrer une transformation de données via une interface utilisateur, puis la lancer et attendre le résultat, d'autres outils peuvent être plus adaptés que dbt.
Une autre faiblesse de dbt est qu'il ne considère les requêtes SQL que comme des chaînes de caractères et n'a aucun moyen d'interprétation pour détecter les erreurs à un stade précoce.
La société d'origine de dbts, dbt Labs, a reconnu cette lacune et y a répondu avec un tout nouveau produit. Ce dernier est encore en phase bêta profonde au moment de la rédaction de cet article.
8. conclusion
SQL et les plateformes de données modernes (RDBMS) sont le résultat de plusieurs décennies de recherche et développement. Il s'agit de systèmes difficilement surpassables.
dbt exploite ces grandes évolutions, les place dans le contexte des meilleures pratiques de développement logiciel modernes et corrige de nombreuses faiblesses de SQL. Il convient de souligner en particulier les possibilités étendues d'automatisation des tests avec assurance qualité intégrée.
Cette combinaison est un rempart qui devrait rendre les futures batailles pour les précieuses données d'entreprise beaucoup plus victorieuses.
Votre contact au sujet de SQL & dbt
