Re-découvrir le data mart pour le Big Data

De nombreux professionnels, et mêmes revues spécialisées présentent le data mart comme un extrait, une partie du Data warehouse. Combien de fois avez-vous lu que le data mart est une partie du Data warehouse ? Cette définition très répandue et intuitive du Data mart est fausse.   Cette fausse définition fait perdre de vue l’intérêt du data mart dans la chaîne de valorisation de données et dans le Big Data.

Dans cette article nous allons corriger cette perception erronée du Data mart en revenant sur sa définition authentique de base, ensuite nous vous expliquerons la différence entre le data warehouse et le data mart, et enfin nous conclurons sur l’intérêt plus que jamais prépondérant du data mart dans le contexte Big Data actuel.

1 – DES BASES DE DONNEES OPERATIONNELLES  AU DATA WAREHOUSE

Pour comprendre l’intérêt et le sens du Data mart, il faut comprendre l’intérêt du Data Warehouse. Si vous avez lu nos précédents articles sur les supports de stockage de données en Big Data, alors vous savez que l’activité d’une entreprise est par essence multi-process.

Pour atteindre son objectif de gestion, une entreprise a besoin de découper son activité principale en plusieurs processus métiers. Chacun de ces processus génère des données opérationnelles qui sont capturées soit dans des bases de données OLTP (type MySQL, SQL Server, Oracle, DB2, Ms Access, etc.), soit alors dans des feuilles de calcul (Excel le plus souvent). Notez que la capture de ces données ne se fait pas dans une base de données unique ou dans une feuille de calcul ; elle se fait dans les différents supports de l’entreprise, de sorte que chaque [processus] métier se retrouve avec un ou plusieurs fichiers de données (bases de données, fichiers plats, feuilles de calculs, etc.).

L’éparpillement de données qui s’en suit (qu’on appelle plus formellement « silotage de données »), fait qu’il est difficile pour les décideurs de l’entreprise d’avoir une vision globale de ce qui s’y passe. Elle empêche également la DSI d’implémenter des tableaux de bord qui sont arrimés à l’activité de l’entreprise pour le suivi de gestion.

Conséquence, pour avoir une vision décisionnelle de l’ensemble des activités de l’entreprise, il faut commencer par « dé-siloter » toutes les sources de données, c’est-à-dire harmoniser toutes les bases de données, fichiers plats, feuilles de calcul éparpillées au sein de l’entreprise afin qu’on puisse en avoir une vision unique. En clair, l’idée c’est de faire en sorte que toutes les données de l’entreprise soient perçues comme un « gros fichier unique ». Pour ce faire, il y’a plusieurs approches, nous allons y revenir plus bas, mais la principale approche adoptée jusqu’à ce jour consiste à intégrer toutes les données dans un Data Warehouse.

Le Data warehouse fut dès les années 90, la solution intuitive à l’harmonisation des données d’une entreprise. C’est une stratégie qui procède par intégration de données, c’est-à-dire par transfert de toutes les sources de données silotées de l’entreprise vers un répertoire ou un emplacement unique afin que les utilisateurs et les autres systèmes de l’entreprise puissent y accéder en seul clic. C’est plus simple ainsi !

Si on part de la définition reconnue du Data Warehouse, «  une collection de données orientée-sujet, intégrée, à variance constante et non-volatile utilisée pour la prise de décision stratégique », on comprend aisément que plus qu’un simple répertoire de stockage de données, l’intention derrière l’inception du data warehouse est de fournir une vision unifiée et homogène de toute la data de l’entreprise. Cela implique :

