DataWarehouse, DataMart, DataLake… Que de data !
Vous avez pu entendre ou lire ces terminologies et vous demander si elles pouvaient vous être utiles, alors voici un peu d’histoire et de définitions !
Comme nous l’avons évoqué dans un précédent billet du blog, ce n’est pas du tout une bonne pratique que d’interroger les systèmes opérationnels (ERP, CRM, Appli comptable…) directement pour produire des rapports, des tableaux de bord, bref, tout ce qui concerne le décisionnel ou la Business Intelligence. Et cela on le sait depuis longtemps.
Pour répondre à cette problématique les infocentres ont été mis en place dans les années 70-80 ; cela consistait en un système centralisé sur lequel on avait recopié les données que l’on souhaitait interroger. Cela répondait au problème de saturation des systèmes opérationnels mais n’offrait aucune aide particulière pour la production des reportings.
Au début des années 80, Bill Inmon a conceptualisé la notion de DataWarehouse. La démarche est de créer une base donnée dédiée dans laquelle on aura stocké des informations nettoyées et intégrées sémantiquement. Le nettoyage permet d’assurer l’intégrité des requêtes de façon à ce que les mêmes notions soient présentées toujours de la même manière ; l’intégration sémantique implique de faire le lien entre les données de différentes sources comme le client qui peut provenir du CRM, de la gestion commerciale ou de la comptabilité et qui sera identifié de manière unique même s’il a déménagé plusieurs fois.
Ainsi cela permet d’avoir des données stables et fiables, et de pouvoir construire ses rapports et ses tableaux de bord sereinement.
La conception du DataWarehouse se fait traditionnellement en partant des données disponibles dans les systèmes opérationnels pour ensuite le concevoir (ce que les anglo-saxons appellent Top-Down) ; le mode opératoire est donc de récupérer l’ensemble des données pouvant potentiellement être utilisées dans le cadre des rapports ou des tableaux de bord envisagés.
L’inconvénient de cette approche est la manipulation d’un volume important de données qui ne sont pas toutes utiles et des coûts de leur nettoyage et de leur intégration.
Ainsi à la fin des années 90, Ralph Kimball propose de changer d’approche et de partir des besoins des utilisateurs pour définir le périmètre de base de données plus petites et axées sur une thématique d’analyse : les DataMarts. La spécificité est qu’on va organiser les données d’une manière très particulière qui permet d’obtenir de meilleurs temps de réponse pour les requêtes (modélisation dimensionnelle ou en « étoile »).
A partir de là on trouve deux chapelles : pour certains il faut alimenter les DataMarts à partir du DataWarehouse ; pour d’autres plus besoin de DataWarehouse, l’ensemble des Datamarts le constitue et ces derniers sont alimentés directement des données opérationnelles (avec bien entendu nettoyage et intégration sémantique au préalable).
Et puis arrive le Big Data et tous ses outils. Et le souhait revient de vouloir stocker beaucoup de données pour effectuer des analyses plus tard. Mais l’approche DataWarehouse coute chère et le volume de données est souvent incompatible avec un stockage dans une base de données traditionnelle. En 2010 James Dixon présente le concept de DataLake. L’idée est de stocker de manière économique la donnée brute sans la nettoyer ni l’intégrer et de reporter ces opérations nécessaires à plus tard lorsqu’il y en aura le besoin.
Consultez notre offre :