Le Portail du Manager Innovant

Data Warehouse, Entrepôt de données

09 mars 2020  Par   Partagez
Data Warehouse
Le Data Warehouse, est une base de données spécifique aux besoins décisionnels. Elle est intrinsèquement organisée de manière à assurer la stabilité contextuelle des données selon les sujets et thèmes de l'entreprise. Le data warehouse gère l'historisation des données structurées.

Qu'est-ce qu'un Data Warehouse ?

Définition du Data Warehouse
Le Data Warehouse, ou entrepôt de données, est une base de données dédiée au stockage de l'ensemble des données utilisées dans le cadre de la prise de décision et de l'analyse décisionnelle.

Le Data Warehouse est exclusivement réservé à cet usage. Il est alimenté en données depuis les bases de production grâce notamment aux outils d'ETL Extract Transform Load.

Ensuite, les utilisateurs, analystes et décideurs, accèdent aux données collectées et mises en forme pour étudier des cas précis de réflexion. Ils construisent des modèles d'étude et de prospective pour limiter la part d'incertitude lors du processus de prise de décision.

Les 4 caractéristiques du Data Warehouse

Le Data Warehouse n'est pas une simple copie des données de production. Le data warehouse est organisé et structuré.
Père du concept, Bill Immon dans son livre "Building the Data Warehouse" (John Wiley and Son 1996) le décrit ainsi :
"Subject oriented, integrated, nonvolatile, time variant collection of data in support of management decisions.
  1. Orienté sujet

    Au coeur du Data warehouse, les données sont organisées par thème. Les données propres à un thème, les ventes par exemple, seront rapatriées des différentes bases OLTP de production et regroupées.
  2. Intégré

    Les données proviennent de sources hétérogènes utilisant chacune un type de format. Elles sont intégrées avant d'être proposées à utilisation
  3. Non volatile

    Les données ne disparaissent pas et ne changent pas au fil des traitements, au fil du temps (Read-Only).
  4. Historisé

    Les données non volatiles sont aussi horodatées. On peut ainsi visualiser l'évolution dans le temps d'une valeur donnée.
    Le degré de détail de l'archivage est bien entendu relatif à la nature des données. Toutes les données ne méritent pas d'être archivées.

Data Warehouse Open Source

Architecture technique du Data Warehouse

3 architectures technologiques typiques et classiques pour le stockage de grandes quantités de données pour des fins décisionnelles : SMP, MMP et Cluster.

SMP (Symetric Multi-Processing)

Principe : le modèle d'architecture de type "SMP" est fondé sur l'exploitation de plusieurs processeurs identiques oeuvrant en parallèle et partageant une mémoire commune. Inconvénients : la mémoire est unique, la synchronisation de l'accès à la mémoire par les différents processeurs constitue le principal inconvénient de ce type d'architecture.

MMP (Massively Parallel Processing)

  • Principe : le modèle d'architecture de type "MPP" est fondé sur l'exploitation d'un nombre important de processeurs. Chaque processeur dispose de sa propre mémoire.
  • Inconvénient  : il nécessite des développements spécifiques. Les traitements doivent être prévus dès la conception pour une exécution sur ce type d'architecture.

Cluster 

  • Principe : : avec l´architecture de type "Cluster", les ordinateurs sont organisés en "grappes". Ils sont interconnectés par des liaisons rapides Ethernet. Sur le plan du principe, le fonctionnement est assez proche de l'architecture MMP.
  • Inconvénient : : le programme à exécuter doit impérativement être développé pour ce type d'architecture.

Data warehouse de nouvelle génération

Voir aussi les solutions autour du moteur Hadoop de Apache Fundation et les principes du Cloud Computing pour l'emtreprise et d'IaaS. Ce sont les technologies à suivre de près.

Recommandations

Comme pour tout système informatique, l'architecture technique du Data Warehouse sera choisie et dimensionnée en tenant compte de la volumétrie, du nombre d'utilisateurs et de la charge d'activité potentielle.
Pas facile à définir pour un projet en continuelle évolution. Attention au sous-dimensionnement et n'hésitez pas à jeter un oeil sur les réalisations de la concurrence.

Quelques constructeurs

Cette liste n'est ni exhaustive, ni préférentielle

L'Infocentre, l'ancêtre des bases de données décisionnelles

L’infocentre était un SGBDR présentant une copie de travail d’une partie de la base de production, mise à jour périodiquement. L’infocentre était une première solution pour soulager le système de production des requêtes complexes du décideur. Il permettait en effet de transférer les données de base de type non relationnel dans un univers plus propice à l’interrogation impromptue.

Avec l’accroissement des besoins en matière de décision, que ce soit en termes de quantité de données collectées ou en nombre d’utilisateurs potentiels, l’infocentre se révéla bien insuffisant. Le DW l’a rapidement remplacé.

Un projet de Management

Pour Bill Inmon, père "putatif" du Data Warehouse, La finalité n'est pas de fédérer l'ensemble des données de production. Le datamart n'est pas non plus un entrepôt de taille réduite qui attend patiemment de grandir... la finalité est tout autre. Un data Warehouse est un instrument d'assistance au management. Perdez de vue cette finalité et votre projet sera en bien mauvaise voie... À méditer.

