Data Lake vs Data Warehouse – Quelle base de données pour quel besoin ?

Pour centraliser les données de votre entreprise dans une base de données de référence, vous avez deux principales solutions : construire un Data Lake ou mettre en place un Data Warehouse. Ce sont deux approches assez différentes :

• Le Data Lake stocke les données en vrac, qu’elles soient structurées, semi-structurées ou non structurées. C’est une « baignoire de données » dont les premiers utilisateurs sont les Data Scientists.
• Le Data Warehouse, couplé à un ETL, stocke des données structurées destinées à des usages métier qualifiés en amont.

Nous allons développer dans cet article les principales différences entre Data Lake et Data Warehouse, en commençant par bien définir chacune des deux options. Vous pourrez ainsi identifier celle qui correspond le mieux à votre besoin.

Tableau de synthèse des différences entre Data Lake et Data Warehouse

Qu’est-ce qu’un DataWarehouse ? [Définition]

Un DataWarehouse (entrepôt de données en français) désigne un dispositif technologique destiné à stocker et gérer des données issues de différents systèmes sources à des fins d’analyse exploratoire. Le terme « dispositif » est important dans la mesure où un Data Warehouse ne se réduit pas à un seul outil, mais est constitué d’une combinatoires de composants technologiques. Essentiellement : une base de données cloud (Snowflake, Amazon Redshift…), un outil ETL pour gérer les flux de données et un outil de BI pour réaliser les analyses de données. Ce sont les 3 briques d’une architecture Data Warehouse. Il s’agit d’un dispositif technologique au service de l’analyse décisionnelle qui vise à transformer des données en informations.

Un entrepôt de données stocke des données structurées, en provenance essentiellement des systèmes transactionnels (OLTP). Ces données sont pour la plupart des métriques et les attributs décrivant des métriques. Les données non-structurées, comme les logs web ou les données d’activité sur les réseaux sociaux, sont largement ignorées. Nous y reviendrons.

Les 4 fonctions du Data Warehouse

Le Data Warehouse centralise les données et rend possible leur unification. Il créé une source unique de vérité. C’est la raison pour laquelle les dispositifs Data Warehouses sont souvent utilisés pour construire un Référentiel Client Unique. Maintenant que nous connaissons la finalité du Data Warehouse, quelles sont les fonctions qui permettent d’atteindre cette finalité ? En définitive, elles peuvent se résumer à 4 :

• L’extraction. La base Data Warehouse, via l’outil ETL auquel elle est branchée et qui partie intégrante du dispositif, extrait les données en provenance de toutes les sources de données qui l’intéresse. Elle se branche aux systèmes sources et résume toutes les bases.
• Le nettoyage. Le Data Warehouse nettoie les données qu’il ingère, procède aux déduplications et reformatages nécessaires pour organiser les données qu’il stocke de manière cohérente et structurée. Le Data Warehouse est une base multi-tables très organisée.
• La transformation. Un entrepôt de données, ou plutôt le système ETL auquel il est branché (l’ETL joue un rôle clé comme on le voit), permet de réaliser les transformations nécessaires afin d’adapter les modèles de données aux cas d’usage cibles du Data Warehouse : BI, reporting, segmentation, création d’agrégats marketing…Les données ne sont jamais chargées dans l’entrepôt de données avant d’être nettoyées, normalisées et transformées par le process ETL.
• La mise à jour des données. Les données stockées dans le Data Warehouse sont mises à jour continuellement (de plus en plus en quasi temps réel), via les sources de données auxquelles il est connecté. Il enrichit et modifie constamment les données historiques par l’intégration des données fraiches issues de ces sources.

La suite de l’article complétera la définition du Data Warehouse, mais sachez que nous avons déjà publié de nombreux articles sur ce dispositif de Data Management. Nous vous invitons à parcourir notre blog pour approfondir les points qui vous intéressent.

Qu’est-ce qu’un Datalake ?[Définition]

