Le SQL pour automatiser la migration de la couche de DataViz

 

Le SQL pour automatiser la migration de la couche de DataViz

De nombreuses entreprises souhaitent décommissionner telle ou telle technologie de data visualisation pour partir vers des technologies plus pérennes, plus en adéquation avec les plateformes Cloud du moment : Azur, AWS, GCP...   Ces migrations sont à haut risque compte tenu de la complexité des plateformes. Et quand bien même la migration a pu avoir lieu, l’output peut présenter d’emblée des pathologies rédhibitoires pour les métiers et pour l’IT : lenteur, complexité, lourdeur de la maintenance. Et le « divorce » avec la solution de dataviz en source coûte suffisamment cher pour ne pas s'imposer un "mariage" ad vitam avec une nouvelle technologie de dataviz 😊.    Nous avons développé un moteur agnostique de génération de SQL qui va permettre une migration "As Is", de la couche de dataviz en source, vers du SQL.   Ce SQL va être transposé dans la base de données en source de la technologie cible (Azure SQL, BigQuery, Redshift, etc.).     En somme, il s’agira de générer dans la base de données cible, via de nouveaux data pipelines en SQL "à plat", une couche de données très "métier" et par essence multiplateforme.   La technologie de dataviz cible ne fera du coup que des requêtes simples sur ces données. L’efficacité n'en sera que meilleure. Et les migrations futures ne seront que plus simples. Ces projets sont proposés au forfait.

L’intérêt de "pivoter" par du SQL

Performances améliorées En déplaçant toute la complexité inhérente à la couche de dataviz vers du simple SQL au sein des bases de données, on dope mécaniquement les performances : l’intelligence peut être factorisée et les données persistées. Ainsi, on assiste à une réduction massive des temps de latence. L’expérience utilisateur devient plus fluide.

Simplicité de maintenance La gestion centralisée des requêtes SQL simplifie la maintenance de la couche de dataviz. Les mises à jour et les modifications peuvent être effectuées directement au niveau de la base de données, évitant ainsi des interventions complexes sur plusieurs plateformes, avec à chaque fois des équipes différentes. Comme il s’agira de simple SQL, la maintenance sera à la portée du plus grand nombre.

Consolidation des ressources En migrant vers des data pipelines en SQL simple qui génèrent des jeux de données mutualisées, on évite la prolifération des outils de data visualisation répondant à telle ou telle exigence du métier. Cela permet de simplifier la gestion des licences, la formation des utilisateurs et la supervision des performances. Il est ainsi possible de consolider les ressources et d’optimiser les infrastructures.

Scalabilité accrue L'intégration de la complexité de la couche de datavisualisation dans la base de données améliore la scalabilité du système. Un DWH chez un hyperscaler est conçu pour gérer plus efficacement une croissance importante du volume de données, tout en maintenant des performances optimales, garantissant ainsi la pérennité des solutions de dataviz.

Sécurité Le SQL "à plat" (sans subqueries) permet de rendre le code plus lisible et plus facile à maintenir : il est possible d’avoir un contrôle direct sur les conditions et les filtres appliqués aux données sans avoir à naviguer entre plusieurs niveaux de requêtes imbriquées. Cela rend la vérification et la modification des critères de sélection plus aisée. La sécurité de la base de données, qui est souvent optimale, est mutualisée pour l’ensemble des solutions de dataviz qui se nourrissent de ces pipelines.

Techniquement   Introspecter la technologie en source de façon ultra granulaire   {openAudit} notre logiciel va récupérer les informations suivantes :

Au niveau de l'intelligence des dashboards en source : La liste des expressions et des variables utilisées, et leur niveau d'imbrication ;  La liste des fonctions utilisées dans ces expressions et ces variables.

Au niveau des sources :  Les requêtes SQL, et donc la liste des champs et des tables utiles ; La liste des jointures pour relier ces tables ; La définition des SQL personnalisés ; Les contextes utilisés ; La liste des prompts utilisés dans les dashboards.

Migrer   Au départ de ces informations, {openAudit} va générer du SQL pour construire les pipelines de données dans la base de données en cible, tout en factorisant l’intelligence.   (A noter :  généralement nous proposons de simplifier la plateforme source avant migration).

Conclusion    Les migrations d’outils de dataviz sont un casse-tête. Nous proposons des migrations "As Is" tout en permettant de "dompter" la complexité, en la recentrant là d'où elle n'aurait peut-être pas dû sortir, le DWH.    Notre très forte capacité à introspecter la plupart des technologies de datavisualisation nous permet de proposer ce moteur de translation de la couche de dataviz vers du SQL. Ça permettra de repartir sur des bases saines et pérennes. Nous proposons ce type de projet au forfait pour permettre aux entreprises clientes de cadrer leurs projets précisément.