Lignage des données

Nejat ARINIK

Département Informatique

INSA de Lyon

2015/2016

Sous la responsabilité de :

Eric SIMON : SAP

Philippe LAMARRE : Département Informatique

Résumé. Il devient de plus en plus difficile d'avoir une vision globale des données depuis une grande

quantité des données sont stockées dans les bases de données pour le Big Data et l’informatique

décisionnelle. Une des solutions peut être de déterminer d’où les données viennent et par quelles

transformations les données sont dérivées. Ce problème est connu sous la notion de lignage des

données. Dans ce travail, nous nous intéressons au lignage des données au niveau du schéma qui est

considéré comme une première étape avant de faire une analyse de lignage au niveau des données. Il

est basé sur l’analyse des opérations de transformations utilisées pour produire les données à partir

des données source de base. Il permet ainsi une meilleure compréhension sur la sémantique des

données. De plus, notre approche présente les informations de lignage sous une forme adaptée au rôle

de l’utilisateur (développeur ou utilisateur métier).

Mots-clés : lignage des données, analyse orientée utilisateur, gestion de métadonnées

Abstract. It is becoming more difficult to have a global view of data and to manage it since large

amount of data is stored for big data and business intelligence purposes. One of the solutions can be

to determine where data comes from and through what transformations the data derived. This problem

is known as data lineage or data provenance. In this work, we are interesting in schema-level data

lineage which is considered as the first step before doing lineage analysis at data-level. It uses schema

elements and transformations, and it can provide a better understanding of the semantics of data.

Moreover, this work conducts a user-oriented data lineage in order to distinguish different users:

Developers/designers and business users.

Key-words : data lineage, user oriented analysis, metadata management

1 Introduction

De nos jours, les entreprises stockent tous les types de données (fichiers log, etc.) dans une

infrastructure de développement permettant de gérer des opérations de Big Data, et s’équipent d’un

système décisionnel ou complètent leurs ERP de module dit Business Intelligence d’où l’intérêt de faire

l’analyse de Big Data face à l’explosion de données digitales variées. Cependant, les premiers outils

décisionnels étaient réservés à la gestion supérieure de l’entreprise ou à la DSI, et donc peu d’utilisateurs

finaux étaient concernés. Or, l’aide à la décision opère tous les étages de l’entreprise. Les utilisateurs

veulent désormais travailler indépendamment du département IT et produire eux-mêmes les rapports et

les analyses dont ils ont besoin pour leurs activités quotidiennes. Ce sont précisément les utilisateurs

métier qui jouent un rôle principal dans le fonctionnement décisionnel et qui deviennent des

consommateurs de données [Cegid, Simon16]. Pourtant, la gestion de données doit être facilement prise

en main pour eux et ils cherchent donc d'autres solutions pour comprendre, gérer et gouverner leurs

données. D'autre part, la qualité de données devient un défi incontournable dans l’aide à la décision et la

gouvernance de données et les utilisateurs métier ont besoin d’avoir une vision sur la source de données

[Simon16].

L’utilité d’avoir une vision sur la source de données est liée à la détermination de son origine qui est

connu sous le phénomène de lignage des données ou provenance de données. Ce phénomène a été abordé

par la littérature et l’industrie depuis deux décennies afin de déterminer l’origine des données et est

essentiellement présenté par 2 types d’analyses : Analyse de l’impact et celle de lignage. La première

désigne une étude d’impact d’une source de base vers une source dérivée. De l’autre côté, la deuxième

analyse est symétrique à la première et fait un mouvement en arrière à partir d’une source dérivée. Afin

de concrétiser les deux notions, prenons un exemple d’un cas réel : «Une personne pourrait se demander

de la source du chiffre de la marge nette d’un mois précis dans un rapport financier. Dans ce cas, elle

s'intéresserait à faire un mouvement en arrière dans l'évolution du chiffre, cherchait l'origine de données

et aurait également la possibilité de connaître tous les chiffres intermédiaires et les tables utilisées avec

les définitions de schéma de celles-ci. La personne pourrait constater que la marge est calculée à partir de

deux lignes de deux tables différentes et que l'une a un étiquète fiable et l'autre ne l'a pas (Lineage

Analysis). A partir de ce moment, la personne s'intéresserait à savoir dans quel rapport ou quelle partie du

