Puits de données comparé aux Data Lake, ODS, MDM, ...

Le Puits de Données est une figure de style (patern) d'Architecture.
Cette figure de style est décrite sur ce site.
On trouve aussi une présentation sur Slideshare et une note de principes.

Des questions fréquentes concernent les distinctions à faire avec d'autres figures de style :

• Data Lake
• ODS
• MDM (voir ici)

En ce qui concerne les Data Lake et ODS les différences figurent ci-après :

Puits et Data Lake

Malgré une apparente proximité, il y a une forte opposition entre ces 2 figures :

Par vocation un puits concentre « peu » (au sens sémantique) de données, très structurées, et avec la contrainte d’être au niveau de grain le plus fin. Mais les données d’un puits sont des données pivot, très fortement partagées.

Le Data Lake à l’opposé stocke des données en vrac, non mises en qualité, non modélisées (donc non structurées), le modèle étant reconstitué à la volée. La technologie Hadoop permet en effet de stocker très facilement de telles données et d'y accéder sans indexation ou modélisation préalable.

En conséquence, sur les mêmes données stockées dans le Data Lake à différents instant d'un cycle, il n’y pas forcément de cohérence du résultat… Ce n'est pas le souci principal, puisque l'objectif est de tout conserver en vrac. Le Data Lake a ainsi une approche différente de celle d'un ODS, qui doit aussi nettoyer les données (data cleansing) et les mettre en cohérence avant toute exploitation statistique.

Certes un Puits vise aussi à conserver toutes les données, dans la dimension historique, et au travers des différents flux, afin de créer la traçabilité par rapport aux silos de l'Entreprise, ou de la balkanisation de l'écosystème. Mais la modélisation doit être commune afin de garantir la cohérence de ces données pivot.

En ce qui concerne le Data Lake, il y aura des évolutions et certains experts du Data Lake disent d’ailleurs qu’il vaut mieux modéliser (et les mettre dans le Data Lake) les données les plus utiles et récurrentes.

Puits et ODS

Une architecture décisionnelle classique comprend, en amont du flux de données qui alimente les différentes bases mises en forme inversée (modèles en étoile, …), un entrepôt de données où les données sont chargées et travaillées par un ETL (classiquement appelé ODS).

En première analyse il y a duplication entre les puits et ce type d’entrepôt.

Cependant, en analysant plus en détail il apparaît que :

• Certaines transformations, par exemple de conversion de format, si elles sont réalisées en amont dans le puits, seront disponibles pour l’ensemble des applications et portail et n’auront plus à être refaites, et maintenues, au niveau de l’entrepôt, il y a ainsi clairement une économie d’échelle,
• Les problématiques d’intégration en particulier le lien avec les référentiels sont mieux placées si elles sont plus en amont, car plus proches de la source et là encore ce positionnement est gagnant,
• Les besoins de données à date sont spécifiques au décisionnel (en particulier pour disposer de lots de données homogènes en date), mais le puits peut alimenter l’entrepôt correctement grâce à sa gestion complète des dates (modèle tri-daté),

Il existe ainsi une complémentarité très importante :

• Il n’est pas nécessaire que tous le flux passent par des Puits, surtout si certains flux n’ont d’intérêt que pour le décisionnel, la problématique de profondeur historique est différente (par exemple, retropolation de séries selon la nomenclature actuelle).
• La coexistence Puits-ODS introduit une flexibilité pour les choix de périmètre et la gouvernance.
• Le décisionnel doit disposer de données détaillées mises dans l’ODS et de données inversées plus ou moins agrégées (en mode OLAP, ROLAP,…) pour faciliter les analyses.
• Un ODS répond au même type de besoin qu’un puits de données : constituer un point unique où se trouvent les données de références pour différents usages. La préoccupation est d’éviter les divergences et incohérences qui ne manquent de se produire si les analyses puisent les mêmes données à des sources différentes.

Cependant les analyses statistiques induisent des besoins spécifiques qui doivent être traités dans l’ODS et non pas dans un puits de données :

• Homogénéité des « populations » (au sens statistique) étudiées : 
• mêmes définitions, quelles que soient les provenances, afin que de fausses divergences ne puissent apparaître (les « biais »),
• disponibilité des différentes informations qui ont des provenances différentes. On peut d’ailleurs se satisfaire de données manquantes, mais de toutes manières, les exigences sont différentes de celles qui sont de règle pour des systèmes opérationnels, tels que ceux que doit satisfaire un puits de données,
• Stabilité du « peuplement » des lots :
• Le décisionnel fonctionne à rythme lent et cadencé, pour créer des agrégats comparables et suivre des évolutions.
• Il faut donc garantir la représentativité de la série, pour ne pas générer de fausses évolutions qui seraient dues à des variations de date, de production des données, de couverture, …
• Enrichissement sémantique par création de nouveaux concepts de classement propres à l’analyse :
• Le décisionnel permet de créer une classification dynamique, mais celle-ci est naturellement fluctuante, et un besoin de suivi « longitudinal » implique de créer des codifications stables,
• Ces codifications sont issues de croisement de données existantes et sont à créer au préalable à toute analyse, par exemple : la catégorie socioprofessionnelle,
• Des retraitements automatiques peuvent être exécutés : apurement des erreurs mineures, conversions de codes, de données,… la mise en qualité des données répond au cahier des charges de statisticiens, qui n’est pas celui du gestionnaire
• Les besoins de documentation sont en partie spécifiques, signalant par exemple les évolutions qui peuvent provoquer des biais.

Enfin, et ceci est majeur, les Puits, traçant des données opérationnels de référence, ont vocation à être situé en amont dans les échanges et flux opérationnels. C'est en effet ce positionnement qui permet de contrôler la migration et de jouer le Lego dans l'intégration des composants, des moteurs qui encapsulent la complexité.

A contrario, les ODS sont en aval, après l'enrichissement par les moteurs de complexité.

De toutes façons on va vers la coexistence de plusieurs « paterns » : les bases relationnelles bien adaptées aux « Legacy », les bases non structurées en Data Lake, et les ODS.