Passons maintenant au deuxième candidat : le Data Lake. Un Data Lake est une base de données qui permet de stocker de larges volumes de données structurées, semi-structurées et non-structurées. Le Data Warehouse évoque le dur, le solide, l’organisé, l’articulé, le structuré, le compartimenté – la rationalité en somme. Le Data Lake, à l’inverse, évoque le liquide, le fluide, le mélange, l’inorganique, le non-structuré. Le Data Warehouse package l’eau dans des bouteilles organisées sur des étagères là où le Data Lake fait justement office de « lac ». Il est un immense contenant prêt à accueillir de gros volumes de données « en vrac ». L’image vaut ce qu’elle vaut (elle n’est d’ailleurs pas de nous) mais permet de mettre le doigt sur la différence principale entre les deux dispositifs. Pour l’anecdote, ce serait James Dixon, CTA de Pentaho, qui aurait utilisé pour la première fois le terme de « Data Lake » pour désigner ces immenses bases de données terrains de jeu des Data Scientists.

Le Data Lake stocke des données de tous ordres et en grande quantité, qu’elles soient structurées, semi-structurées (comme XML, JSON ou encore CSV) ou carrément sans structure. Les technologies utilisées pour construire un Data Lake, parce que largement open source (le framework Hadoop en premier lieu), rendent le stockage très peu onéreux. Il n’y a pratiquement aucunes limites en termes d’espace de stockage.

Les 2 caractéristiques principales d’un Data Lake

Le lac des données accueille les données comme elles sont, dans leur format natif, sans transformation. Nous voilà donc devant les deux caractéristiques principales du Data Lake :

• La capacité à stocker d’énormes volumes de données (Quantité). Les solutions Data Lake permettent d’échapper aux limites de stockage des solutions Data Warehouse.
• La capacité à accueillir les données dans leur état d’origine, sans transformation (Qualité).

Pour poursuivre la métaphore, soulignons que le Data Lake est connecté à toutes les « sources » de données suivant un stream de données en temps réel – ces sources étant comme les petits ruisseaux qui plongent dans le lac. Certaines mauvaises langues préfèrent parler de marécage (swamp) plutôt que de lac, pour souligner le côté un peu « bordélique » et littéralement « déréglé » d’un Data Lake. Nous reviendrons à la toute fin de notre article sur cette question.

Les images permettent d’obtenir une première compréhension de la différence entre Data Warehouse et Data Lake. Mais les images ne remplacent pas les concepts. Quelques précisions s’imposent donc !

L’approche ETL (system.in.write) vis l’approche ELT (system.in.read)

Si la donnée entre dans le lac dans son état d’origine, elle fait bien sûr l’objet de transformations après coup. Les Data Scientists prélèvent des échantillons de données, leur applique des transformations et des modèles en fonction de leurs cas d’usage et de leurs besoins d’analyse. Le schéma de données est défini en aval, et non en amont comme c’est le cas dans l’approche Data Warehouse.

Le processus d’extraction des données est le même dans les deux approches Data Warehouse et Data Lake. C’est au niveau du chargement des données dans la base que les deux solutions se distinguent :

• Le Data Warehouse, on l’a vu, est connecté aux sources de données indirectement. Il n’ingère pas directement les données. Celles-ci transitent d’abord sur un serveur de traitement temporaire, ce que l’on appelle une solution ETL : Extract – Transform – Load. L’ETL est utilisé également pour faire le tri dans les données, si bien que toutes n’ont pas l’honneur de rejoindre le Data Warehouse. On exclut certaines données inutiles pour les cas que l’on s’est fixé, pour simplifier le modèle de données mais aussi pour réduire le volume de stockage (qui a un impact sur la vélocité des requêtes SQL). C’est aussi la raison pour laquelle un Data Warehouse contient moins (et souvent bien moins) de données qu’un Data Lake. L’inconvénient de l’approche Data Warehouse est qu’elle exclut de facto des données qui pourraient être utiles plus tard…
• Le Data Lake fonctionne avec une solution ELT qui charge les données dans le lac directement, dans leur état d’origine. Extract – Load – Transform. On charge avant de transformer – et la transformation désigne le travail passionnant mais complexe des Data Scientists car il faut du boulot pour extraire des enseignements à partir de cet immense magma de données à l’état brut, même si de nombreux outils facilitent aujourd’hui le travail exploratoire ! Charger avant de transformer permet de conserver toutes les données et donc de ne passer à côté d’aucunes données potentiellement intéressantes pour l’analyse exploratoire. C’est ce que l’on appelle l’approche « schema.in. read », que l’on distingue de l’approche « schema.in.write » utilisée avec un Data Warehouse.

Découvrez notre comparatif complet des logiciels ETL : Cloud Vs On-Premise Vs Open Source.