rapport les données non-fiables sont utilisées (Impact Analysis)».

D’un point de vue théorique, l’analyse de lignage des données au niveau de métadonnées est prérequis

pour celle au niveau de données qui vise à trouver les tuples exactes qui génèrent les données interrogées

dans l’analyse [Velegrakis05, Santana04]. Car, cela permet d’abord d’identifier des éléments de schéma

de tables et un ensemble de requête de transformation dans un grand système de données et de résoudre

ensuite les conflits sémantiques [Velegrakis05]. D’autre part, les métadonnées sont essentielles pour la

compréhension, la maintenance, l'interrogation, l'intégration et l'évolution de bases de données. Les

exemples de métadonnées comprennent des schémas d’une table, des commentaires sur des données,

l’étiquetage de qualité de données, etc. Dans ce travail on ne focalise que sur des éléments de schéma des

tables utilisés dans l’analyse de lignage de données. En plus, des opérations de transformations, qui

transforment une source de données de base en une source de données dérivée, seront prises en

considération.

L’aspect qu’on veut élaborer dans ce travail est la distinction des perspectives de l'analyse de lignage

des données pour répondre aux besoins de gestion et gouvernance de données. C'est-à-dire qu'un

utilisateur métier et un développeur n'ont pas la même tendance à voir dans l’analyse de lignage des

données. Donc, il faudrait faire une distinction selon le type de l'utilisateur. En outre, il se peut qu'une

seule personne performe plusieurs perspectives pour comprendre mieux le contexte.

Puisque le stage se déroule chez SAP, on a réalisé une étude de l'existant pour mieux comprendre les

solutions de l'analyse de la provenance de données réalisée par 2 différents produits de l’entreprise SAP :

SAP HANA Studio et SAP Information Steward. HANA Studio est un environnement de développement

basé sur Eclipse et est utilisé par ses développeurs pour le développement des applications. L’outil permet

de faire l'analyse de lignage des données à l’intérieur de Information views. Les information views font

partie de la modélisation de SAP Hana qui correspond à une activité d'affiner et de découper en tranches

des données dans la base de données en créant des vues pour représenter un scénario de business. Le

processus de modélisation est la simulation des entités comme Customer, Product et Sales, et la relation

parmi eux. Par contre l’outil ne propose pas faire l’analyse entre les information views, ce qui est une

situation restreinte pour les développeurs. D’autre part, SAP Information Steward est une solution pour

gérer la qualité de données qui est destinée aux utilisateurs métier. L’outil permet de faire une analyse de

lignage et une analyse d’impact dans sa gestion des métadonnées, associe les métadonnées aux données et

les stocke dans un répertoire central. Donc, son analyse du lignage est orienté métadonnées [SapSteward].

En se basant sur les deux produits de SAP on en conclut que chacun répond aux besoins de leurs

clientèles et ils ne proposent pas une solution à la fois aux besoins des développeurs et des utilisateurs

métiers. Contrairement, on cherche une solution qui ne distingue pas seulement les types d’utilisateurs,

mais permet aussi aux utilisateurs de naviguer sur les différentes vues en même temps. Dans ce travail,

nous proposons l’analyse de lignage et d’impact destinés aux développeurs et aux utilisateurs métier avec

la grosse granularité basé sur les objets de conception et de données pour la raison de simplicité. D’autre

part, notre proposition permet de visualiser l’analyse avec la granularité fine comme pour une colonne

d’une table de base de données.

La structure du document sera comme la suivante : Dans la deuxième section, on expliquera le

déroulement du projet pendant le stage. Dans la troisième section, on présentera la préparation du graphe

de lignage en définissant des termes fondamentaux. Dans la section suivante, on détaille les méthodes qui

permettent d’avoir de différent vues pour distinguer les types d’utilisateur. Dans la cinquième section, on

présentera l’architecture générale étape par étape. Ensuite, on validera les solutions proposées dans

l’interface graphique. Et à la fin, on fera une conclusion et expliquera les perspectives pour le futur.

2 Déroulement du projet

Le stage s'est déroulé en suivant une méthodologie agile au sens large. Il y a eu 2 incréments, sprint en

anglais, pendant 3 mois et chaque incrément contient des contacts journaliers et meetings hebdomadaires