• d’être corporatif (avoir un périmètre corporatif), c’est-à-dire être le point d’arrivée de toutes les données générées par l’entreprise et être le point de départ de toutes les applications d’exploitation de données en entreprise ;
• d’être aussi résilient au changement que possible : on ne met pas à jour les données dans un Data Warehouse, on n’y fait que des ajouts (la variance des données est la même) ;
• d’être historique : étant donné qu’elle a une portée corporative, elle doit stocker des volumes massifs de données en un temps très raisonnable ;
• d’être indépendant des techniques de traitement, et indépendant des technologies informatiques ;
• d’être stable. Sa stabilité repose sur le fait qu’en entreprise, généralement ce qui change le plus ce sont  les technologies et les applications. Cela signifie qu’on peut très bien construire un Data Warehouse en s’appuyant exclusivement sur les processus métiers, qui font généralement l’objet d’une normalisation. Ainsi, on aurait un Data Warehouse pour le CRM, pour la comptabilité, pour la finance, pour le commerce, pour les ressources humaines etc. Ceci est possible parce que les processus métiers ne sont pas sujets à des changements rapides.

Comme vous pouvez le voir, l’intention de base du Data Warehouse est très ambitieuse, pour ne pas dire démesurée !!  

Du coup, comment faire pour implémenter un répertoire unique de toutes les données de l’entreprise ? Autrement dit quelle approche adopter pour construire un Data Warehouse efficace ? Quelle technique permet de réaliser cet exploit ? C’est dans ces questions que se situe l’identité du Data Mart.

2 – DU DATA WAREHOUSE AU DATA MART

Inutile de vous dire que la construction d’un Data Warehouse dans un projet réel est tout simplement pharaonique !

En gestion de projet, lorsqu’on fait face à des projets similaires à celui de la construction d’un Data warehouse, il y’a conceptuellement 2 approches : soit on l’aborde de façon monolithique, c’est-à-dire le tout en seul coup et selon une approche centralisée, soit alors on l’aborde de façon modulaire, c’est-à-dire de façon itérative.  

2 experts se sont penchés sur cette question et ont répondu chacun avec une approche différente, il s’agit de Bill Inmon et de Ralph Kimball.

Bill Inmon propose d’utiliser une approche qu’il qualifie de «  Top Down » (de haut en bas) ou une approche centralisée et monolithique pour construire le Data Warehouse. Selon lui, le Data Warehouse est un point central de stockage de données au niveau de granularité le plus bas possible. C’est d’ailleurs de Bill Inmon qu’on tient cette vision « répertoire central » du Data Warehouse. Pour lui, le Data Warehouse est :

• Une collection de données : c’est-à-dire un point central d’intégration de toutes les données opérationnelles de l’entreprise contenues dans les applications opérationnelles (ERP, applications métier, feuilles de calcul Excel, CRM, SCM, fichiers plats, csv, etc.)
• Orienté-sujet : les données stockées dans le Data Warehouse ne sont pas regroupées selon les besoins des processus métiers, mais selon les sujets, par exemple un sujet client, vendeur, production, localité… ;
• Intégré : étant donné que les données proviennent de différents sources ou systèmes, et sont donc souvent structurées et codées de façons différentes, le Data Warehouse les intègre pour fournir une représentation uniforme, cohérente et transparente ;
• À variance constante : le Data Warehouse stocke les données sous forme d’historique et introduit ainsi la notion de temps dans le stockage de la donnée ;
• Non-volatile : les données sérialisées dans le Data Warehouse sont accessibles en lecture seule, elles ne peuvent pas être modifiées ou changées. La seule opération possible dans le Data Warehouse est l’ajout de données ;
• Utilisé pour la prise de décision stratégique : le Data Warehouse, avec cette approche de stockage, sert de socle pour l’analyse de données et la prise de décisions efficaces. Il aide à répondre aux questions stratégiques comme : « Quels sont les produits qui se vendent le mieux dans chaque région, et quel est l’impact des données démographiques sur ces résultats de vente ? Quel est le chiffre d’affaires réalisé par gamme de produits les trois trimestres précédents ? Qu’est ce qui explique la baisse du chiffre d’affaires sur le trimestre précédent ? »

