Nombreux sont les professionnels de la data qui se posent les questions sur la différence entre le Data Lake et le Data Warehouse. Certains ne saisissent pas le sens ni l’utilisation de ces deux notions dans le stockage de données en Big Data. Dans cette chronique, nous allons définir le Data Warehouse, le Data Lake. Ensuite nous montrerons le positionnement de chacune de ces notions dans la chaîne de valorisation des données et enfin nous vous présenterons les différences notables entre elles afin que vous soyez en même d’identifier du Data Lake ou du Data Warehouse, la stratégie qui est plus adéquate pour votre projet Big Data.
Par essence, l’activité d’une entreprise est multi-process. En d’autres termes, pour atteindre son objectif de gestion, l’entreprise a besoin de découper son activité principale en plusieurs processus métiers, par exemple, le processus d’achat, le processus de vente, le processus d’exploitation, les processus de ressources humaines et bien d’autres. Chacun de ces processus génère des données opérationnelles qui sont le plus souvent capturées soit à partir d’une application spécialisée telle qu’un ERP (Entreprise Ressource Planning) type Oracle, SAP, PeopleSoft, soit alors à travers des feuilles de calcul Excel (ou des fichiers plats, csv, etc.). Il s’en suit un « silotage des données » qui empêche au management d’avoir une vision globale de l’activité de l’entreprise : l’application de finance capture les données de la finance, l’application de logistique capture les données générées par le processus Logistique, l’application RH capture les données générées par les RH etc. Comme ces applications sont distinctes, propres à chaque processus métier, l’entreprise se retrouve avec plusieurs bases de données différentes.
Sommaire
Le Data Warehouse : le point de collecte central des données
Le Data Warehouse est la première solution d’intégration des données de ces différentes applications (ou bases de données). A titre de rappel si vous n’avez pas encore lu le second ouvrage du projet Maîtrisez l’utilisation des technologies Hadoop, l’intégration est une stratégie informatique qui consiste à transférer toutes les données produites par des applications dans un répertoire unique afin que les utilisateurs et les autres systèmes de l’entreprise puissent y accéder. Pour faire simple, intégrer les applications c’est homogénéiser et fournir une vue unifiée des données qu’elles possèdent. Aussi simple que cette solution parait, elle pose deux problèmes majeurs : premièrement, intégrer les données qui proviennent de différentes applications est très complexe, car un couplage très fort traduit par des connexions point-à-point existe entre ces différentes applications. Les applications ne sont pas complètement indépendantes, elles sont interfacées pour exploiter les données l’une de l’autre telle que l’illustre la figure suivante.
Deuxièmement, l’intégration de ces applications nécessite de les rendre toutes compatibles avec un grand nombre d’API ou de formats d’échange, ce qui n’est pas toujours possible puisque les applications sont souvent propriétaires et donc compatibles avec des API spécifiques. Au-delà du problème de silos que posent les données, il y’a aussi l’aspect gouvernance de ces données. En effet, avec les multiples usages qui sont faits de la donnée par les utilisateurs, viennent des enjeux plus élevés, notamment les enjeux sécuritaires, légaux, d’intégration, de conformité, à la fois pour l’entreprise et pour l’individu. On entend tous les jours dans la presse ou sur Internet des cas d’entreprises ayant subi le piratage de leur système informatique ou de leurs données à cause d’une erreur d’inattention des employés. Face à ces risques, les entreprises ont besoin de contrôler et de maîtriser l’usage de la donnée aussi bien à l’intérieur de l’entreprise qu’à l’extérieur. Cela demande donc de définir les politiques de qualité de données, les politiques de sécurité de données, les politiques d’acquisition de données, les politiques de conformité des données aux législations en vigueur (Sarbanes Oxley, Patriot Act, CNIL, RGPD, etc.) et s’assurer que les données sont utilisées selon les politiques et les référentiels de l’entreprise. La gouvernance implique donc nécessairement au préalable une suppression des silos de données dans l’organisation, et une vue unifiée et homogène de toutes les données de l’entreprise. Il faudrait donc quitter le schéma de la figure 1 pour le schéma de la figure ci-après.
Dès lors, le Data Warehouse intervient comme répertoire central et comme cadre d’homogénéisation de toutes les données de l’entreprise. Son but est de fournir une vision unifiée et homogène de toute la data de l’entreprise. Il centralise toutes les données opérationnelles de l’entreprise dans un SGBDR et les organise en sujets métiers, qui sont mis à la disposition des utilisateurs métier correspondants. Les sujets métiers sont mis à la disposition des utilisateurs métier correspondants. Par exemple, le sujet finance regroupe toutes les données liées à la finance, qui est ensuite mis à disposition des analystes financiers.
Formellement, le Data Warehouse ou encore Entrepôt de données, en tant que concept, a été inventé en 1980 par Bill Inmon. Celui-ci le définit Formellement comme : « 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 » :
- 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.). Ce point central ne fait pas forcément référence à la centralisation des données en un lieu physique précis ou dans une machine physique précise, l’idée c’est réussir à unifier et à connecter toutes les données d’une entreprise en utilisant un référentiel commun ;
- 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 ? »
Ainsi, en tant que concept, le Data Warehouse sert de point d’intégration des données opérationnelles et aussi de point de distribution de ces données dans les mains des utilisateurs métiers. L’idée du Data Warehouse c’est :
- 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) ;
- é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 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.
Le Data Warehouse est l’approche qui jusqu’à présent a été utilisée pour ingérer les données de l’entreprise. Pour plus de détails sur la stratégie de Data Warehouse et son implémentation dans votre projet, nous vous recommandons l’ouvrage de Bill Inmon, qui est la référence dans le domaine : Building the Data Warehouse, édition Wiley & Sons
Du Data Warehouse au Data Lake
Malgré la robustesse du Data Warehouse, il n’est plus adapté au contexte actuel. En effet, l’ère Numérique se caractérise par la croissance des différents types d’actifs de données stockées. Les données stockées ne sont plus juste des données structurées d’ERP, mais ce sont des données aussi diverses que les logs d’activité des serveurs Web, les logs d’appels d’un centre appel, les données des réseaux sociaux qui combinent contenus textuels, images, audio et vidéos, les vidéos de centre de surveillance, les données de capteurs etc. Toutes ces données sont générées à une vitesse très élevée et sont stockées dans des formats non-structurés. Ces nouvelles sources de données créent de nouvelles pressions pour l’acquisition rapide, l’absorption, et l’analyse tout en maintenant la cohérence entre tous les actifs de données existantes. Là où en environnement structuré, il y avait des schémas clairs pour l’acquisition, l’échange, l’analyse et la restitution des données, aujourd’hui, l’entreprise doit repenser ses approches de gestion de données pour extraire un signal utilisable de toutes les nouvelles sources de données.
De plus, on assiste à une augmentation de la demande de l’intégration temps réel des résultats analytiques. Il y a de plus en plus de personnes avec une expansion de la variété des rôles qui sont des clients des résultats analytiques. La croissance est spécialement notable dans des entreprises où les processus métiers sont augmentés pour intégrer pleinement les modèles statistiques afin d’optimiser leur performance. Comme exemple, une entreprise de grande distribution peut monitorer les ventes en temps réel de milliers d’unités de gestion de stocks sur des centaines de points de vente, et les logs minute-par-minute des ventes. Fournir ces volumes de données massifs à une communauté de différents utilisateurs pour une analyse simultanée donne de nouvelles pistes et capacités qui n’ont jamais existé auparavant : permettre aux acheteurs d’apprécier les tendances d’achat afin de prendre des décisions plus précises concernant le catalogue de produits ; aux spécialistes de produits de considérer des moyens alternés d’empaqueter les produits ensemble ; aux professionnels de gestion de stocks de faire de l’achalandage plus facilement dans les entrepôts ou les magasins ; aux professionnels de Pricing d’ajuster instantanément les prix des différents points de vente, entre autres. L’utilisation des techniques d’analyse de données dans le contexte actuel requiert un accès en temps réel aux données et donc la capacité du système de stockage à livrer la donnée le plus rapidement possible. Le Data Warehouse a été conçu pour le stockage des données structurées et ne fournit pas d’accès en temps réel à ces données.
Comme nous l’avons dit plus tôt, pour résoudre ces challenges, l’approche la plus appropriée consiste à distribuer le stockage des données et à paralléliser leurs traitements sur un cluster Hadoop. Les technologies utilisées pour implémenter le Data Warehouse ne permettent ni le stockage distribué, ni le parallélisme des requêtes des utilisateurs. Ainsi, les entreprises doivent migrer toutes leurs données vers un cluster Hadoop pour fournir un cadre unifié de traitement et un accès rapide à la donnée.
Avec la baisse des coûts de stockage de données et du coût des ordinateurs, Hadoop peut être envisagé comme point unifié d’accès aux données et le HDFS se présente comme l’option la plus profitable à la fois en termes de performance et en termes de coûts financiers pour le stockage et le traitement des données. Le HDFS peut être utilisé comme répertoire central afin d’historiser diverses sources et divers formats de données, qu’ils soient structurés ou non-structurés. Dans le Data Warehouse, les données doivent être stockées selon un modèle multidimensionnel et les analyses qui peuvent se faire sur les données doivent être prédéfinies. Or, le fait que le HDFS n’exige pas que les données soient stockées selon un modèle particulier de données favorise la capture de nouvelles sources de données et le rend plus flexible pour les analyses de données. Cette approche où Hadoop est utilisé comme le point d’accès unique à toutes les données de l’entreprise est qualifié de Data Lake. Nous allons définir la notion de Data Lake et vous allez voir que ce concept n’a pas la même signification que celle qui est répandue couramment et à laquelle vous pensez peut-être intuitivement.
Définition du Data Lake
L’expression « Data Lake » a été conçue par James Dixon, le directeur technique de Pentaho à la date de publication de cet article . Pentaho est un éditeur logiciel de solution de Big Data. Comme tout concept qui émerge, le Data Lake s’est vu attribué une multitude de définitions, pour la majorité aussi erronées les unes que les autres. Personne ne connait mieux un concept que son auteur. Nous allons donc définir le Data Lake non pas selon ce que nous pouvons penser intuitivement, mais selon la façon dont James Dixon le définit et comme toute définition se donne toujours dans un contexte, nous allons revenir sur le contexte dans lequel il l’a créé.
La majorité des applications métiers sont essentiellement des implémentations informatiques de processus métier (ou applications de workflow) ou encore état machine. Il s’agit des CRM, des ERP, des SCM (Supply Chain Management), des logiciels de centre d’appel, des applications de finance, ou autre application métier. Les entités ou objets du monde réel comme les employés, les clients, les commandes représentés dans ces applications sont stockées comme des collections d’attributs qui définissent leur état à un moment précis. Les attributs sont communément appelés des champs ou colonnes. Comme attributs de ces objets, on peut citer le nom du client, son adresse postale, la date de commande, la quantité achetée, ainsi de suite. C’est la valeur de ces attributs au moment où on les consulte qu’on qualifie techniquement d’état machine ou d’état. Nous reviendrons sur cette notion d’état machine tout à l’heure. Les états machine sont très efficaces lorsqu’il s’agit de répondre aux questions concernant l’état des choses, en d’autres termes, l’état machine permet de faire des analyses de Reporting, qui indiquent la situation de l’objet à un moment donné ou qui indiquent ce qui s’est passé. Cependant, lorsqu’il faut faire des analyses prédictives ou des analyses qui fournissent une vision à moyen ou long terme de l’objet, cela devient plus compliqué. Normalement, pour être à même de pouvoir faire des analyses prédictives, il faut tracer les différents états des attributs dans un historique qu’on appelle un journal. Ce journal prend généralement la forme des tables relationnelles classiques ou des fichiers CSV qui listent l’historique des changements d’états des attributs de l’objet à travers le temps. Dans un Data Warehouse par exemple, l’historique des entités du monde réel est collecté dans des tables appelées tables de fait. De cette façon, le journal peut être agrégé pour un ensemble d’attributs d’un ou de plusieurs objets du système pour en obtenir une vue dans le temps. Cependant, l’historique n’est pas toujours disponible pour tous les objets. En général, le métier choisit un ou plusieurs objets d’intérêt et c’est pour ces objets que l’historique est collecté. Ainsi, si on souhaite subitement analyser l’évolution des attributs d’un objet qui au départ n’avait pas d’intérêt (et donc pour lequel l’historique n’a pas été collecté), cela sera tout simplement impossible. Malheureusement, cette situation est très courante avec l’approche Data Warehouse. Plus précisément, la construction d’applications d’analyse de données dans l’approche Data Warehouse suit le schéma suivant : les utilisateurs soumettent un ensemble de questions auxquelles ils veulent que le Data Warehouse réponde, une copie des données concernant les attributs nécessaires pour répondre à ces questions est extraite du Data Warehouse pour constituer un « Data Mart », et c’est à partir de ce data Mart qu’ils obtiennent les réponses à leurs questions. Chaque Data Mart constitue le Data Warehouse d’un processus métier et toute application d’exploitation de données est construite sur un Data Mart.
C’est ici que l’approche Data Lake intervient. Le Data Lake résout ce problème de la façon suivante : en profitant de la baisse des coûts des ordinateurs, toutes les données de l’entreprise sont stockées dans un répertoire centralisé hébergé sur un cluster d’ordinateurs commodes. Ensuite, les Data Marts du Data Warehouse sont alimentés pour satisfaire les demandes traditionnelles et permettre les requêtes ad-hoc et le Reporting sur les données du Data Lake pour de nouvelles questions. Ainsi, l’idée du Data Lake est d’historiser tous les objets de l’entreprise afin de permettre toute sorte d’analyses prédictives et descriptives. Le Data Lake lève la limitation qui consistait à préétablir les types et les modèles d’analyse de données qui pouvaient être faits et construits sur le Data Warehouse en historisant uniquement certains attributs. Le Data Lake retient et historise tous les attributs de tous les objets de l’entreprise. Ainsi, il n’est pas juste question de stocker toutes les données de l’entreprise dans Hadoop, le Data Lake n’est pas un fourre-tout de données. Dans le Data Warehouse, historiser les données des objets qui ne sont pas pertinents pour la prise de décision est coûteux aussi bien en termes financiers qu’en termes technologiques et inutile (puisqu’ils ne répondent pas aux besoins des utilisateurs à ce moment précis). La baisse des coûts informatiques permet aujourd’hui de tout stocker à coût dérisoire à un niveau de profondeur et de granularité plus élevés pour couvrir les futurs besoins d’analyse de données. Vous trouverez plus de détails sur le Data Lake en consultant le blog personnel de James Dixon.
Comme vous l’avez vu, le Data Lake augmente de façon substantielle le potentiel d’analyse de données. Cependant, bien que son architecture basée sur Hadoop comme point d’accès unique à la donnée de toute l’entreprise semble idéale, elle pose un problème dans sa mise en œuvre : Hadoop, ou plutôt le HDFS sur lequel est basé Hadoop est un système batch, inadapté pour l’ingestion rapide des flux continus de données et les opérations d’écriture/lecture sur ces flux. Ce problème n’est pas unique à Hadoop. Même le Data Warehouse ne fournit pas un accès direct et rapide aux données. De plus, les données doivent être transformées selon les règles de normalisation qui garantissent l’homogénéité des données que ce soit dans le Data Lake ou dans le Data Warehouse. Dans les deux cas de figure, pour résoudre ce problème, une couche intermédiaire est rajoutée entre le Data Lake/Data Warehouse et les sources opérationnelles de données. Dans l’approche Data Warehouse, cette couche intermédiaire s’appelle un ETL.
l’ETL à la rescousse
L’ETL, Extract Transform & Load est le process dans l’environnement informatique qui est chargé d’extraire les données des sources opérationnelles (EXTRACT), de les transformer de sorte qu’elles soient conformes aux règles d’homogénéisation du Data Warehouse (TRANSFORM) et de les charger dans le Data Warehouse (LOAD). Il est habituellement comparé à la cuisine d’un restaurant, où les ingrédients sont transformés en plats savoureux avant d’être servis au client. L’ETL fonctionne comme un système Batch et par défaut, charge les nouvelles données dans le Data Warehouse toutes les nuits. Dans certains métiers, un composant supplémentaire peut être rajouté au système pour améliorer la fréquence de rafraichissement des données du Data Warehouse, ce composant s’appelle l’ODS, Operational Data Store. L’ODS est une base de données opérationnelle qui est fréquemment mise à jour avec les données opérationnelles, généralement dans le but de répondre aux besoins d’analyses urgentes des données.
Malheureusement, malgré son efficacité, l’ETL ne peut pas être utilisé comme pont de connexion dans une approche Data Lake et ceci pour deux raisons principales :
- Le traitement en Batch : l’ETL est un processus Batch qui charge les données périodiquement, il ne peut pas être utilisé pour charger les données qui arrivent en flux continu. Dans son principe même, l’ETL est composé d’un ensemble de routines (fonctions et procédures) qui transforment les données, gèrent leur qualité et appliquent une série de normalisations aux données avant de les charger par lots dans le Data Warehouse ;
- Les normalisations : l’idée du Data Lake c’est de fournir l’historique de tous les états de différents attributs des entités manipulées par l’entreprise. Le Data Warehouse exige que les données soient normalisées via l’ETL pour fournir une vision homogène et unifiée de toutes les données de l’entreprise. Cette homogénéisation entraîne dans la majorité des cas une perte d’information nécessaire pour des Reporting et préjudiciable pour les analyses prédictives. D’ailleurs c’est à cause de cela que les études d’apprentissage statistique ne s’appuient pas sur les données chargées dans le Data Warehouse, mais directement sur les données de la source opérationnelles ;
Dans le cadre du traitement des données générées en streaming, pour ces limites de l’ETL, les acteurs du marché ont remplacé l’ETL par des outils d’ingestion streaming. Kafka et Flume, sont deux exemples de tels outils. Du coup, notre architecture « Data Lake » ressemble à la figure suivante.
Pour réussir à ingérer les données en flux continu et les délivrer efficacement dans le Data Lake, les outils d’ingestion s’appuient sur deux éléments particuliers : une structure de données particulière appelée le Log et un système de messagerie Publish/Subscribe. Cliquez sur le lien suivant pour télécharger gratuitement le système de messagerie Publish/Subscribe le plus adéquat pour l’ingestion streaming des données en Big Data : Apache Kafka
Ressources complémentaires
Pour approfondir votre apprentissage sur le stockage de données en Big Data, notamment le Data Lake, le Data Warehouse, le HDFS, les Data Marts, l’ETL, les systèmes de messagerie Publish/Subscribe, Apache Kafka, n’hésitez pas à vous appuyer sur les ressources suivantes :
- le blog personnel de James DIXON pour comprendre comment il définit le Data Lake : https://jamesdixon.wordpress.com/2014/09/25/data-lakes-revisited/
- pour comprendre la stratégie de stockage la plus adaptée dans un contexte de fort volumétrie de données, et grande variété d’actifs de données, lisez notre chronique suivante : https://www.data-transitionnumerique.com/introduction-a-hadoop-et-l-ecosysteme-big-data/
- Pour comprendre l’ingestion des données en streaming et à large échelle avec le Data Lake, téléchargez gratuitement notre livre numérique sur Apache Kafka : https://www.data-transitionnumerique.com/extrait-livre-big-data-streaming/
- Nous avons développé une formation spécialisée dans le stockage et le traitement à large échelle des données. Elle vous aidera à mettre en place une architecture de stockage à large échelle de données : https://www.data-transitionnumerique.com/formation-big-data-streaming/
- vous pouvez aussi suivre une session de cours extraite de cette formation en vous rendant à l’adresse suivante : https://www.data-transitionnumerique.com/apache-kafka-mode-de-fonctionnement/
Lectures recommandées
Vous pouvez aller encore plus vite et gagner énormément de temps en lisant les ouvrages suivants. Nous vous les recommandons vivement pour développer vos compétences sur le sujet de stockage de données en Big Data.
Hadoop Devenez opérationnel dans le monde du Big Data, la fondation du Data Lake c’est le HDFS. Le HDFS est l’option la plus profitable à la fois en termes de performance et en termes de coûts financiers pour le stockage et le traitement des données à large échelle. Cet ouvrage vous aidera à comprendre comment fonctionne le HDFS et comment le stockage est distribué dans un cluster.
Big Data Streaming – le traitement streaming & temps réel des données en Big Data, cet ouvrage, qui est le troisième du projet DTN, vous aidera concrètement à comprendre le Data Lake, les différentes contraintes et exigences qu’il impose au système informatique, et les architectures appropriées pour son implémentation. Il vous aidera également à monter en compétence sur les technologies principales qui permettent d’implémenter un Data Lake.
Building the Data Warehouse, la référence en matière de Data Warehouse. Cet ouvrage est l’ouvrage emblématique qui a introduit dès les années 90, le concept de Data Warehouse aux DSI. Ainsi, si vous souhaitez appronfondir vos connaissances sur le Data Warehouse, cet ouvrage est LE livre à vous procurer.
The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling. Bill Inmon a donné les concepts théoriques du Data Warehouse. Mais c’est Ralph Kimball qui avec son approche « bottom up », a posé les fondations de l’implémentation véritable en mode projet d’un Data Warehouse. Il a notamment introduit la notion de « Data Mart » comme élément de base de l’implémentation d’un Data Warehouse. Ainsi, pour apprendre techniquement à implémenter un Data Warehouse, nous vous recommandons de vous procurer cet ouvrage.
Bonjour, j’ai pas compris comment le fait que HDFS n’exige pas que les données soient stockées selon un modéle particulier de données favorise la capture de nouvelles sources de données et le rend plus flexible pour les analyses de données.
Bonjour Marwa,
comme nous l’avons mentionné dans la chronique, l’intérêt du HDFS est de stocker des données de différentes natures (JSON, CSV, .gzip, parquet, avro, video, audio, etc…). Si le HDFS peut stocker tous ces types de données, c’est parce qu’il n’y’a pas de MCD, ni de schéma en étoile ou flocon de neige (en clair une couche sémantique) modélisée en amont qui impose la structure de données.
Prenons un exemple simple : lors du stockage de données dans un data warehouse classique, il faut avoir conçu le schéma multidimensionnel, qui impose d’office la structure et le type de données qui peuvent être stockées (tables relationnelles uniquement).
Grâce à cette absence de couche sémantique sur le stockage dans le HDFS, on a donc une plus grande liberté d’action sur ce qu’on peut faire avec les données.
Cette réponse répond-elle à votre question ?
D’accord merci bien pour l’explication
Bonjour,
J’ai une question à poser , il est important d’avoir une réponse. Pourquoi on a besoin de construire un datalake pour le stockage de donneés alors qu’on a déjà le HDFS?
Je serais reconnaissante si vous me répondrez.
Bonjour Marwa,
Oui on pourrait se passer du Data Lake, et simplement stocker toutes les données dans le HDFS.
Le problème avec cette approche est qu’on se retrouve rapidement avec un « fourre-tout » où les données sont simplement stockées sans logique particulière.
Pour faire des analyses décisionnelles efficaces (peu importe que ce soit à travers un Data Mart, un Data Warehouse ou un Data lake), 2 étapes sont indispensables :
1- il faut construire une couche sémantique (un modèle) qui indique les liens métiers qui existent entre les données (par exemple une commande est toujours liée à un client et contient au moins un article). C’est ce lien qui permet plus tard de faire des requêtes qui produisent des résultats qui font sens.
2 – il faut pré-traiter les données en amont afin qu’il soit conforme à la couche sémantique qu’on a définit (par exemple supprimer les doublons, s’assurer que chaque commande a bien un client et au moins un article, vérifier les adresses, etc…)
Le Data Lake est nécessaire pour construire la couche sémantique. Par contre à la différence du Data Lake où la couche sémantique impose les données qui peuvent être stockées, le Data Lake grâce aux faibles coûts du HDFS permet d’historiser une plus grande profondeur de données et de construire la couche sémantique après le stockage de données.
En résumé, Data Lake = Stockage HDFS + couche sémantique en aval
Cela répond-t’il à ta question ?
Oui, merci bien
bonjour,
est ce que le HDFS pour le stockage de données seulement, il ne n’offre pas d’autres fonctionnalités comme l’accès et l’interrogation? Ou bien ces fonctionalités c’est pour la base de données Hbase?
Bonjour Marwa,
le HDFS n’est utilisé que pour le stockage de données en environnement distribué. C’est un système de fichiers distribué. Non, le but d’un système de fichiers n’est pas d’offrir des fonctionnalités d’interrogation de données, mais de produire l’accès utilisateur aux données stockées sur le disque dur. Pour plus de détails sur un système de fichiers ou le HDFS, nous vous recommandons l’ouvrage « Hadoop – Devenez opérationnel dans le monde du Big Data »
Cela répond-t’il à votre question ?
Un peu
Voici un lien vers le lexique du HDFS sur le site : https://www.data-transitionnumerique.com/lexique/hdfs/
Peut-être cela vous aidera.