pour faire le point. Le premier incrément consiste à implémenter le côté Back-End du projet. Le deuxième

consiste à réaliser l’interface graphique. A la fin du deuxième incrément, il y a eu une démonstration de

produits aux clients et leurs avis ont été demandés.

2.1 Familiarisation de l’environnement de SAP Hana

Dans la première phase du stage, la connaissance de la base de données Hana et l'installation de

l'environnement de développement étaient nécessaires. La base de données Hana est un système de

gestion de base de données relationnelles (DBMS) qui performe un traitement de données en mémoire en

favorisant l’usage de multi-threading et l’utilisation de mémoire contigu. A la fin de cette phase, les

tâches réalisées étaient l’installation et la configuration d’une instance de base de données HANA, qui est

une machine virtuelle qui permet d’accéder aux données et schémas, lire des tutoriaux liés à l'architecture

de HANA et aux modèles de données de HANA et les pratiquer.

2.2 Introduction au lignage des données

Dans la deuxième phase du stage, la lecture des documents qui expliquent les notions utilisées dans

l’analyse de lignage des données était nécessaire pour se familiariser avec le sujet de stage, et ces

documents étaient en lien avec les notions de modélisation de Hana. D'autre part, l'utilisation des graphes

est essentielle pour le lignage des données et la traçabilité. L'équipe dans laquelle j’ai effectué mon stage

avait déjà conçu la modèle de représentation et implémenté les procédures en SQL. Donc, on a transformé

des codes SQL existant en des procédures en langage SQLScript qui est le langage de script de Hana.

2.3 Implémentation du côté Back-End

Dans un premier lieu, j’ai découvert le Graph Engine. Afin d’augmenter la vélocité de traitement des

requêtes de parcours de graphe, le Graph Engine est choisi par l’équipe. Le Graph Engine ou moteur de

graphe est un outil qui propose le stockage des données avec l’indexation et qui permet de lancer

plusieurs algorithmes de parcours de graphe dans SAP HANA tel que l’algorithme de calcul des

descendants, de composante fortement connexe, de plus court chemin et ainsi de suite. Pour en utiliser un,

il suffit de créer un scénario de calcul avec la configuration des paramètres comme le point de départ, le

filtre sur les nœuds, le filtre sur les arcs, le nombre maximum de niveau etc. Le résultat d'un scénario de

calcul est une table contenant tous les nœuds parcourus. Par conséquent, j’ai créé un scénario de calcul en

parcours en largeur en précisant à partir de quels nœuds le parcours de graphe commence, et j’ai

configuré la direction de graphe avec les possibilités de "outgoing edges" et de "incoming edges". Cette

direction permet de réaliser l’analyse d’impact et de lignage, respectivement.

Puis, j’ai créé une procédure en SQLScript qui exécute le scénario de calcul, récupéré ensuite les

nœuds descendants en le mettant dans une table temporaire, applique une transformation là-dessus et à la

fin renvoie les données transformées. Cette procédure a prouvé la faisabilité de l'architecture qui sera

présentée dans la section 5. Afin de réaliser ces tâches, le SQL dynamique est utilisé.

Ensuite, j’ai implémenté en SQLScript les algorithmes de l’analyse d’impact et de lignage qui prennent

en entrée une seule colonne d’une table pour les vues orientée données et orientée conception. La version

actuelle de ces algorithmes, ceux qui prennent en entré plusieurs colonnes d’une table ou simplement tous

ses colonnes, est implémenté par l’équipe.

La dernière étape était l’implémentation des services de graphe de lignage (Lineage Graph Services) en

langage XSJS (Server-side JavaScript) en prenant en considération des prérequis de Galilei, qui est un

framework d’éditeur de diagramme et de modèle basé sur HTML5/Javascript. Galilei nécessite d’un

modèle de graphe en JSON dans lequel chaque nœud a un identifiant unique et on précise le nœud de

racine et ses successeurs avec la relation de dérivation. XSJS est un ensemble d’interfaces de

programmation d’application (API) de côté serveur basé sur le langage Javascript qui permet de

configurer les applications pour interagir avec SAP Hana. Dans ce projet, les API de base de données et

de traitement de requête sont utilisés pour l’exécution des procédures stockés et l’envoie des requêtes de

