SQL & SQLOps au service de la transformation numérique

SQL & SQLOps au service de la transformation  numérique

Le code procédurale SQL et ses dérivés ont été marginalisés au profit des ETL / ELT dans les infras "on premise".   Les ETL/ELT ont foisonné dans les entreprises ces 30 dernières années, avec en idée première de rendre accessible le déploiement de "data pipelines" à des profils moins techniques. Il était aussi question de faciliter les analyses d’impact, d’avoir du versioning, de faciliter le monitoring des flux, de pouvoir répliquer les Jobs, etc. Avec le Cloud, le SQL revient "en majesté" pour de nombreuses et très bonnes raisons.  Et on voit aussi apparaître des solutions orientées SQLOps qui "augmentent" le SQL en l'encapsulant dans des outils qui offrent des garanties supplémentaires.   Mais comment opérer une transition précise de DataStage, Talend, BODS, SSIS... , vers du "simple" SQL ou vers des outils orientés SQLOps ?

La résilience du SQL

Notre expérience nous montre que les développeurs ont souvent continué à modéliser les flux en SQL avant des les construire avec l’ETL en place.

Pourquoi ?

Les développeurs ont souvent une relation forte avec le langage SQL : le SQL offre une manière naturelle de décrire et de comprendre les relations et les schémas de données.

L'utilisation de requêtes SQL permet de tester rapidement des transformations de données directement dans la base de données.

L’utilisation du SQL permet aux applications de gérer les données sans se soucier du stockage sous-jacent, ce qui simplifie le déploiement sur différentes plateformes Cloud.

En somme, le SQL, c’est la simplicité, l’efficacité, la scalabilité.   "Le monde de demain" est largement tourné vers le SQL, avec pour preuve un retour massif du SQL et de ses "dialectes" pour gérer le processing de la donnée chez les hyperscalers : Redshift SQL chez AWS, BigQuery chez GCP, ou le T-SQL dans Azure. Comme souvent, on a donc tendance à réinventer ce qu'on avait un peu oublié .   Mais le SQL a encore les limites qui étaient les siennes auparavant : On peut se retrouver avec un foisonnement de code difficilement maintenable. Et plus le système sera imposant, plus il y a aura besoin d'expertise, ce qui qui ne va pas dans le sens d'architectures orientées domaines ("data mesh"), visant à donner au métier un usage intensif et extensif de la donnée.   ...

Et les  solutions orientées SQLOps ?

Les solutions orientées SQLOps encapsulent du SQL. Elles permettent aux data analystes d'écrire du code SQL pour définir les transformations, pour les tester, pour les documenter et pour les exécuter de manière reproductible. En somme, elles proposent des fonctionnalités qui allient la simplicité du SQL avec un véritable outil de contrôle. Les plus connues de ces solutions sont dbt, dbForge Studio, ou encore Dataform de Google.

Les attributs principaux de ces outils :

Ils favorisent une approche modulaire du développement de données, en permettant la création de packages réutilisables. Cela simplifie la maintenance, la mise à jour et la gestion des transformations de données.

La documentation est générée automatiquement à partir des métadonnées des requêtes SQL.

Ces outils intègrent des fonctionnalités de tests automatisés.   .....

Migrer ?

Que vous vouliez migrer vers du simple SQL, vers un "dialecte" de SQL, ou vers une solution type dbt, il faudra être en capacité de "déconstruire" tout ce que votre ETL /ELT embarque de façon efficace, en le transposant dans la technologie cible. Ça peut être très compliqué, très long, très cher.

Nous proposons une méthode en 2 étapes :

1. Simplifier le système en source :  Le data lineage granulaire de {openAudit}, notre logiciel, couplé aux usages de l’information, permettra d’identifier et d'écarter les « branches mortes », i.e. les data pipelines qui sont rejoués continuellement mais qui produisent des données qui ne sont jamais consultées. C'est souvent plus de 50 % des systèmes.   A voir aussi :  Baisser les coûts du Cloud

2. "Traduire" les jobs ETL :  La très forte capacité d’introspection d’{openAudit}, en particulier pour ces qui concerne les ETL/ELT présents dans les systèmes legacy (DataStage / BODS / SSIS / Talend…), permet de faire un inventaire exhaustif et dynamique de l’ensemble des actions qui viennent agir sur la donnée. {openAudit} va « traduire » ces instructions en simple SQL ; Ce SQL sera enrichi avec un exécutable pour le faire "adhérer" le plus précisément possible à la technologie cible (BigQuery, Redshift, Azur SQL, etc.) ;  Pour une migration vers dbt (par exemple), {openAudit} ira encapsuler ce SQL dans les jobs dbt.

L'ensemble de ces mécanismes de migration va être automatisé.  Par ailleurs, les vues, les vues de vues, les procédures dynamiques, les flux gérés avec du code procédural seront repris dans la cible, selon l'articulation de la source.

Conclusion    Le SQL joue un rôle central dans l'environnement Cloud, tant au niveau des bases de données que dans l'évolution des méthodes ETL, vers des approches plus flexibles et adaptées au Cloud. L'utilisation judicieuse de dialectes SQL spécifiques aux bases de données Cloud et l'adoption des outils orientés SQLOps peuvent contribuer à optimiser la gestion des données dans ces environnements dynamiques. D’aucuns aimeraient avancer dans cette direction, mais la migration n’est pas simple. Sauf à automatiser les processus.    A voir aussi :  Migrer de SAP BO vers Power BI