Les notions de base
Rappel sur le concept de Data Warehouse
Mathieu MONESTIER, Massana Conseil
En reprenant la définition de Wikipedia, le Data Warehouse (ou Entrepôt de données en français) est une base de données regroupant une partie ou l'ensemble des données fonctionnelles d'une entreprise.
Son but est de fournir un ensemble de données servant de référence unique, utilisé pour la prise de décisions dans l'entreprise par le biais de statistiques et de rapports réalisés via des outils de reporting.
Théorisé et popularisé dans les années 90 par Bill Inmon et Ralph Kimball, le Data Warehouse répond à trois enjeux majeurs, qui ont permis aux entreprises de structurer et de fiabiliser leurs solutions de reporting :
• La réconciliation dans une architecture centralisée des informations issues des différents systèmes de gestion de l’entreprise, en adoptant un langage commun et partagé par tous les utilisateurs ;
• L’historisation des données manipulables ;
• La fiabilité des informations, via la complétude et l’exactitude des données mises à disposition.
Un Data Warehouse est constitué d’un ensemble de briques techniques servant ces enjeux :
• « Staging Area » : zone de préparation de données, non persistante. Elle permet de collecter les données sources, de la qualifier et de les organiser avant de pouvoir les déverser dans l’entrepôt ;
• « Data Warehouse » : au sein strict, il s’agit de la zone de stockage persistante (historisée) des données. Le Data Warehouse est modélisé pour répondre aux besoins de pilotage de l’entreprise, avec un niveau de granularité plus ou moins fin selon les exigences.
• « Data Mart » : spécialisation du Data Warehouse, permettant de répondre plus spécifiquement à une problématique fonctionnelle. Les données stockées dans un DataMart sont en règle générale pré-calculées et agrégées pour faciliter la restitution prédéfinie ou à la demande, dans des délais raisonnables pour les utilisateurs.
Cette architecture est parfois complétée par une base « ODS » (Operational Data Store), qui est un espace de stockage persistant dans lequel seront stockées les données sources à un niveau détaillé.
L’ODS pourra servir les besoins décisionnels ; il est à ce titre utilisé dans certaines architectures comme le socle de données du Data Warehouse. Mais, comme son nom l’indique, il a également vocation à servir les besoins opérationnels de l’entreprise.
Son but est de fournir un ensemble de données servant de référence unique, utilisé pour la prise de décisions dans l'entreprise par le biais de statistiques et de rapports réalisés via des outils de reporting.
Théorisé et popularisé dans les années 90 par Bill Inmon et Ralph Kimball, le Data Warehouse répond à trois enjeux majeurs, qui ont permis aux entreprises de structurer et de fiabiliser leurs solutions de reporting :
• La réconciliation dans une architecture centralisée des informations issues des différents systèmes de gestion de l’entreprise, en adoptant un langage commun et partagé par tous les utilisateurs ;
• L’historisation des données manipulables ;
• La fiabilité des informations, via la complétude et l’exactitude des données mises à disposition.
Un Data Warehouse est constitué d’un ensemble de briques techniques servant ces enjeux :
• « Staging Area » : zone de préparation de données, non persistante. Elle permet de collecter les données sources, de la qualifier et de les organiser avant de pouvoir les déverser dans l’entrepôt ;
• « Data Warehouse » : au sein strict, il s’agit de la zone de stockage persistante (historisée) des données. Le Data Warehouse est modélisé pour répondre aux besoins de pilotage de l’entreprise, avec un niveau de granularité plus ou moins fin selon les exigences.
• « Data Mart » : spécialisation du Data Warehouse, permettant de répondre plus spécifiquement à une problématique fonctionnelle. Les données stockées dans un DataMart sont en règle générale pré-calculées et agrégées pour faciliter la restitution prédéfinie ou à la demande, dans des délais raisonnables pour les utilisateurs.
Cette architecture est parfois complétée par une base « ODS » (Operational Data Store), qui est un espace de stockage persistant dans lequel seront stockées les données sources à un niveau détaillé.
L’ODS pourra servir les besoins décisionnels ; il est à ce titre utilisé dans certaines architectures comme le socle de données du Data Warehouse. Mais, comme son nom l’indique, il a également vocation à servir les besoins opérationnels de l’entreprise.
Le Data Lake
Un Data Lake (ou Lac de données) est un système référentiel centralisé permettant de stocker et de gérer à bas coût de fortes volumétries de données structurées, semi-structurées et non structurées, dans leur forme brute à mesure qu’elles arrivent. Les données stockées n’ont pas vocation à être modélisées.
Le terme « Data Lake » semble être attribuable à James Dixon, CTO de Penthao, qui en 2010 faisait l’analogie avec un Data Mart :
« Si vous pensez à un Data Mart comme un stock d'eau embouteillée – nettoyé, emballé et organisé pour une consommation facile - le Data Lake est un grand plan d'eau dans un état plus naturel. Le contenu du Data Lake provient d’une source alimentant le lac et différents utilisateurs du lac peuvent venir examiner, plonger ou prendre des échantillons ».
L'idée sous-jacente d’une architecture Data Lake est ainsi d'avoir un espace unique collectant et archivant toutes les données requises par l'entreprise. Ce sont des données brutes, copies des systèmes sources ou de sources externes. Mais cela peut aussi être des données transformées utilisables pour diverses tâches, y compris du reporting, de l'analyse ou de l'apprentissage automatique.
L’un des éléments fondamentaux à noter lorsque l’on évoque le Data Lake est qu’il s’agit d’une architecture de type « schema on read ».
Cela signifie que la structuration et l’interprétation des données stockées dans le Data Lake se fait à la lecture, par l’utilisateur cherchant à exploiter les données. Cela offre une plus grande liberté lors de l’exploitation des données, sans être contraint par un schéma prédéterminé. Mais cela oblige aussi à avoir une grande maîtrise des données manipulées.
A contrario, le Data Warehouse est de type « schema on write », les données étant structurées au moment de leur stockage pour en permettre l’utilisation directe.
Vous lirez avec intérêt l’article suivant détaillant le concept de Data Lake :
http://www.journaldunet.com/solutions/dsi/1165409-qu-est-ce-que-le-datalake-le-nouveau-concept-big-data-en-vogue/
Ces bases étant posées, quel impact l’architecture de type Data Lake a-t-elle sur la mise en place d’une solution décisionnelle ?
Le terme « Data Lake » semble être attribuable à James Dixon, CTO de Penthao, qui en 2010 faisait l’analogie avec un Data Mart :
« Si vous pensez à un Data Mart comme un stock d'eau embouteillée – nettoyé, emballé et organisé pour une consommation facile - le Data Lake est un grand plan d'eau dans un état plus naturel. Le contenu du Data Lake provient d’une source alimentant le lac et différents utilisateurs du lac peuvent venir examiner, plonger ou prendre des échantillons ».
L'idée sous-jacente d’une architecture Data Lake est ainsi d'avoir un espace unique collectant et archivant toutes les données requises par l'entreprise. Ce sont des données brutes, copies des systèmes sources ou de sources externes. Mais cela peut aussi être des données transformées utilisables pour diverses tâches, y compris du reporting, de l'analyse ou de l'apprentissage automatique.
L’un des éléments fondamentaux à noter lorsque l’on évoque le Data Lake est qu’il s’agit d’une architecture de type « schema on read ».
Cela signifie que la structuration et l’interprétation des données stockées dans le Data Lake se fait à la lecture, par l’utilisateur cherchant à exploiter les données. Cela offre une plus grande liberté lors de l’exploitation des données, sans être contraint par un schéma prédéterminé. Mais cela oblige aussi à avoir une grande maîtrise des données manipulées.
A contrario, le Data Warehouse est de type « schema on write », les données étant structurées au moment de leur stockage pour en permettre l’utilisation directe.
Vous lirez avec intérêt l’article suivant détaillant le concept de Data Lake :
http://www.journaldunet.com/solutions/dsi/1165409-qu-est-ce-que-le-datalake-le-nouveau-concept-big-data-en-vogue/
Ces bases étant posées, quel impact l’architecture de type Data Lake a-t-elle sur la mise en place d’une solution décisionnelle ?
Data Warehouse vs. Data Lake
De nouveaux usages BI se font plus pressants ces dernières années, cherchant à donner plus d’autonomie aux analystes pour traiter leurs gisements de données, Big Data ou non.
Le Data Warehouse peine à couvrir ces nouveaux usages car par définition, c’est une architecture structurée pour répondre à des problématiques identifiées, en garantissant la cohérence et la pertinence des résultats.
Dans ce contexte, l’avenir du Data Warehouse est-il le Data Lake ?
Au regard des éléments décrits précédemment et au regard des technologies actuelles on est tenté de répondre par la négative. Deux caractéristiques majeures font défaut à ce jour dans un Data Lake :
• La réconciliation fonctionnelle des données provenant de différentes sources, via un langage commun porteur d’informations unifiées ;
• La fiabilité des données manipulées par l’utilisateur, permettant de s’assurer que les résultats produits reflètent strictement la réalité car basés sur des données exactes et exhaustives.
Néanmoins, pour répondre complètement à la question, il faut détailler les différents usages.
Le Data Warehouse peine à couvrir ces nouveaux usages car par définition, c’est une architecture structurée pour répondre à des problématiques identifiées, en garantissant la cohérence et la pertinence des résultats.
Dans ce contexte, l’avenir du Data Warehouse est-il le Data Lake ?
Au regard des éléments décrits précédemment et au regard des technologies actuelles on est tenté de répondre par la négative. Deux caractéristiques majeures font défaut à ce jour dans un Data Lake :
• La réconciliation fonctionnelle des données provenant de différentes sources, via un langage commun porteur d’informations unifiées ;
• La fiabilité des données manipulées par l’utilisateur, permettant de s’assurer que les résultats produits reflètent strictement la réalité car basés sur des données exactes et exhaustives.
Néanmoins, pour répondre complètement à la question, il faut détailler les différents usages.
Les usages
Le reporting d’entreprise
Le socle de tout système décisionnel est aujourd’hui de permettre la production de reporting décisionnels, voire opérationnels.
Il s’agit ainsi de mettre régulièrement à la disposition d’un grand nombre de personnes des rapports de suivi et de pilotage de l’entreprise, dont les chiffres ont été vérifiés et validés, sont reproductibles dans le temps (une même analyse produite à des périodes différentes doit présenter les mêmes résultats) et sont auditables (le cheminement pour générer le résultat est connu et documenté).
Il s’agit donc ici des usages « historiques », mais toujours bien présents des systèmes décisionnels, que l’on évoque une simple liste tabulaire ou un tableau de bord synthétique.
La « Data Discovery »
Pour pallier la rigidité que peuvent imposer les solutions de reporting historique (car les données doivent être validées et vérifiables), de nouvelles typologies d’outils cherchant à offrir plus d’autonomie à l’utilisateur dans la manipulation de ses données a émergé il y a quelques années. On les classe souvent dans les solutions de BI Agile ou encore de Data Visualisation.
Sans être exhaustif car le nombre d’acteurs est particulièrement important et en croissance constante, les éditeurs majeurs sont Tableau Software, Qlik ou encore Microsoft avec PowerBI.
Ces solutions cherchent à libérer les utilisateurs des contraintes imposées par les Data Warehouse et les logiciels associés, en leur donnant la possibilité d’analyser eux-mêmes et sans recours aux équipes informatiques les données dont ils ont besoin, en croisant le cas échéant les données standardisées de l’entreprise avec leurs propres jeux de données.
Ils offrent par ailleurs des capacités de croisement et de représentation des informations puissantes, permettant de mettre en relation des données sans être contraint par un cadre prédéterminé.
La population susceptible d’exploiter ces solutions est plus restreinte et de type analyste ou administrateur fonctionnel de données.
L’analyse prédictive
Dans le prolongement de la data discovery, la multitude des données existantes et utilisables par l’entreprise permet plus facilement de mettre en œuvre des algorithmes statistiques et prédictifs.
L’objectif est ici d’identifier des corrélations et des schémas reproductibles que l’on n’aurait pas détectés naturellement et qui permettent d’établir des projections réalistes sur les situations à venir.
Les données exploitées doivent être proches de la source, afin qu’aucun biais ne soit introduit par leur préparation. Il n’est pas nécessaire qu’elles soient exhaustives, mais l’échantillon doit être le plus large possible pour permettre une identification pertinente des patterns.
L’enjeu majeur pour produire des résultats cohérents et ne pas introduire de biais dans les résultats est ici la bonne compréhension des données manipulées et leur qualité au sens large. Si l’échantillon manipulé est trop restreint, incohérent ou incomplet, les projections seront erronées.
La population d’utilisateurs est relativement restreinte, de type statisticien ou « Data Scientist ». Ils maîtrisent parfaitement les contraintes et enjeux métier de l’entreprise.
Ils s’appuient sur des développements spécifiques ou des solutions de « Data Science » (DataIku, Alteryx, RapidMiner, …) et des langages statistiques comme R.
L’analyse en temps réel
L’analyse en temps réel est probablement l’usage premier des Big Data.
Il consiste à mener des analyses en temps réel (ou micro-batch à fréquence déterminée) sur les données mises à disposition par les objets connectés notamment, pour superviser les comportements et anticiper des comportements à venir.
C’est par exemple identifier en temps réel la défaillance d’un équipement pour permettre une intervention corrective rapide.
C’est également l’application d’algorithmes prédictifs, qui vont permettre d’anticiper la survenance de ces défaillances et de déterminer plus efficacement les politiques de maintenances préventives.
L’article suivant illustre cet usage :
http://www.decideo.fr/Siemens-combine-Hadoop-et-Teradata-pour-collecter-300-milliards-de-donnees-de-capteurs_a8759.html
Les données exploitées sont de manière générale brutes et adressées via des développements spécifiques.
Le socle de tout système décisionnel est aujourd’hui de permettre la production de reporting décisionnels, voire opérationnels.
Il s’agit ainsi de mettre régulièrement à la disposition d’un grand nombre de personnes des rapports de suivi et de pilotage de l’entreprise, dont les chiffres ont été vérifiés et validés, sont reproductibles dans le temps (une même analyse produite à des périodes différentes doit présenter les mêmes résultats) et sont auditables (le cheminement pour générer le résultat est connu et documenté).
Il s’agit donc ici des usages « historiques », mais toujours bien présents des systèmes décisionnels, que l’on évoque une simple liste tabulaire ou un tableau de bord synthétique.
La « Data Discovery »
Pour pallier la rigidité que peuvent imposer les solutions de reporting historique (car les données doivent être validées et vérifiables), de nouvelles typologies d’outils cherchant à offrir plus d’autonomie à l’utilisateur dans la manipulation de ses données a émergé il y a quelques années. On les classe souvent dans les solutions de BI Agile ou encore de Data Visualisation.
Sans être exhaustif car le nombre d’acteurs est particulièrement important et en croissance constante, les éditeurs majeurs sont Tableau Software, Qlik ou encore Microsoft avec PowerBI.
Ces solutions cherchent à libérer les utilisateurs des contraintes imposées par les Data Warehouse et les logiciels associés, en leur donnant la possibilité d’analyser eux-mêmes et sans recours aux équipes informatiques les données dont ils ont besoin, en croisant le cas échéant les données standardisées de l’entreprise avec leurs propres jeux de données.
Ils offrent par ailleurs des capacités de croisement et de représentation des informations puissantes, permettant de mettre en relation des données sans être contraint par un cadre prédéterminé.
La population susceptible d’exploiter ces solutions est plus restreinte et de type analyste ou administrateur fonctionnel de données.
L’analyse prédictive
Dans le prolongement de la data discovery, la multitude des données existantes et utilisables par l’entreprise permet plus facilement de mettre en œuvre des algorithmes statistiques et prédictifs.
L’objectif est ici d’identifier des corrélations et des schémas reproductibles que l’on n’aurait pas détectés naturellement et qui permettent d’établir des projections réalistes sur les situations à venir.
Les données exploitées doivent être proches de la source, afin qu’aucun biais ne soit introduit par leur préparation. Il n’est pas nécessaire qu’elles soient exhaustives, mais l’échantillon doit être le plus large possible pour permettre une identification pertinente des patterns.
L’enjeu majeur pour produire des résultats cohérents et ne pas introduire de biais dans les résultats est ici la bonne compréhension des données manipulées et leur qualité au sens large. Si l’échantillon manipulé est trop restreint, incohérent ou incomplet, les projections seront erronées.
La population d’utilisateurs est relativement restreinte, de type statisticien ou « Data Scientist ». Ils maîtrisent parfaitement les contraintes et enjeux métier de l’entreprise.
Ils s’appuient sur des développements spécifiques ou des solutions de « Data Science » (DataIku, Alteryx, RapidMiner, …) et des langages statistiques comme R.
L’analyse en temps réel
L’analyse en temps réel est probablement l’usage premier des Big Data.
Il consiste à mener des analyses en temps réel (ou micro-batch à fréquence déterminée) sur les données mises à disposition par les objets connectés notamment, pour superviser les comportements et anticiper des comportements à venir.
C’est par exemple identifier en temps réel la défaillance d’un équipement pour permettre une intervention corrective rapide.
C’est également l’application d’algorithmes prédictifs, qui vont permettre d’anticiper la survenance de ces défaillances et de déterminer plus efficacement les politiques de maintenances préventives.
L’article suivant illustre cet usage :
http://www.decideo.fr/Siemens-combine-Hadoop-et-Teradata-pour-collecter-300-milliards-de-donnees-de-capteurs_a8759.html
Les données exploitées sont de manière générale brutes et adressées via des développements spécifiques.
Quelle architecture BI ?
A la lecture de ces cas d’usages, on identifie que la nature des données exploitées n’est pas la même, avec des exigences en termes de granularité, de définition, de cohérence et de fiabilité qui diffèrent.
Cela se traduit dans les architectures techniques sous-jacentes.
Ainsi, le Data Lake est le Data Warehouse représentent deux couches techniques complémentaires pour servir ces usages.
Le Data Lake va adresser les besoins d’analyse pour lesquels les données doivent être proches de la source et relativement peu transformées.
L’absence de couche sémantique permettant d’interpréter et de réconcilier les données mises à disposition n’est pas un frein, car les utilisateurs exploitant ces informations sont peu nombreux et « spécialisés ». Ils maîtrisent parfaitement les données et les besoins métier et savent exploiter les outils statistiques et analytiques mis à leur disposition.
Ces utilisateurs prennent en charge, de par leur expertise et leur connaissance fonctionnelle, l’interprétation de la donnée, en réalisant des analyses successives. Ils affinent progressivement leurs besoins, répondent de façon itérative à des questions plus précises et in fine participent à la compréhension et la documentation des données manipulées et des informations produites.
Se faisant, ils produisent des analyses qui pourront à terme être industrialisées pour devenir récurrentes et accessibles à une large population.
Ces analyses récurrentes et fiabilisées ont vocations à être industrialisées via le Data Warehouse. Elles pourront ainsi être diffusées plus largement au sein de l’entreprise.
Cela se traduit dans les architectures techniques sous-jacentes.
Ainsi, le Data Lake est le Data Warehouse représentent deux couches techniques complémentaires pour servir ces usages.
Le Data Lake va adresser les besoins d’analyse pour lesquels les données doivent être proches de la source et relativement peu transformées.
L’absence de couche sémantique permettant d’interpréter et de réconcilier les données mises à disposition n’est pas un frein, car les utilisateurs exploitant ces informations sont peu nombreux et « spécialisés ». Ils maîtrisent parfaitement les données et les besoins métier et savent exploiter les outils statistiques et analytiques mis à leur disposition.
Ces utilisateurs prennent en charge, de par leur expertise et leur connaissance fonctionnelle, l’interprétation de la donnée, en réalisant des analyses successives. Ils affinent progressivement leurs besoins, répondent de façon itérative à des questions plus précises et in fine participent à la compréhension et la documentation des données manipulées et des informations produites.
Se faisant, ils produisent des analyses qui pourront à terme être industrialisées pour devenir récurrentes et accessibles à une large population.
Ces analyses récurrentes et fiabilisées ont vocations à être industrialisées via le Data Warehouse. Elles pourront ainsi être diffusées plus largement au sein de l’entreprise.
Data Lake et Data Warehouse, deux outils complémentaires
Il n’est pas possible de considérer en l’état actuel des choses que le Data Lake peut et à vocation à remplacer définitivement le Data Warehouse.
Les besoins de reporting fiables, standardisés et accessibles à une large population d’utilisateurs restent bien présents dans les entreprises et ne peuvent être pris en charge de façon satisfaisante autrement que par une architecture de type Data Warehouse.
Néanmoins, la mise en place d’un Data Lake, permettant de collecter et de stocker largement les données de l’entreprise et de son environnement, offre de nouvelles possibilités d’analyse.
Celles-ci sont moins guidées et sont accessibles à une population plus limitée. Mais elles permettent d’être plus réactives et plus ouvertes sur l’anticipation des situations et la valorisation du capital données de l’entreprise.
Bien qu’en cours de stabilisation, le paysage technologique évolue encore beaucoup. Nous vivons probablement aujourd’hui la même révolution que celle vécue il y a 30 ans avec la démocratisation de la base de données relationnelle.
Mais les bases sont à présent jetées et le reste de l’histoire s’écrit dès à présent. Les outils « Data » (Data Viz, Data Preparation, Data Science, …) qui deviennent maturent en est l’une des preuves.
Les besoins de reporting fiables, standardisés et accessibles à une large population d’utilisateurs restent bien présents dans les entreprises et ne peuvent être pris en charge de façon satisfaisante autrement que par une architecture de type Data Warehouse.
Néanmoins, la mise en place d’un Data Lake, permettant de collecter et de stocker largement les données de l’entreprise et de son environnement, offre de nouvelles possibilités d’analyse.
Celles-ci sont moins guidées et sont accessibles à une population plus limitée. Mais elles permettent d’être plus réactives et plus ouvertes sur l’anticipation des situations et la valorisation du capital données de l’entreprise.
Bien qu’en cours de stabilisation, le paysage technologique évolue encore beaucoup. Nous vivons probablement aujourd’hui la même révolution que celle vécue il y a 30 ans avec la démocratisation de la base de données relationnelle.
Mais les bases sont à présent jetées et le reste de l’histoire s’écrit dès à présent. Les outils « Data » (Data Viz, Data Preparation, Data Science, …) qui deviennent maturent en est l’une des preuves.