http entre le côté Back-End et Front-End.

2.4 Implémentation du côté Front-End

J’ai d’abord étudié la faisabilité d’utiliser un outil de visualisation de graphe parmi les produits de

l’entreprise SAP. Après avoir comparé l’outil de visualisation de Graph Engine avec Galilei, il s’est avéré

que Galilei est plus avantageux car il permet d'utiliser des données dynamiques alors que le Graph Engine

nécessite des données statiques dans la base de données. Un autre avantage de Galieli est que toutes les

opérations et conceptions sont possibles puisqu’il est un éditeur de modèles. La forme des nœuds ou des

arcs pourrait être différente selon leurs types. En plus, Galilei propose un éditeur d’extension pour

l’objectif de l’analyse d’impact et de lignage qui est simple à l’utiliser et extensible aux nouvelles

fonctionnalités.

Dans un premier lieu, l’équipe a choisi d'utiliser le pure HTML pour la visualisation des graphes en

raison de simplicité et rapidité afin de faire des tests visuels. Donc, le but était de visualiser le graphe de

lignage. Ensuite, on a décidé de créer un projet de Web SAP UI5 basé sur l'architecture MVC en raison

de maintenabilité et pérennité. SAP UI5 est une librairie développée par SAP pour le développement des

solutions web et mobile et repose sur des standards tels qu’OpenAjax, CSS, HTML5. En outre, il y a plus

de fonctionnalités proposées dans SAP UI5 par rapport à la solution de pure HTML. En conséquence, un

menu de boutons et un menu de propriétés sont ajoutés à l’application Web grâce au SAP UI5. Le

développement Web s’est réalisé à l’aide de l’équipe.

3 Graphe de lignage

Après avoir donné une vue générale sur le projet, on détaillera dans cette section la phase de

préparation de graphe de lignage. Cette phase consiste à construire les modèles logiques et physiques.

3.1 Modèle logique

Pour expliquer le modèle logique du graphe de lignage et ses composants, les notions de dataset et

d’objet de conception seront d’abord définies, ensuite la définition de graphe de dérivation sera présentée.

Dataset Un dataset ou un ensemble de données est considéré comme une collection de données qui

contient des éléments de données organisés dans une manière spécifique. En général, un dataset fait

référence à une table de base de données avec des lignes et des colonnes. Néanmoins, il y a des cas où un

dataset a une organisation de données plus complexe, comme les structures imbriquées (fichiers XML),

les données multidimensionnelles, etc. Dans ce cas, un dataset peut être représenté par une ou plusieurs

tables de dataset, qui sont liées sémantiquement.

Objet de conception Un design object ou un objet de conception est simplement un objet de

développement dans une base de données tel qu’un schéma, une procédure, etc. Il décrit soit la structure

d’un dataset, soit l'information de «comment un ou plusieurs dataset en sortie sont calculés à partir d'un

ou plusieurs dataset en entrée». L'exemple du premier cas peut être un schéma XSD d'un fichier XML.

Dans le deuxième cas, le dataset créé à partir d'un objet de conception peut être vide. Un objet de

conception qui contient une déclaration DDL (Data Definition Language) pour une table de dataset peut

être un exemple. Ou bien le dataset peut être défini complètement par son objet de conception. A titre

d’exemple, ce serait un objet de conception qui contient un programme de transformation de données.

Dans le dernier cas, un objet de conception contient toutes les opérations de données qui permettent de

décrire les transformations effectuées tels que la jointure, l’union et ainsi de suite.

L'exemple ci-dessous qui est une définition de vue de base de données correspond à un objet de

conception simple. Elle définit la structure et le contenu de la vue, et contient l’information de

transformation réalisée par une multiplication du salaire par 2.

CREATE VIEW employee_view AS

SELECT name, salary x 2 as ‘salary (dollars)’

FROM employee ;

Pour résumer les deux notions en reprenant le même exemple, la définition d’une vue est un objet de

conception qui est non-matérialisé. C’est-à-dire qu’on ne parle pas de l’existence de données. Pourtant,

l’instance de cette vue, qui est matérialisé, est un exemple de dataset, car on parle de l’existence de

données.

Graphe de dérivation L’analyse de lignage des données est représentée par un graph dont les arcs