Le Data Lake Vs Le Data Warehouse – Une différence de conception

• Dans une architecture Data Warehouse, on passe beaucoup de temps en amont, à réfléchir aux cas d’usage des données et à la manière de modéliser, structurer, organiser et processer en vue des cas d’usage cibles. On répond à 3 questions : Quels cas d’usage ? Quelles données intégrer dans le DWH ? Quelles règles et modélisations mettre en place ? Designer un Data Warehouse, c’est construire un cadre qu’il est ensuite difficile de faire évoluer. C’est l’inconvénient majeur de l’approche DWH. Modifier les contours d’un Data Warehouse, connecter de nouvelles sources par exemple ou bien ajouter un cas d’usage, est complexe à gérer. Dans un Data Warehouse on reste en quelque sorte prisonnier d’une structure que l’on a mis en place au moment du déploiement.
• Dans une architecture Data Lake, c’est plutôt l’inverse. On charge tout sans distinction et c’est en aval que l‘on (plus précisément les Data Scientists) travaille le plus. On ne pose aucune question en amont, mais on peut s’en poser une infinité en aval. Le spectre des questionnements & réflexions possibles est aussi large que l’imagination et l’intelligence des Data Scientists qui travaillent sur le Data Lake. Dans un Data Lake, le champ des possibles est infini.

Pour aller plus loin, nous vous renvoyons à notre guide complet : Data Lake – Entre océan et marais [Définitions & Enjeux].

DataLake Vs DataWarehouse ? Quelle solution choisir ?

Si votre entreprise souhaite analyser de gros volumes de données structurées, le Data Warehouse est une bonne option. Pour faire de l’analyse descriptive, pour cataloguer les données structurées à disposition de l’entreprise, un Data Warehouse peut largement faire l’affaire. Prenons un exemple, pour rendre les choses plus concrètes et moins théoriques. Vous gérez une entreprise et vous voulez comprendre les schémas commerciaux sur une période donnée, par exemple : le nombre de requêtes pour un produit ou le nombre de vues sur vos vidéos marketing. Un entrepôt de données vous permettra d’obtenir facilement ces informations dans la mesure où il centralise et associe toutes les données structurées contenant l’information que vous recherchez.

Données structurées Vs Données non-structurées

Nous répétons : « données structurées ». Mais vous n’êtes sans doute pas sans savoir que la plupart des entreprises engagées dans des projets Big Data n’ont pas à gérer que des données structurées. Les données structurées ne sont qu’une partie des données de l’entreprise. Une étude a montré que 63% des entreprises et fournisseurs de services stockaient en moyenne 25 petabytes de données non-structurées. Pour ces entreprises-là, disposer d’un Data Lake est une option attirante en raison de la capacité d’un Data Lake à stocker de vastes quantités de données non-structurées.

Le Data Lake rend possible l’analyse prédictive et l’analyse prescriptive

De plus, un Data Lake permet aux analystes d’aller au-delà de l’analyse descriptive et de pénétrer le données passionnants de l’analyse prédictive et prescriptive :

• L’analyse prédictive est la pratique qui consiste à utiliser les données à disposition pour prédire les tendances futures de son activité (son chiffre d’affaires prévisionnel par exemple) et le comportement d’achat de ses clients.
• L’analyse prescriptive va un pas plus loin et utilise des technologies boostées à l’intelligence artificielle permettant de générer des recommandations en fonction des résultats de l’analyse prédictive.

Pour ces deux stades supérieurs d’analyse, le Data Lake est un must.

Alors, que choisir ? Data Warehouse et Data Lake ? La réponse dépend des données qu’il s’agit de stocker (structurées ? non-structurées ?) mais aussi des utilisateurs cibles. A qui est destiné le dispositif ? Quels sont les utilisateurs cibles ?

A qui est destiné le dispositif ? Zoom sur les 3 profils d’utilisateurs de données

Finalité des données

Dans un Data Lake, les cas d’usage des données ne sont pas figés et ne déterminent pas la morphologie de la base. Les données qui entrent dans le Data Lake peuvent être prévues pour une utilisation précise ou stockées tout simplement histoire de les avoir sous la main le jour venu. Quand on construit un Data Warehouse, on définit quels sont les données qui doivent y entrer et comment elles doivent être transformées en fonction des cas d’usage que l’on a formulé. La finalité des données est par conséquent qualifiée en amont.

Utilisateurs

