data-lineage-decomposed-article-zeenea

Le Data Lineage décomposé : typologies et granularité du lineage

novembre 2, 2021

Le sujet de Data Lineage semble universel : quel que soit le secteur d’activité, toutes les parties prenantes dans une organisation Data cherchent à connaître l’origine et la destination des données qu’elles sont amenées à manipuler ou interpréter. 

La capacité à gérer le Data Lineage est donc une composante incontournable pour une solution de Data Catalog. Mais comme souvent, derrière une question simple et universelle se cache un monde de complexité difficilement appréhensible. Cette complexité est en partie liée à l’hétérogénéité de la réponse attendue en fonction du prisme de l’interlocuteur dans l’entreprise. Nous vous exposons dans cet article notre approche pour décomposer le data lineage en fonction de la nature de l’information recherchée et de sa granularité.

 

Typologie du Data Lineage : à la recherche de l’origine de la donnée

La question de l’origine d’une donnée possède de nombreuses réponses. Certains voudront connaître la formule de calcul ou la sémantique exacte de la donnée. D’autres voudront savoir de quel(s) système(s), de quelle(s) application(s) ou de quelle(s) machine(s) ou usine elle est issue. D’autres encore s’intéresseront aux processus métiers ou opérationnels qui ont produit la donnée. Ou encore à toute la chaîne de traitement technique amont et aval. Difficile de faire le tri dans ce maquis de considérations très diverses !

Une approche par couche

Pour structurer l’information de lineage, nous proposons, à l’instar de ce qui se pratique dans le domaine de la géocartographie, de distinguer plusieurs couches superposables. 

Nous en identifions trois :

  • La couche physique, qui va comprendre les objets du système d’information – applications, systèmes, bases, jeux de données, programmes d’intégration ou de transformation, etc.
  • La couche métier, qui va contenir les éléments organisationnels – domaines, processus ou activités métier, entités, responsables, contrôles, comités, etc.
  • La couche sémantique, qui va s’intéresser à la signification des données – formules de calcul, définitions, ontologies, etc.
data-lineage-layers-FR-zeenea

Focus sur la couche physique 

La couche physique constitue le canevas de base sur lequel vont pouvoir s’ancrer les autres couches. Cette approche est une nouvelle fois similaire à ce qui se pratique en matière de cartographie : au-dessus de la carte physique, il est possible de superposer d’autres couches portant des informations spécifiques.

La couche physique représente par ailleurs la dimension technique du lineage ; elle est matérialisée par des artefacts techniques tangibles – bases de données, systèmes de fichiers, middlewares d’intégration, outils de BI, scripts et programmes, etc. En théorie, la structure du lineage physique peut donc être extraite de ces systèmes, et donc en grande partie automatisée, ce qui n’est généralement pas le cas des autres couches.

Un point est fondamental : pour que cette approche bottom up fonctionne, il est nécessaire que le lineage physique soit exhaustif.

Cela ne signifie pas que le lineage de tous les objets physiques soit disponible, mais que pour ceux qui en disposent, le lineage soit complet. Et cela pour deux raisons. D’une part, un lineage partiel (donc faux) risque d’induire celui qui le consulte en erreur, mettant en péril l’adoption du catalogue. D’autre part, la couche physique servant de point d’ancrage aux autres couches, ses lacunes se propagent.

En complément de cette représentation en couches superposables, abordons l’autre aspect fondamental du lineage : celui de sa granularité.

 

Granularité du Data Lineage

En matière de granularité du lineage, nous distinguons 4 niveaux distincts : la valeur, le champ (ou la colonne), le jeu de données et l’application.

Le niveau valeur peut être abordé rapidement. Il s’agit, pour une donnée particulière (on parle ici d’une valeur spécifique, pas de la définition d’une donnée), de connaître toutes les étapes qui ont permis de la calculer. Pour des applications de pricing mark-to-model par exemple, le lineage du prix doit comprendre toutes les données brutes (horodatage, fournisseur, valeur), les valeurs dérivées de ces données brutes ainsi que les versions de tous les algorithmes utilisés dans le calcul.

Des exigences réglementaires ou contractuelles existent dans de nombreux domaines (banque, finance, assurance, santé, pharmaceutique, IOT, etc.), mais de façon généralement très localisée. Elles sont clairement hors de portée pour un Data Catalog, dans lequel il est difficilement imaginable de gérer chaque valeur de données ! Répondre à ces exigences nécessite soit un progiciel spécialisé, soit un développement spécifique.

Les 3 autres niveaux concernent des métadonnées, et sont quant à eux clairement du domaine d’un Data Catalog. Détaillons-les rapidement.

Le niveau champ est le niveau le plus fin. Il s’agit, pour une information présente dans un jeu de données (table ou fichier), un rapport, un tableau de bord, etc., de tracer toutes les étapes (au niveau physique, métier ou sémantique) permettant d’alimenter le champ en question.

Au niveau dataset ( jeu de données), le lineage est défini non plus pour chaque champ mais au niveau du conteneur du champ, qui est typiquement une table dans une base de données, un fichier dans un data lake, une API, etc. On représente à ce niveau les étapes qui permettent d’alimenter le jeu de données dans son ensemble, typiquement à partir d’autres jeux de données (on retrouve à ce niveau d’autres artefacts, tels que des rapports, des tableaux de bord, des modèles ML voire des algorithmes)

Enfin, le niveau application permet de documenter le lineage de façon macroscopique, en s’attachant aux éléments logiques de haut niveau dans le système d’informations. Le terme application est ici utilisé de façon générique pour désigner un regroupement fonctionnel de plusieurs jeux de données.

On pourrait bien sûr imaginer d’autres niveaux supérieurs (regrouper par exemple les applications dans des domaines métiers), mais complexifier davantage relève plus de la cartographie des flux que du lineage…

Enfin, chaque niveau s’imbrique dans le niveau supérieur, avec pour conséquence que le lineage du niveau supérieur peut être déduit de celui du niveau inférieur (si je connais le lineage de tous les champs d’un dataset, alors je peux déduire le lineage de ce dataset).

Nous espérons que cette décomposition du data lineage vous permettra de mieux l’appréhender dans votre organisation. Dans un prochain article, nous partagerons notre approche pour que chaque métier puisse tirer un maximum de valeur du Lineage grâce à notre matrice typologie / granularité / métier.

 

Pour en savoir plus sur les bonnes pratiques du Data Lineage, téléchargez dès maintenant notre eBook : Tout ce que vous avez toujours voulu savoir sur le Data Lineage !

    data-lineage-white-paper-mockup-fr

    zeenea logo

    At Zeenea, we work hard to create a data fluent world by providing our customers with the tools and services that allow enterprises to be data driven.

    zeenea logo

    Chez Zeenea, notre objectif est de créer un monde “data fluent” en proposant à nos clients une plateforme et des services permettant aux entreprises de devenir data-driven.

    Be(come) Data Fluent

    Read the latest trends on big data, data cataloging, data governance and more on Zeenea’s data blog.

    Join our community by signing up to our newsletter!

    Devenez Data Fluent

    Découvrez les dernières tendances en matière de big data, data management, de gouvernance des données et plus encore sur le blog de Zeenea.

    Rejoignez notre communauté en vous inscrivant à notre newsletter !

    Let's get started
    Make data meaningful & discoverable for your teams
    Learn more >
    Démarrez maintenant
    Donnez du sens à votre patrimoine de données
    En savoir plus >