Toutes les entreprises ne passeront pas au Big Data...

Cela dit big data ou pas, c'est bien le soin avec lequel on a structuré la base qui assure de la qualité des informations décisionnelles que l'on pourra en extraire. S'extasier devant la capacité de stockage des bases en pleine croissance exponentielle est devenu un vrai poncif. Cela dit, les chiffres sont de plus en plus impressionnants.

Considérons une base typique comme Microsoft Azure SQL qui propose une capacité maximale de 240 Teraoctets (1012). Si on considère qu'un livre texte de 300 pages occupent environ 900.000 octets (300*3.000). On pourrait donc stocker sur cette base l'équivalent de : 200 Téraoctets/900000, environ 200 millions d'ouvrages... Soit bien plus que les 14 millions de livres de la BNF (1). C'est un exemple à ne pas prendre à la lettre, il s'agit juste de donner une idée concrète de ces dimensions tout en sachant que les bases les plus importantes utilisent le pétaoctet (1015) comme unité de mesure.

Il est bien évident qu'en situation de décision, il ne s'agit pas de chercher à accéder à une telle masse de données. Chaque décideur désire l'accès uniquement à celles qui l'intéresse bien entendu.

Pour les puristes, un ouvrage complet au format pdf illustrations comprises, type ebook occupe une taille de 3Mo. Une capacité de 200To permet peu ou prou de stocker 66 Millions de livres complets.
En fait c'est bien par cette affirmation qu'il faudrait commencer tous les projets décisionnels et ne pas se laisser influencer par le gigantisme des bases actuelles en espérant que le décideur se débrouille tout seul ! Mission impossible !
C'est bien par la question de la structure de la base qu'il faut commencer, lui donner du sens pour en extraire des enseignements pertinents.

De toute façon, toutes les entreprises ne sont pas prêtes à passer au Big data (voir ici le dossier big data). Le Big Data exige un investissement conséquent, non seulement dans la technologie mais aussi dans la compétence. Sans un spécialiste de l'analyse et des managers bien sensibilisés donc bien formés, la technologie a elle seule ne sert pas à grand chose...

Revenons à la question du Data Warehouse plus classique :

  • 1 À quelles informations veut-on pouvoir accéder ?
  • 2 Quelles données faut-il alors mettre dans le DW ?
  • 3 Comment doit-on les organiser ?
Ensuite, la capacité de stockage intervient dans un second temps et chacun verra cette question en fonction des réponses ci-dessus. À noter une question subsidiaire d'importance avant de dimensionner définitivement le système : Et demain ? On évolue comment ?

Facteurs d'utilité et de performance du système

La qualité de l'intégration des données au sein du Data Warehouse est désormais reconnue comme le principal facteur conditionnant la réussite du système décisionnel.
C'est dire si cet aspect du projet Business Intelligence mérite un soin particulier.
Il ne faudrait pas pour autant que ce point, quoique essentiel, mobilise la totalité des efforts de conception. L'ensemble du projet est complexe. Il serait ainsi peu judicieux de ne pas consacrer autant d'attention à l'épineuse question de l'organisation des bases décisionnelles.

L'hypothétique information...

Ce second aspect influence directement la facilité d'accès à une information précise. En effet, l'utilisateur en situation ne dispose jamais du temps et de l'énergie nécessaires pour fouiller dans les bases en quête d'une hypothétique information. L'accessibilité en un temps raisonnable à l'information traduit en fait le degré d'utilité (et aussi d'utilisation) du système décisionnel.
Pour faire simple, plus les informations seront faciles d'accès, plus l'instrument sera utilisé et par conséquent, plus il sera appelé à se développer. Eternelle règle de l'utilité et de l'utilisation des systèmes informatiques
Bref, il s‘agit là ni plus ni moins du facteur définissant la performance globale du système d'aide à la décision.

À ce sujet, voir aussi

  • Modélisation du data warehouse, schéma en étoile
    Le projet Data Warehouse et la modélisation des données en utilisant le schema en étoile Business Intelligence
  • Le projet Data Warehouse, un processus continu
    Le projet Data Warehouse, un processus continu, les 4 étapes d'un projet qui sera toujours en perpétuelle évolution. Il est essentiel de se placer sous l'angle de l'utilisateur et non sous celui de la technique. La toute première génération de Data warehouse a été marquée par une succession d'échecs. Les concepteurs appliquaient le "postulat du technicien" :
    " Si je mets le maximum de données, les utilisateurs trouveront leur bonheur." Bien entendu, avec une hypothèse erronée dès l'énoncé du principe fondateur, on ne peut que bâtir des usines à gaz.
  • Le ROI de la Business Intelligence
    Le projet Business Intelligence est un projet d'envergure. Et comme pour tout projet d'envergure il est pour le moins hasardeux de s'embarquer sans calculer précisément le Retour sur Investissement attendu. Voyons comment calculer le ROI du projet BI en tenant compte des gains cachés qui n'apparaissent pas immédiatement sur le compte de résultats.

Ressources web

           



Tous les articles