sont orientés pour indiquer la direction de flux. Ce type de graphe est appelé sous la notion de graphe de

dérivation, car les nœuds en entrée sont transformés et cette transformation dérive donc les nœuds en un

dataset ou une table de dataset. Pour la raison de simplicité, on utilisera les notions dataset et table dans le

même sens dans le reste du document.

Dans ce travail, on propose un graphe biparti

composé de nœuds de donnée et de calcul pour

modéliser le graphe de dérivation. Un nœud de calcul

permet de montrer explicitement les transformations

effectuées entre les dataset en entrée et ceux en sortie.

Puisque un objet de conception peut définir le

contenu et la structure d’un dataset, on utilisera le

terme d’objet de conception au lieu de transformation

dans le reste du document. En conséquence, les

données de calcul seront des objets de conception et

ceux de données seront simplement des dataset. Dans

la figure 1, un exemple de graphe de dérivation

bipartie sont illustrés. Dans le graphe, la figure de

table représente un dataset et le rond représente un

objet de conception. Les tables Product, Sales et

Customer sont des tables de base, et elles sont

transformées par les objets de conception et produisent les tables dérivées Product_Expensive_2015,

Elderly_People_Contact_List et Recommandation_Elderly_People.

Présentation de l’information dans le graphe de lignage Le modèle logique expliqué dans le

chapitre précédent permet d’identifier les acteurs principaux d’une analyse de lignage mais cela reste dans

un niveau abstrait. Afin de faire une analyse de lignage des données plus détaillée, les opérations de

données effectuées à l’intérieur des objets de conception seront ajoutées dans le graphe de dérivation.

Ainsi, un résultat précis sera obtenu pour chaque analyse. En reprenant le même exemple illustré dans la

figure 1 on suppose que la table Recommandation_Elderly_People est produite à partir de la requête

suivante :

Figure 1: Graphe de derivation

CREATE VIEW Recommandation_Elderly_People AS

SELECT A.brand_name, B.contact AS email

FROM Product_Expensive_2015 AS A

INNER JOIN Elderly_People_Contact_List AS B ON A.sales_id = B.sales_id

WHERE B.contact LIKE '%@%'

A partir de la définition de la requête, on peut

remplacer l’objet de conception C2 par ses

opérations de données et obtenir une version plus

détaillée du graphe. Une partie de ce graphe est

illustrée dans la figure 2 où le rond en noir

représente une colonne d’une table et le rond en

blanc représente une opération de

transformation. Les opérations sont catégorisées

en deux parties : Opération des calculs d’attribut

qui est identifié par EVAL et celle d’ensemble de

liste est identifié par FILTRE et JOIN. Ce type

de représentation permet de modéliser toutes les

opérations de données et de faire une analyse de

lignage avec la granularité fine. Par exemple, si

une colonne d’une table n’est pas utilisée dans la

production d’une autre table, cela ne servira à

rien à continuer l’analyse de lignage des données

et il faudra l’arrêter.

3.2 Modèle physique

Au-delà du modèle logique du graphe de lignage, c’est le modèle physique qui permettra de stocker les

données du graphe de lignage. On expliquera la solution de stockage utilisée dans ce travail.

Modèle de représentation du graphe de lignage Le graphe de lignage est stocké dans deux tables :

NODES et EDGES. La table NODES contient tous les nœuds et ses propriétés. Les propriétés sont

définies selon le type de nœud. Les tables, les colonnes et les opérations de données sont stockés en tant

que des nœuds et chacun a son propre identifiant unique. De l’autre côté, la table EDGES possède les

relations entre les nœuds stockés dans la table NODES et précise le nœud de source et le nœud de cible

dans une relation puisque les arcs du graphe de dérivation sont orientés. On identifie les deux tables sous

la notion de table de lignage.

4 Méthodes

Les méthodes qu’on va expliquer seront une solution au problème évoqué dans l’introduction. On va

d’abord expliquer les objectifs des méthodes et puis les méthodes proposées dans ce travail.

4.1 Objectifs

Il y a plusieurs objectifs qu’on voudrait mettre en pratique. L’objectif principal est de fournir aux

utilisateurs un graphe de dérivation où ils peuvent naviguer sur à la fois les objets de conception et les

dataset. Afin d’afficher les deux types de graphe de dérivation, on propose deux différentes vues : vue