C’est à cause de ces caractéristiques qu’il faudrait selon Bill Inmon faire un inventaire de toutes les sources de données de l’entreprise, y appliquer des règles d’homogénéisation, afin de construire une couche sémantique (plus formellement un modèle multidimensionnel), qui sera implémentée dans un SGBDR sous forme d’un schéma de base de données (schéma en étoile, en constellation ou en flocon de neige). 

Voici une image de ce qu’est le Data warehouse d’après Bill Inmon :

Et voici la façon dont il devrait être implémenté selon lui :

L’approche définie par Bill Inmon est pratique d’un point de vue utilisateur. On comprend facilement à quoi ressemblera le résultat dès qu’on commence le projet. Cependant, étant donné qu’on aborde sa construction dans son ensemble, il y’a de gros risques de tomber dans ce qu’on qualifie en gestion de projet de « tunnel infini », c’est-à-dire un projet sans fin. C’est justement cet aspect « tunnel infini » qui a donné de la crédibilité et du poids au « Data mart » de Ralph Kimball.

3- DEFINITION DU DATA MART

Lorsqu’on décide d’identifier toutes les sources de données d’une entreprise dans sa globalité et qu’on essaye de les modéliser, on prend le risque de ne jamais finir le projet ou encore d’avoir sur les mains un projet dont le périmètre est beaucoup plus grand, ou même pire de finir le projet, mais de se rendre compte au moment de la livraison que les besoins des utilisateurs,  ou les processus métiers de l’entreprise ont changé et qu’on le produit qu’on a entre les mains ne sert plus à rien !

C’est ça les principaux risques et problèmes potentiels de la méthode de Bill Inmon. Construire un Data Warehouse d’une entreprise dans sa globalité n’est pas faisable.   

Ralph Kimball par contre, propose de construire le data warehouse selon une approche modulaire ou Bottom Up (bas vers le haut). L’idée c’est de « manger l’éléphant morceau par morceau », un morceau à la fois.

Selon lui, le Data Warehouse se construit de façon opportuniste et itérative, de processus métier en processus métier, du plus prioritaire au moins prioritaire.

On part d’une liste de questions auxquelles les utilisateurs souhaitent répondre et on construit ce qu’on appelle un Data mart. Le data mart n’est pas juste une sorte de base de données spécifique qui répond aux questions des utilisateurs, c’est un véritable Data warehouse au sens propre du terme puisqu’il possède toutes les caractéristiques énoncées par Bill Inmon plus haut. A la seule différence que le Data mart sera le Data warehouse pour un périmètre bien précis de l’entreprise, par exemple un processus métier tel que le CRM, ou encore le processus RH.

Attention !!! les data Marts ne sont pas construits par départements, mais par processus métiers !

C’est à noter que le Data mart de chaque processus métier est construit séparément et sont tous indépendants les uns des autres. En réduisant ainsi le scope ou périmètre du projet, on a beaucoup plus de chances de réussir la construction de son data warehouse et la probabilité qu’on tombe sur un tunnel infini (avec toutes ses conséquences) est très faible.

Attention !!! Le Data mart n’est pas un sous-ensemble du Data mart comme vous pourrez le lire dans plusieurs magasines ou revues spécialisées. Comme vous pouvez le voir, le Data mart n’a d’origine que les questions des métiers et non un Data warehouse existant. Le Data mart est un Data Warehouse simplement avec un périmètre fonctionnel bien plus faible. Penser que le Data mart est un sous-ensemble ou l’extraction d’une partie du Data warehouse revient à dire que le Data warehouse a déjà été préalablement construit, ce qui est justement l’objectif !  

Il faut quand même noter que l’approche de Kimball, bien qu’élégante et plus pratique, soulève quelques questions : comment mettre en œuvre des data mart qui se nourrissent potentiellement de sources de données qui sont hors de leur périmètre ? Comment faire pour éviter les doublons de data mart potentiels ? Comment s’y prendre pour faire communiquer les data marts de différents processus métiers de l’entreprise entre eux ?  Regardons toutes ces questions dans la section suivante sur la conception des data marts.

