Migration DataViz - une couche sémantique interopérable - {oa-lake-ctx}

Thu, 02 Jul 2026 00:00:00 +0000

Les plateformes décisionnelles historiques reposaient généralement sur une couche sémantique permettant aux utilisateurs de manipuler des objets métier plutôt que des tables ou des requêtes SQL.

“Clients”, “contrats”, “produits” ou “chiffre d’affaires” étaient exposés sous une forme fonctionnelle indépendante des structures physiques de stockage.

Pour répondre à ce besoin, nous avons conçu {oa-lake-ctx}.

{oa-lake-ctx} constitue la couche sémantique de l’architecture {oa-lake}. Elle centralise les objets métier, les dimensions, les mesures, les KPIs, les règles de calcul et les mécanismes de sécurité.

Point clé : les outils consommateurs manipulent des objets métier. Les structures physiques restent masquées.

Architecture

{oa-lake-ctx} centralise les dimensions, mesures, hiérarchies, KPI et règles de calcul.

Ces composants sont définis une seule fois puis exposés aux outils consommateurs.

Contrairement à certaines couches sémantiques du marché, {oa-lake-ctx} ne nécessite ni modèle physique spécifique, ni table pivot, ni chemin de navigation imposé.

Les relations sont calculées dynamiquement à partir du modèle existant.

Point clé : un modèle métier unique pour toutes les données et tous les outils consommateurs.

Sources de données

{oa-lake-ctx} peut exploiter simultanément plusieurs systèmes de données.

Les données peuvent provenir de bases Oracle, SQL Server, PostgreSQL, DB2, Snowflake, BigQuery, Redshift, fichiers ou autres sources compatibles SQL.

Les objets métier peuvent combiner plusieurs sources dans une même définition fonctionnelle.

Usage typique : construire un KPI à partir de données réparties sur plusieurs plateformes.

Objets métier

Les catalogues exposés par {oa-lake-ctx} regroupent les dimensions, mesures, KPI, hiérarchies et nomenclatures métier.

Les relations entre objets sont définies dans la couche sémantique et non dans les outils de restitution.

Les catalogues peuvent être organisés indépendamment des structures physiques des bases de données.

Génération SQL

Les requêtes SQL sont générées dynamiquement à partir des objets métier, dimensions, mesures et filtres sélectionnés.

Les jointures, agrégations et règles de calcul sont appliquées par le moteur.

Les filtres utilisateurs sont propagés jusqu’aux systèmes sources via le mécanisme de Push-Down SQL : pas de copie systématique des données, les requêtes sont exécutées sur les systèmes existants, dans le respect des architectures en place.

Le SQL généré peut être exécuté par {oa-lake} ou par tout moteur SQL compatible.

Point clé : les utilisateurs manipulent des objets métier ; le SQL est généré automatiquement.

Smart Cache

Les données restent dans les systèmes sources lorsque cela est possible.

Les jeux de données les plus sollicités peuvent être matérialisés au format Parquet.

Le cache est piloté par le Cache Manager de {oa-lake}, géré automatiquement selon les usages observés.

La gestion du cache reste indépendante des outils consommateurs.

Point clé : les requêtes les plus coûteuses peuvent être accélérées sans modifier les systèmes sources.

SQL Engine

{oa-lake} s’appuie sur un moteur SQL columnar et in-memory.

Les requêtes générées par {oa-lake-ctx} sont exécutées par ce moteur ou propagées vers les systèmes sources selon le contexte.

Le SQL reste portable, standard et exécutable sur différents moteurs, indépendant des technologies de stockage utilisées — ce qui limite le lock-in technologique.

Point clé : le moteur SQL constitue la couche d’exécution de l’architecture.

Sécurité

La sécurité est gérée au niveau de la couche sémantique.

Les restrictions d’accès, profils utilisateurs, catalogues métier et filtres de sécurité sont appliqués avant génération des requêtes.