orienté conception dont les acteurs principaux sont des objets de conception et vue orienté donnée dont

les acteurs principaux sont des dataset. En plus, l’analyse d’impact ou de lignage seront appliqués à

chaque vue selon la demande de l’utilisateur.

Un autre objectif est d’offrir des renseignements utiles sur les analyses de lignage des données. A titre

d’exemple, un utilisateur pourrait se demander quelles seront des objets de conceptions impactés à partir

d’une action de changement et quels seront donc le niveau de complexité des opérations qu’il rencontra

Figure 2: Graphe de lignage détaillé

pour les corriger. Dans ce contexte, le niveau de complexité correspond au délai du temps exigé pour

corriger un problème rencontré. C’est la raison pour laquelle on catégorise les opérations de données

selon leurs types de transformation et on propage le type de transformation d’un nœud à ses successeurs

au cours de parcours de graphe. Car, une opération de projection et celle d’agrégation n’ont pas les

mêmes niveaux de complexité quand ils sont impactés par une action de changement. La première ne

contient pas de transformation de valeur de départ, alors que la deuxième en transforme directement. En

conséquence, on applique le procédé de propagation sur les 2 méthodes proposées.

4.2 Vue orientée conception

Les designers et développeurs voudraient évaluer l’impact de leurs modifications sur les autres objets

de conceptions dépendants avant d'effectuer leurs changements. C'est pour cela que la vue orientée

conception est dédiée à la conception et au développement et il s’agit d’un algorithme qui produit un

graphe de dérivation basé sur les objets de conception. Néanmoins, l’affichage du graphe ne sera pas

présenté avec la granularité fine comme le modèle physique expliqué et l’algorithme renvoie en sortie

trois tables EDGES, NODES et DETAILS qui

permettent de construire un nouveau graphe de

dérivation plus compact et dense par rapport aux au

graphe de départ dont les nœuds seront de type objet de

conception. La raison de produire un graphe compact est

que ce serait plus compliqué à comprendre le graphe s’il

y a des milliers d’opérations de données effectuées et

donc la grosse granularité permet de faire un zoom en

arrière pour la raison de simplicité et compréhensibilité.

En reprenant le même exemple de la figure 1, les objets de conception impactés par la colonne contact

de la table Customer sont montrés sous forme de graphe de dérivation basé sur les objets de conception

C1 et C2 dans la figure 3. Dans chaque objet de conception situé dans le graphe compact en sortie

contient des informations sur les détails des opérations effectués et les colonnes en sortie.

4.3 Vue orientée données

La vue orientée données est dédiée aux utilisateurs de

businness. C'est-à-dire que les objets de conception sont

intentionnellement omis et les datasets sont montrés comme

illustré dans la figure 4. C'est-à-dire que l'utilisateur peut voir les

dataset sous forme du graphe de dérivation et chercher plutôt des

dataset au lieu des objets de conception. Par exemple, la table

Product ne contribue pas à la production de la table

Elderly_People_Contact_List alors que la table Sales contribue à

la fois à la table Elderly_People_Contact_List et celle

Product_Expensive_2015. Cette information précise n’est pas

désormais disponible dans la vue orienté conception.

Dans la même figure, une illustration d’analyse d’impact est

montrée. En sélectionnant la colonne contact, les dataset

impactés sont Elderly_People_Contact_List et

Recommandation_Elderly_People.

Figure 3: Vue orientée conception

Figure 4: Vue orientée données

5 Architecture

Dans cette section, on présente l’architecture générale du projet en expliquant chaque étape.

Stockage de données : Tables de Lignage Les données sont

stockés dans les tables NODES et EDGES. Le fait de stocker les

données de graphe de lignage a deux avantages principaux.

Premièrement, il permet de construire un graphe de dérivation avec

les propriétés des nœuds et des arcs. Deuxièmement, il permet

également de se servir du Graph Engine pour exécuter ses

algorithmes.

Chargement de données : Loaders Cette étape consiste à charger

les données extraites par des vues de calcul et des objets de

développement de flowgraph aux tables de lignage. Les deux types de

données contiennent des opérations de données multiples. Afin

d’automatiser le chargement de données l’équipe a développé un

plugin pour l’environnement de développement de Hana Studio.