4- CONCEPTION ET MODELISATION DU DATA MART

Dans l’approche de Kimball, pour chaque processus métier, un Data Warehouse appelé  dans ce cas un Data mart est construit et l’ensemble des data Marts de tous les processus métiers de l’entreprise forment le Data Warehouse global de celle-ci. Ici le Data Warehouse (EDW – Enterprise Data Warehouse) c’est la somme des Data Marts.

Pour communiquer entre eux, les data Marts sont reliés à l’aide de ce que Kimball appelle des « dimensions conformes« , partagées par les métiers. Nous reviendrons plus bas sur la notion de « dimension ». Mais nous pouvons déjà vous dire que 2 ou plusieurs dimensions sont dites conformes si elles contiennent un ou plusieurs champs communs dont le contenu vient du même domaine métier…

L’outil que Kimball définit pour identifier les dimensions conformes et construire les data Marts s’appelle la Matrice de Bus du Data Warehouse. Le tableau suivant est un exemple de Matrice de Bus de Data Warehouse d’un hyper marché.

Les dimensions conformes, encore appelées « bus », agissent comme des ponts qui permettent de relier les data Marts des différents processus métiers de l’entreprise. Dans la matrice de bus du Data Warehouse, les processus métiers sont en ligne, et les dimensions sont en colonne ; les dimensions conformes se sont les dimensions qui sont communes à 2 ou plusieurs processus métier. Par exemple, dans notre tableau, les processus métiers sont : Ventes, Gestion des stocks, Livraison, Commandes, et les dimensions sont Date, Produit, Magasin, Promotion, Vendeur, et contrat ; les dimensions conformes sont Date, Produit et Magasin.  Chaque ligne de la matrice correspond à un data Mart. Dans notre exemple, on aura les data marts suivants :

Ventes {Date, Produit, Magasin, Promotion},
Gestion des stocks {Date, Produit, Magasin},
Livraison {Date, Produit},
et Commandes {Vendeur, Contrat}.

La figure suivante illustre les faisceaux de communication possibles entre les data mart représentés dans la matrice de bus plus haut.

En identifiant les dimensions conformes et en les représentant dans la matrice de bus, on peut rapidement s’apercevoir des relations qui existent entre les data mart et voir les différentes possibilités d’effectuer des analyses croisées entre eux.

Dans notre figure, on constate que grâce à leurs dimensions conformes, les data mart Gestion des stocks, Livraison et Ventes peuvent être interconnectés, et dont il sera possible d’effectuer des analyses entre les données de ces 3 data marts. Par contre, le Data mart Commande, puisqu’il ne partage aucune dimension conforme avec les 3 autres, sera un data mart isolé et seules ses dimensions pourront être utilisés pour ses analyses décisionnelles.

Vous voyez qu’à l’aide des dimensions conformes, on arrive à bâtir un Data Warehouse global, commun, et  distribué. Et étant donné que les Data marts peuvent être construits indépendamment une fois qu’on a identifié les éventuelles dimensions conformes qu’il y’a entre eux, ceux-ci peuvent être implémentés par différentes équipes à des moments différents, et dans des technologies différentes. 

La modélisation du Data mart proprement dite est identique à celle du Data warehouse tel qu’on le connait : on utilise les techniques de modélisation multidimensionnelle (soit la modélisation en flocon de neige, en constellation, ou en étoile) et on cherche à relier les dimensions, et les faits. Nous avons amplement traiter la modélisation multidimensionnelle dans la chronique suivante: « cube OLAP : socle de l’analyse décisionnelle en Big Data ». Ici, nous répétons simplement les rudiments nécessaires pour que vous arriviez à comprendre comment modéliser un data mart.

