Interopérabilité des outils de dataviz avec le SQL

 

Interopérabilité 

des outils de dataviz avec le SQL

 

Dans le monde actuel de la gestion des données, les informations sont souvent réparties sur différentes plateformes de dataviz au gré des besoins métiers, des enjeux techniques, des contraintes budgétaires, etc.

 

Pour optimiser la gestion et l'utilisation de ces données, une approche d'interopérabilité basée sur SQL peut permettre de rétablir les outils de dataviz dans ce qu’ils sont au départ : des outils de "visualisation" - pas des outils de data prep’ qu’ils ont eu tendance à devenir, créant un surcroît dommageable d’opacité et d’inertie. 

 

Ça peut être un trait d'union pertinent dans le cadre d'une migration, pour la modernisation durable d'une plateforme. 

 
 

Le SQL comme modèle pivot

L'approche que nous proposons consiste à utiliser le SQL comme point de pivot pour moderniser les data platforms.  Ce SQL sera le réceptacle de l'intelligence de la plateforme à décommissionner.

 

L'intelligence contenue dans la ou les plateformes source pourra devenir commune à diverses plateformes de dataviz, actuelles ou futures. 

 

Dans cette logique, nous avons développé un moteur agnostique de génération de SQL au départ de différentes technologies de dataviz, permettant une migration "As Is" de toute l'intelligence vers du SQL.

 

Notre moteur est opérant pour les technologies suivantes (d'autres à l'étude) :  

 

Mais comment migrer vers du SQL ?

 

Introspection de la technologie source

Notre logiciel {openAudit} récupère des informations structurantes telles que la liste des expressions et variables utilisées, leur niveau d'imbrication, les fonctions utilisées dans ces expressions, les requêtes SQL, les champs et tables utiles, les jointures, les SQL personnalisés, les contextes et les prompts utilisés dans les dashboards, etc.

 

Migration en SQL

À partir de ces informations, {openAudit} génère du SQL pour construire les pipelines de données dans la base de données cible. Le SQL généré depuis la technologie de dataviz en source sera transposé dans la base de données cible, que ce soit Azure SQL, BigQuery, Redshift, etc. 

 

Les bénéfices attendus 

 

Migration de l’intelligence vers la base de données cibles

En créant dans la base de données cible une couche de données métier, multiplateforme, via de nouveaux pipelines en simple SQL "à plat", la technologie de dataviz utilisée pourra se contenter de requêtes simples. Cela améliorera les performances et facilitera les migrations futures.

 

De la dataviz, seulement de la dataviz

Les équipes qui travaillent sur la représentation des données pourront se concentrer sur la création de rapports et de tableaux de bord sans se soucier des transformations de données, avec des modèles simples, explicites.

 

Une maintenance mutualisée pour plusieurs outils

La centralisation des requêtes SQL simplifiera la maintenance de la couche de dataviz. Les mises à jour et modifications pourront être effectuées directement au niveau de la base de données, sans interventions complexes sur plusieurs plateformes.

 

Des performances largement améliorées

En déplaçant la complexité de la couche de dataviz vers du simple SQL au sein des bases de données, on améliorera mécaniquement les performances. L’intelligence pourra être factorisée et les données persistées, réduisant ainsi les temps de latence de certains outils de dataviz. D'autant que les bases de données des hyperscalers sont particulièrement efficaces et peu gourmandes en ressources.

 

Conclusion 

 

L'approche d'interopérabilité basée sur SQL permet de créer une architecture de données flexible et scalable.

 

En centralisant l'intelligence des données en simple SQL, les entreprises peuvent maximiser l'efficacité de leurs équipes de dataviz tout en garantissant une qualité et une cohérence des données. D'autant que ce mouvement peut être complètement automatisé.

 

Commentaires

Posts les plus consultés de ce blog

La Data Observabilité, Buzzword ou nécessité ?

BCBS 239 : L'enjeu de la fréquence et de l'exactitude du reporting de risque

Le data lineage, l’arme idéale pour la Data Loss Prevention ?