Nous avons vu que Data Warehouse et Data Lake ne s’adressaient pas au même profil d’utilisateurs. Le Data Lake est le terrain de jeu des Data Scientists qui utilisent des outils spécifiques pour mettre de l’ordre dans le chaos de données que constitue le lac. Il est difficile à explorer pour les utilisateurs opérationnels et plus généralement par tous les utilisateurs qui ne sont pas familiers des données non-transformées.

Accès

Parce que non-structuré, le Data Lake est plus facilement accessible. Il est plus simple à consulter et à modifier. Les restrictions sont très limitées. Par construction, les Data Warehouse sont très structurés et en cela plus faciles à comprendre. L’inconvénient est que les règles et restrictions inhérentes à leur structure les rendent plus difficile à manipuler. La liberté d’accès des Data Lakes est un avantage aussi bien qu’un inconvénient : elle rend la gouvernance des données plus lâche. Nous reviendrons sur cette question à la fin de l’article.

Choisir un DataLake ou un DataWarehouse – L’exemple de la BI

Prenons un exemple très concret pour terminer. Supposons que vous souhaitiez faire de la Business Intelligence. Quelle est la meilleure option ? La première option, classique, consiste à pencher pour un Data Warehouse. La deuxième, moderne, consiste à porter son dévolu sur un Data Lake. Mais avant, rappelons que la BI :

• Permet de créer une source unique de vérité. La BI sert à produire des reportings à partir de l’ensemble des données de l’entreprise et de partager ces reportings à toute l’organisation.
• Est analyse descriptive. La BI est de nature descriptive dans la mesure où elle raconte ce qui se passe maintenant et ce qui s’est passé dans le passé. Elle fournit des KPIs et métriques qui permettent de piloter l’activité. La BI permet de comparer la réalité avec les objectifs cibles que s’est fixée l’entreprise : par exemple le volume de ventes réalisé avec l’objectif de ventes. Les informations ayant trait à l’analyse prédictive sont généralement présentées sous la forme de tableaux de bord synthétiques.
• Est analyse diagnostique. Cette analyse vise à obtenir des enseignements plus profonds et à répondre à la question : « Pourquoi est-ce qu’il s’est produit ceci ? ». La BI aide à comprendre les causes. Les outils de BI proposent des fonctionnalités qui permettent d’accéder au détail des tableaux de bord et de mener des analyses approfondies.

En revanche, le rôle de la BI n’est pas de prédire le futur. La BI ne s’intéresse qu’au passé et au présent. L’analyse prédictive n’est pas de son ressort.

Une fois ces quelques précisions apportées sur la BI, voyons les deux solutions possibles pour mettre en place votre dispositif.

Approche classique d’un dispositif BI avec Data Warehouse – Architecture et caractéristiques

La Business Intelligence est traditionnellement associée au Data Warehouse. Quand on évoque l’un, l’autre n’est jamais très loin. Ce sont en quelque sorte les faces d’une même médaille : la BI est la partie face, le front-end ; la base DWH la partie pile, le back-end. Le DWH est construit pour faire de l’analyse décisionnelle, de la BI. Il est donc tout naturel de penser d’abord au Data Warehouse lorsque l’on souhaite mettre en place un dispositif de BI. C’est l’approche classique, apparue dans les années 1980, qui reste pertinente dans beaucoup de cas.

Le Data Warehouse centralise les données en provenance de toutes les bases opérationnelles. La BI exploite le Data Warehouse pour transformer ces données centralisées en informations. Le Data Warehouse, nous l’avons vu, est une base relationnelle SQL qui permet de définir des relations entre différentes tables de données. Comme nous l’avons vu plus haut, les sources de données sont connectées au Data Warehouse via des process ETL. Le Data Warehouse applique l’approche schema-on-write : il est designé pour répondre à des questions précises.

Il y a 3 couches dans une architecture Data Warehouse – BI :