• Les dimensions sont les regroupements de données caractérisant un sujet métier bien précis. Par exemple le Client, le vendeur, le temps, la Date, la localité sont tous des sujets. La table dans laquelle ces données sont regroupées s’appelle une table de dimension, et dans ce cas, les sujets sont des regroupements d’attributs ou colonnes décrivant la même réalité. Par exemple, si on revient dans notre matrice de bus plus haut, on s’aperçoit que le sujet Livraison est composé des attributs date et Produit. Chaque [table de] dimension constitue un axe d’analyse, qui se traduit par une insertion de l’identifiant unique de la dimension dans la table de fait. Plus les attributs qui composent la dimension seront bien choisies et bien construites (discrètes et finies), plus le Data mart sera en même d’analyser dans le détail ;

• Le fait : on ne peut pas définir la notion de fait sans définir la notion de mesure. La mesure est la valeur quantitative à laquelle est associé un fait. En réalité, le fait est un événement quantitatif correspondant à une opération métier. Dans la modélisation multidimensionnelle, le fait fait référence à l’ensemble des données générées par cet événement et la mesure associée. Par exemple, dans un super marché, le fait peut correspondre à un bip de scanner lorsqu’on passe l’article en caisse, cet événement (le bip) génère les données sur la quantité et le prix d’achat de l’article ; en comptabilité, un fait correspond à un l’enregistrement d’une opération dans le journal, en CRM, le fait correspond à un achat client. L’ensemble des faits sont sérialisés dans une table qu’on appelle en modélisation multidimensionnelle la table de faits. Chaque fait est collecté selon un niveau de grain ou un niveau de granularité qui dicte le niveau de détail ou de profondeur jusque auquel on peut aller dans les analyses de données.

Grâce à ces 2 concepts, et l’introduction des dimensions conformes, vous pouvez concevoir et modéliser aisément un Data mart.  Si vous souhaitez aller plus loin dans la construction d’un Data Mart, Ralph Kimball a rédigé un ouvrage qui est devenu le grand classique du sujet : « The Data Warehouse LifeCycle ».

Quittons cette partie sur une brève note de fin.  Les 2 approches de construction d’un data warehouse peuvent se résumer ainsi : dans l’approche Top Down, le Data Warehouse sert de point de distribution de données à toute l’entreprise pour les analyses ; dans l’approche Bottom Up, il sert de point de collection pour les données nécessaires à un processus métier spécifique. L’effort de développement consiste en un programme de cycle itératif, tandis que dans une approche Top Down, l’effort consiste en un long projet en cycle Y. Quoiqu’il en soit, Data mart et Data warehouse renvoie à la même réalité !

5 – COMMENT IMPLEMENTER ET UTILISER UN DATA MART ?

Comme vous le savez à ce stade, l’’intérêt du Data Mart est d’offrir aux utilisateurs la capacité de faire des requêtes multidimensionnelles ou des agrégations par axe de dimension du processus métier dans lequel ils travaillent. Les SGBD classiques ne possèdent pas les caractéristiques nécessaires pour répondre à des analyses décisionnelles. Dès lors, pour implémenter un Data mart, il faut modéliser le schéma multidimensionnel du data mart dans des technologies capables de supporter les requêtes multidimensionnelles, notamment les technologies de cube OLAP.  

Attention !!! ne confondez pas Data Mart avec cube OLAP. Les gens font souvent cet amalgame. Le Data Mart et le Cube OLAP sont 2 choses différentes. Tandis que le premier fait référence à une approche de construction de Data Warehouse, l’autre fait référence à UNE approche de stockage et de requête des données du Data Warehouse. Le Data Mart existe indépendamment d’un cube OLAP. Le cube OLAP est un moyen comme un autre pour stocker et adresser des requêtes au Data Mart. 

En fonction de l’étendue du périmètre fonctionnel du data mart, vous pouvez l’implémenter dans 2 types de technologies OLAP différentes : les ROLAP et les DOLAP.

5.1 – Implémentation du data mart dans les cubes ROLAP