Opération de graphe : Graph Engine Les opérations de graphe

sont effectuées par le Graphe Engine. Son algorithme de parcours en

largeur est utilisé dans les scénarios de calcul de Graph Engine. Il

prend en entrée une liste de nœuds de départ à partir duquel l’analyse

de lignage commence. Le résultat du scénario de calcul est également

une liste de nœuds parcourus dans le graphe dont ses nœuds et arcs

appartiennent aux tables de lignage. Le résultat contient également

l’information de profondeur. Les procédures stockées ont besoin de

cette information pour l’analyse d’impact ou de lignage.

Analyse d’impact et de lignage : Procédures stockées Les

algorithmes d’analyse d’impact et de lignage sont exécutés pour les

vues orientée données et orientée conception une fois que le résultat

du scénario de calcul est renvoyé par le Graphe Engine. La demande

d’exécution des algorithmes viennent des services de graphe de

lignage (Lineage Graph Services).

Génération des graphes La génération des graphes est effectuée

en deux phases: La première est la création du modèle de graphe en

JSON une fois qu’une procédure stockée renvoie le résultat. Afin de gérer la création de graphes, un API,

nommé Lineage Graph Services, s’utilise par des requêtes HTTP via URL. Les requêtes utilisées sont les

suivants :

Les requêtes GetTable LineageGraph et GetTable ImpactGraph sont utilisées pour piloter le

scénario qui prend toutes les colonnes d’une table dans la vue orientée conception et orientée

données.

La requête GetAttribute DesignActionGraph est utilisée pour piloter le scénario qui prend une

seule colonne d’une table et interroge une analyse de l’impact d’une action dans la vue orienté

conception.

La deuxième phase consiste à afficher des graphes via le framework d’editeur Galilei dans l’interface

graphique. Le modèle de graphe en JSON est récupéré par une requête HTTP en interrogeant le Lineage

Graph Services. Galilei traite le modèle et affiche le graphe de l’analyse d’impact de droite à gauche et

celui de l’analyse de lignage de gauche à droite.

6 Interface graphique

Afin de valider le travail, les données de Foodmart, une base de données de démonstration utilisée

publiquement, sont chargés aux tables de lignage par le plugin développé.

Figure 5: Architecture générale

Dans l’interface graphique, les actions d’utilisateur possibles sont les suivantes: Choisir le point

d'entrée de l’analyse de lignage à l’intermédiaire d’une boîte de dialogue, switcher entre la vue orientée

donnée et la vue orientée conception de la même analyse, cliquer sur un nœud et voir les propriétés du

nœud dans le menu de propriétés à droite, surligner les tables ou objets de conception impactées à partir

des colonnes de la racine sélectionnée dans les vues orientée données et orientée conception. Noter que la

racine est indiquée en verte dans le graphe et il est toujours une table, et pas un objet de conception, d’où

la nécessité de choisir un point de départ pour les analyses. Actuellement, la sélection de plusieurs tables

n’est pas autorisée comme un point de départ.

Par ailleurs, on propose 3 cas d’utilisation dans l’interface graphique : Analyse de lignage dans les

vues orientée conception et orientée données pour toutes les colonnes d’une table, analyse d’impact dans

les vues orienté conception et orienté donnée pour toutes les colonnes d’une table et impact d’une action

de conception dans la vue orienté conception pour une colonne d’une table.

Les deux premiers cas d’utilisation sont destinées à la fois aux designers et aux utilisateurs métier,

mais l’objectif principal est de donner une vue globales sur les données. Afin de naviguer sur le graphe de

dérivation, l’utilisateur peut

sélectionner une ou plusieurs

colonnes de la racine et voir les

objets de conception ou des

tables surlignées et ses

propriétés en détail. Grâce au

procédé de propagation des

opérations des données dans les

algorithmes de vue orientée

données et orientée conception,

on explique si les objets

surlignés sont impactés

directement ou indirectement

par la valeur de la colonne

sélectionnée de la racine.

Dans la figure 6, une analyse d’impact qui commence par la table racine CUSTOMER est illustrée

dans la vue orientée données. L’utilisateur clique sur la colonne CITY de la table CUSTOMER et voie

les tables impactées par la colonne sélectionnée. Ensuite, il clique sur une table impacté, la table