• La première est ce que les anglais appellent la staging area. C’est la base transitoire, construite à partir d’un outil ETL, utilisée pour charger en batch les données dans le DWH.  La staging area est constituée de tables qui reflètent les structures des systèmes sources. Elle rassemble toutes les tables et toutes les colonnes de toutes les sources, y compris la clé primaire. A ce stade, aucune règle business n’est appliquée. En revanche des règles techniques sont mises en place, par exemple le matching des data types : par exemple la longueur des chaînes de caractères. Cette base transitoire organise la donnée sans en changer le sens. Elle fait fonction de sas avant son intégration dans la deuxième couche : le Data Warehouse proprement dit.
• La deuxième couche est le Data Warehouse. C’est à ce niveau que les données sont transformées suivant des règles business spécifiques. Ces règles modifient la nature et le format des données pour qu’elles se plient aux usages business du DWH. Plus ces règles de transformation sont définies en amont dans la conception de l’architecture du DWH, plus il sera difficile de les modifier ultérieurement. La modélisation dimensionnelle et le Data Vault sont les deux approches principales pour modéliser les données du DWH issues des différentes sources.
• La troisième couche est la couche qui permet de mettre de l’intelligence dans les données. C’est à cette hauteur que se positionne la BI. Cette couche est le produit d’une modélisation dimensionnelle et vise à présenter les données aux utilisateurs finaux. C’est là que les données se transforment en informations. On parle de Data mart pour désigner cette couche. La modélisation la plus employée est la modélisation en étoile. Pour en savoir plus, nous vous renvoyons vers l’article que nous avons consacré à la modélisation en étoile.

Découvrez notre article : Design d’un Data Warehouse – Zoom sur la modélisation en étoile.

Approche moderne d’un dispositif BI avec Datalake – Architecture et caractéristiques

Il existe une deuxième approche pour construire un dispositif de BI : c’est, vous l’aurez deviné, celle consistant à utiliser un Data Lake. C’est l’approche moderne. Elle permet de résoudre le problème classique que pose l’approche Data Warehouse. La mise en place d’un Data Warehouse permet de bien structurer les process et les règles business, mais faire évoluer le dispositif a posterio est complexe comme nous l’avons vu. Intégrer de nouveaux types de données implique de modifier le design du DWH, de restructurer la base et reconfigurer l’ETL. Lorsque l’on gère de gros volumes de données, ce process est chronophage et coûteux. C4est pour cette raison que beaucoup d’entreprises penchent plutôt vers l’approche moderne Data Lake.

Le Data Lake utilise une approche schema.in.read qui facilite grandement l’évolutivité du dispositif. Pas besoin de définir une structure et un schéma de données au moment de sa mise en place. Les données arrivent telles qu’elles, sans passer par un sas de filtrage et sans se voir appliquées des règles. Lorsque l’on a besoin de lire la donnée, on applique la règle directement au code qui lit la donnée plutôt que d’avoir à configurer la structure de données en amont. On passe du process Extract – Transform – Load au process Extract – Load – Transform. C’est ce qui fait la force du Data Lake. Une architecture Data Lake permet d’obtenir des insights business non seulement à partir des données processées et gouvernées, mais aussi à partir des données brutes qui n’étaient pas accessibles dans l’approche Data Warehouse.

L’enjeu de la gouvernance des données

Le principal challenge lorsque l’on décide d’opter pour cette approche Data Lake, c’est de mettre en place une gouvernance des données solide sans quoi le lac risque rapidement de se transformer en marécage. Il y a un enjeu majeur de Data Quality. Il faut que les utilisateurs business aient confiance dans la qualité des données stockées dans le Data Lake. On observe d’ailleurs une tendance depuis quelques années qui consiste à organiser le Data Lake, à lui appliquer des règles de gouvernance et à séparer le Data Lake en deux environnements : un environnement pour l’exploration et le développement, distinct de l’environnement de production. Le premier environnement est utilisé pour explorer la donnée, la nettoyer, la transformer afin de construire un modèle de machine learning, des fonctions et d’autres outils analytiques. Les données telles que les métriques ou les fonctions sont générées au cours du process de transformation et stockées dans l’environnement de production.

Une autre approche pour améliorer la gouvernance du Data Lake consiste à ne faire entrer dans le lac de données que les données vérifiées. Le Data Lake n’est plus un fourre-tout. Aucune donnée n’est stockée qui n’ait été décrite et documentée dans un registre définissant les rôles et les responsabilités des différents utilisateurs. La mise en place de cette approche Data Lake évoluée nécessite un investissement temporel, mais c’est selon nous incontournable.

Nous arrivons au terme de ce long article. Nous espérons vous avoir éclairé sur la différence entre Data Warehouse et Data Lake !

CRM / Data - Plus de 15 ressources & templates gratuits à télécharger.

Découvrir