Data lineage — principes techniques |

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.

Data lineage - les principes de la conteneurisation des connecteurs

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

L’architecture {openAudit} repose sur des composants conteneurisés déployés dans l’environnement du Client.

Chaque composant est spécialisé pour une technologie donnée et assure la collecte des métadonnées nécessaires à la reconstruction du data lineage : bases de données, plateformes ETL/ELT, outils de data visualisation et bases d’audit.

Les extracteurs produisent des fichiers CSV standardisés contenant les métadonnées collectées. Ces fichiers peuvent être contrôlés par le Client avant leur transfert vers les composants centraux de traitement.

Lorsqu’une anonymisation est requise, un conteneur dédié est inséré dans la chaîne de collecte afin de remplacer les chaînes de caractères, constantes SQL et autres informations sensibles par des variables avant la production des fichiers d’échange.

Point clé : les extracteurs et les anonymiseurs sont découplés des moteurs de traitement. Chaque composant peut être déployé et mis à jour indépendamment.

Principes techniques

Un conteneur dédié par technologie.
Collecte des métadonnées au plus près des systèmes analysés.
Anonymisation optionnelle avant transfert.
Production de fichiers CSV standardisés.
Compatibilité Docker, Podman.
Déploiement On-Premise, SaaS ou hybride.
Mise à jour indépendante des composants.

Extraction

Les extracteurs se connectent aux technologies analysées à l’aide de comptes de service dédiés.

Les métadonnées collectées concernent :

Les bases de données.
Les plateformes ETL / ELT.
Les outils de datavisualisation.
Les bases d’audit.
Le scheduleur.

Chaque extracteur produit un format de sortie homogène indépendamment de la technologie analysée.

Anonymisation

Un conteneur d’anonymisation peut être positionné entre la collecte et le transfert des métadonnées.

Les éléments suivants peuvent être remplacés par des variables techniques :

Chaînes de caractères.
Paramètres applicatifs.
Valeurs littérales.

L’objectif est de conserver les dépendances techniques tout en supprimant les informations sensibles.

Point clé : l’anonymisation intervient avant la génération des fichiers transférés.

Fichiers d’échange

Les composants produisent des fichiers CSV standardisés contenant :

Les objets techniques.
Les dépendances.
Les transformations.
Les informations d’usage lorsque celles-ci sont disponibles.

Ces fichiers peuvent être archivés, contrôlés ou validés par le Client avant leur transfert.

Traitement

Les fichiers produits sont exploités par les composants centraux de {openAudit} pour :

Reconstruire les dépendances.
Consolider les métadonnées.
Intégrer les usages issus des logs d’audit.
Et produire le data lineage.

Résultat : une chaîne de collecte homogène, indépendante des technologies analysées et des modes de déploiement.

Data lineage - protocoles de connexion aux différentes technologies analytiques

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

L’acquisition des métadonnées repose sur les interfaces natives exposées par les technologies analysées par {openAudit}.

Selon les plateformes, les collectes utilisent des protocoles de base de données, des API REST, des SDK, des référentiels techniques ou des exports standardisés.

Point clé : les collecteurs utilisent les mécanismes officiellement exposés par les éditeurs (JDBC, ODBC, API REST, SDK, référentiels techniques, exports).

Principes techniques

Comptes de service dédiés.
Accès limité aux métadonnées.
Compatibilité On-Premise, Cloud et hybride.
Utilisation des interfaces natives des plateformes.
Chiffrement des mots de passe après première utilisation.

Bases de données

Les bases relationnelles sont analysées via :

JDBC.
ODBC.
Connecteurs propriétaires.

Les collectes portent sur :

Schémas.
Tables.
Vues.
Procédures stockées.
Statistiques d’usage (lorsque analysés).

ETL / ELT

Les plateformes ETL/ELT sont analysées via :

Référentiels techniques.
API d’administration.
Exports XML ou JSON.

Les métadonnées collectées permettent de reconstruire :

Les jobs.
Les transformations.
Les dépendances.
Les flux de données.

Outils de Data Visualisation

Les outils de data visualisation sont analysés via :

SDK.
API REST.
Référentiels internes.

Les collectes portent sur :

Les sources de données.
Les couches sémantiques.
Les dashboards.
Les règles de gestion.

Ces informations permettent de prolonger le data lineage jusqu’à la couche de restitution.

Usage typique : faire du data lineage dans les sources et le relier au data lineage dans la couche de data visualisation, jusqu’à la cellule du dashboard.

Environnements sécurisés

Les collectes peuvent être supervisées de façon sécurisée via :

VMware Horizon.
OpenOTP (double authentification).
Bastion d’administration.
Journalisation et traçabilité des opérations.

Les accès restent limités aux composants nécessaires à la collecte des métadonnées.

Pour information : même mécanisme de collecte en environnement Cloud, On-Premise ou hybride.