à titre de rappel, un cube ROLAP ou Relationnal OLAP est un cube dans lequel les données sont stockées sous forme d’une base de données relationnelles. Cela signifie que les requêtes que les utilisateurs sont traduites en SQL avant d’être exécutés par le moteur. L’outil SSAS (SQL Server Analysis Services) de Microsoft est un exemple de logiciel ROLAP. Avec le ROLAP, les data mart ont un périmètre d’utilisation départementale ; les utilisateurs d’un service de l’entreprise, d’un processus métier ou d’un département entier peuvent utiliser le même data mart.

5.2- Implémentation du data mart dans un cube DOLAP 

Il y’a des cas en entreprise où seules certaines personnes sont responsables des analyses décisionnelles. On les appellent souvent des « powers users ». Dans ce cas de figure, il n’est pas nécessaire d’implémenter le data mart dans un cube OLAP à portée départementale. Il est plus indiqué d’utiliser ce qu’on appelle un cube DOLAP, pour Desktop OLAP.  Dans cette approche, le moteur OLAP est un client lourd installé en local, directement sur le PC des powers users ; les données y sont stockées de façon soit de façon relationnelle, soit de façon multidimensionnelle, ou soit sous la forme de fichiers plats. Les utilisateurs peuvent faire leurs analyses directement sous leur poste sans dépendre du service informatique. On appelle aussi cette approche « Self Service Business Intelligence ». PowerPivot de Microsoft Power BI, et QlikView de Qlik sont des exemples de DOLAP.

5.3 – Implémentation du data mart dans un contexte Big Data

Avec la mise en place des systèmes de traitement massivement parallèle tels que Hadoop, ou Spark, vous pouvez être tenté de croire que le data mart n’a plus sa place en Big Data.  Détrompez-vous !

En fait, avec la grande varieté d’actifs de données générées en Big Data, le data mart est plus que jamais nécessaire !  Pour comprendre pourquoi, il faut saisir les conséquences de la granularité des données. Même si le Data warehouse se veut le plus complet possible en matière de données, les faits sont que ça coûte cher de stocker une donnée qui peut potentiellement ne pas être exploitée dans le futur. Du coup, lorsqu’on construit un data warehouse, on a tendance à partir des questions que l’utilisateur souhaite répondre pour prendre uniquement les dimensions d’intérêt dans l’immédiat.

Le Data Lake lève ces restrictions de stockage en s’appuyant sur la baisse des coûts d’ordinateur et sur l’approche de cluster computing. Grâce au data lake, on peut historiser tous les objets de données de l’entreprise à la granularité la plus fine possible, et s’assurer ainsi que dans le futur on pourra effectuer toute sorte d’analyse décisionnelle. Lorsqu’un utilisateur a besoin de réponses spécifiques, un data mart est construit à partir de la granularité de l’information stockée dans le data lake. Voilà comment le data mart est utilisé en Big Data !

Nous sommes arrivés au terme de cette chronique.  Notre objectif était de vous aider à redécouvrir le data mart et son intérêt plus que jamais prépondérant dans le contexte Big Data actuel. Ce qui en ressort c’est que le data mart n’est pas un sous-ensemble du data warehouse, et encore moins un extract. Le data mart et l’entreprôt de données sont 2 concepts interchangeables qui correspondent à la même réalité, mais à des périmètres fonctionnels différents. Là où le data warehouse a pour ambition de couvrir l’intégralité de l’entreprise, le data mart a une ambition plus modeste, qui est de couvrir un processus métier particulier. Ainsi, on peut avoir plusieurs data mart dans une entreprise. Dans ce cas de figure, pour les faire communiquer, on utilise ce que son créateur, Ralph Kimball, qualifie de « dimensions conformes ». En Big Data, le data mart a revêtu une importance sans précédent grâce à la réduction des coûts de stockage générée par le data lake.

Voilà ! Si vous avez aimé cette chronique, n’hésitez pas à le repartager, cela contribue à augmenter la visibilité de notre site. Merci d’avance pour votre contribution.