sales/SALES dans la figure 6, et regarde quelles colonnes de la table sont impactées. En plus, il lit des

détails supplémentaires sur le type de transformations effectuées sur les colonnes impactées.

De l’autre côté, le dernier cas d’utilisation, l’impact d’une action de conception, se concentre sur

l’action de la suppression d’une colonne. L’utilisateur ne peut choisir qu’une colonne dans ce scénario

comme le point de départ. Les questions qui se posent sont les suivants : « Si je supprime une colonne,

quelles colonnes des autres tables produites par des objets de conception sont impactées ? », « Si je

supprime une colonne, quels types d’opération de données des autres tables produites par des objets de

conception sont impactés ? Sont-ils impactés directement par la valeur de la colonne sélectionnée de la

racine ? Ou indirectement ? ».

Dans la figure 7, un exemple de l’impact d’une action de conception est illustré à partir de la colonne

CITY de la table racine CUSTOMER. Pour clarifier l’explication de l’exemple, supposons que l’action

souhaité est le changement de type de la colonne CITY. Dans la racine, l’utilisateur a une vision

concernant tout le graphe. Dans la figure, c’est indiqué qu’il y a une formule d’évaluation possiblement

impactée par l’action souhaité et il faudrait vérifier si la formule nécessite d’une correction. En plus, il

existe quatre colonnes produites par des objets de conception et l’utilisateur n’a pas besoin de les corriger,

car c’est juste la projection des colonnes et l’action de changement de type n’aura aucun impact sur les

colonnes en sortie.

Figure 6: Analyse d'impact dans la vue orienté donnée

Figure 7: Impact d'une action de conception

7 Conclusion

L’analyse de lignage des données est un sujet incontournable dans les systèmes de Data Warehouse et

cela intéresse les utilisateurs à trouver l’origine des données. Dans le cadre de projet de fin d’études, un

service de lignage des données a été proposé au niveau de métadonnées. Les éléments du schéma sont

considérés comme métadonnées et constituent la base de l’analyse de lignage des données. Ainsi, cela

permet de répondre plusieurs questions posées par des utilisateurs de business pour la gestion et la

gouvernance de données. En plus, les vues orientée conception et orientée données ont été proposés pour

à la fois distinguer les types de l’utilisateur et avoir deux point de vue en même temps en performant les

deux vues du même graphe lignage.

A la phase de réalisation du projet, les algorithmes de l’analyse de lignage et d’impact ont été

implémentés pour une action de suppression de colonne, un service de lignage qui construit des modèles

de graphe ont été implémenté. Une interface d’utilisateur a été également développée pour permettre aux

utilisateurs de visualiser et analyser des analyses de lignage des données avec un graphe plus compact et

facile à gérer.

References

[Velegrakis05] Yannis Velegrakis, Renee J. Miller, and John Mylopoulos. 2005. Representing and

Querying Data Transformations. In Proceedings of the 21st International Conference on Data

Engineering (ICDE '05). IEEE Computer Society, Washington, DC, USA, 81-92.

DOI=http://dx.doi.org/10.1109/ICDE.2005.123

[Santana04] Aurisan S. de Santana, Ana Maria de C. Moura. Metadata to Support Transformations and

Data & Metadata Lineage in a Warehousing Environment. DOI: 10.1007/978-3-540-30076-2_25. Data

Warehousing and Knowledge Discovery, 6th International Conference, DaWaK 2004.

Webographie

[Simon16] Eric Simon. Taking the data lineage challenge in the new world of agile EIM.

http://scn.sap.com/people/eric.simon/blog/2016/04/27/taking-the-data-lineage-challenge-in-the-new-

world-of-agile-eim. [Online ; consulté le 06-Juin-2016].

[Cegid] Cegid. Décisionnel "métier": analyse, reporting et prévisions à portée de l'utilisateur

http://www.cegid.fr/decisionnel-metier-analyse-reporting-et-previsions-a-portee-de-l-utilisateur/r1-

4349.aspx. [Online ; consulté le 06-Juin-2016].

[SapSteward] SAP Information Steward. Understand, analyze, and quantify the impact of data on your

business. http://go.sap.com/documents/2015/12/78b07395-517c-0010-82c7-eda71af511fa.html. [Online ;

consulté le 06-Juin-2016].