Cette approche permet de reproduire les mécanismes de sécurité rencontrés dans des plateformes telles que SAP BusinessObjects ou IBM Cognos.

Point clé : les règles de sécurité sont définies une seule fois puis appliquées à tous les outils connectés.

Restitution

Les catalogues exposés par {oa-lake-ctx} peuvent être consommés par tout outil capable d’interroger une source PostgreSQL.

Power BI, Looker, Spotfire, Tableau, Qlik ou d’autres plateformes accèdent aux mêmes objets métier, dimensions, mesures et KPI.

Les définitions fonctionnelles restent identiques quel que soit l’outil utilisé.

Résultat : plusieurs plateformes peuvent partager le même catalogue métier sans duplication des règles de calcul.

Gouvernance

Les objets métier, KPI, dimensions, mesures et règles de calcul sont centralisés dans un référentiel unique.

Les évolutions fonctionnelles sont réalisées dans {oa-lake-ctx} puis immédiatement disponibles pour les outils connectés.

Point clé : {oa-lake-ctx} constitue le point central de définition des objets métier et des KPI.

Data lineage - alimentation des data catalogues tiers pour exposer son data lineage technique

Thu, 02 Jul 2026 00:00:00 +0000

{openAudit} permet la consultation du data lineage via son portail Web Mosaïc, mais les métadonnées consolidées peuvent également être publiées vers différents data catalogues du marché qui présentent souvent de fortes limitations pour ce qui concerne le data lineage. L’intérêt est de n’avoir qu’un outil pour une data governance optimale.

Le data lineage est reconstruit dans le référentiel technique {openAudit}, puis exposé vers les catalogues de données via des connecteurs dédiés.

Cette architecture permet de dissocier les mécanismes de collecte et de reconstruction du data lineage de la couche d’exposition utilisée par les équipes de gouvernance.

Point clé : le référentiel technique reste indépendant du catalogue cible. Les mécanismes de collecte et de reconstruction du lineage (et de connexion) ne dépendent pas du data catalogue utilisé.

Architecture

Les métadonnées collectées sont consolidées dans la base de données colomnar oA.mdb après traitement par le moteur oA.Job.

Le référentiel central contient notamment :

Le data lineage au champ.
Les usages.
Les informations de gouvernance associées le cas échéant.

Les catalogues sont ensuite alimentés à partir de ce référentiel unique via des connecteurs d’exposition indépendants des solutions de data catalogue.

Connecteurs d’exposition

Les connecteurs assurent :

La publication automatisée du lineage.
Les synchronisations continues.
La gestion des restrictions.
Le support des différents Workspaces.

L’exposition du data lineage peut être complète ou partielle selon les capacités d’affichage du catalogue cible, sachant que le data lineage produit en amont est, lui, disponible au champ.

Résultat : les catalogues ne consomment que les métadonnées consolidées et non les sources techniques d’origine.

Catalogues supportés

Les connecteurs disponibles permettent à ce jour d’alimenter les data catalogues suivants :

DataGalaxy
Zeenea
Collibra

Gestion des usages

Lorsque les logs d’audit sont disponibles, les usages observés sont intégrés au référentiel technique puis exposés vers le catalogue.

Les utilisateurs peuvent ainsi distinguer :

Les flux “vivants”, consommés par des outils ou requêtés.
Les flux et donc les objets non consommés (souvent plus de 80 % de l’ensemble).

Usage typique : enrichir le data catalogue avec des informations d’usage afin d’identifier les objets candidats à la rationalisation ou au décommissionnement.

Gouvernance |

Migration DataViz - une couche sémantique interopérable - {oa-lake-ctx}

Architecture

Sources de données

Objets métier

Génération SQL

Smart Cache

SQL Engine

Sécurité

Restitution

Gouvernance

Data lineage - alimentation des data catalogues tiers pour exposer son data lineage technique

Architecture

Connecteurs d’exposition

Catalogues supportés

Gestion des usages