ARCHITECTURE
Data Lake vs Data Warehouse vs Lakehouse : quelles différences ?
2/7/2024
Il faudra attendre les années 1980 pour voir naître le premier Data Warehouse, développé par Paul Murphy et Barry Devlin.
Avec l'essor des données non structurées et le besoin croissant d'accès aux données en temps réel, le concept de Data Lake émerge dans les années 2010 en complément du data warehouse.
Et ce n’est qu’en 2020 que le concept de Lakehouse est introduit, combinant les fonctionnalités du Data Warehouse et du Data Lake en un modèle unifié.
Solutions aujourd’hui populaires, qu’est-ce qui différencie un Data Warehouse, d’un Data Lake ou d’un Lakehouse ?
Un Data Warehouse est un système centralisé de gestion et de stockage de données conçu pour collecter, consolider et analyser de grandes quantités de données structurées provenant de diverses sources.
Il permet de regrouper des données historiques et actuelles pour faciliter le reporting et l'analyse de l'information à des fins de prise de décision stratégique.
Les données sont organisées et structurées de manière à optimiser les requêtes et l'analyse, souvent en utilisant des techniques de modélisation spécifiques comme les schémas en étoile ou en flocon de neige.
Un Data Lake est un système de stockage de données qui permet de conserver de grandes quantités de données dans leur format brut et original, qu'elles soient structurées, semi-structurées ou non structurées.
Contrairement à un Data Warehouse, qui organise et structure les données avant de les stocker, un Data Lake accepte les données telles qu'elles sont, ce qui permet une plus grande flexibilité et agilité dans leur utilisation ultérieure.
Un des aspects distinctifs des data lakes est leur architecture plate et non hiérarchique. Cela veut dire que les données sont stockées dans une structure simple et uniforme, sans hiérarchie complexe de dossiers ou de répertoires imbriqués.
Un Data Lakehouse permet de stocker, gérer et analyser à la fois des données structurées, semi-structurées et non structurées, le tout au sein d’un même système.
Fruit du mélange d’un Data Warehouse et d’un Data Lake, le Data Lakehouse combine les avantages de ces deux architectures pour offrir un système de gestion de données unifié et performant. Il offre la flexibilité de stockage d'un Data Lake avec la gestion et l'optimisation des requêtes d'un Data Warehouse.
Cette architecture permet ainsi de réaliser des analyses avancées, y compris des tâches de data science, tout en assurant des performances élevées pour les requêtes et le reporting.
Maintenant que vous comprenez mieux les tenants et aboutissants de chaque solution de stockage de données, voici quelques différences qui vous permettront d'éclaircir votre choix.
Le Data Warehouse utilise une architecture hiérarchique et structurée pour stocker des données strictement structurées. Les données sont organisées selon des schémas définis à l'avance, comme des schémas en étoile ou en flocon de neige, optimisant ainsi les requêtes et le reporting.
Le Data Lake quant à lui adopte une architecture plate et non hiérarchique permettant de stocker des données brutes dans leur format natif, qu'elles soient structurées, semi-structurées ou non structurées. Les données sont organisées à l'aide de métadonnées, offrant une grande flexibilité et évolutivité.
Le Lakehouse combine les architectures des Data Warehouses et des Data Lakes. Il intègre la gestion structurée et les capacités d'optimisation des requêtes d'un Data Warehouse avec la flexibilité de stockage de données brutes d'un Data Lake. Cela permet de gérer et d'analyser des données structurées et non structurées au sein d'un même système.
Le Data Lake sert au stockage de données brutes. Ces données, souvent non structurées, occupent naturellement beaucoup de place et nécessitent un espace de stockage important. Il existe cependant un risque de créer un "marécage de données" (Data Swamp) si l'entreprise ne met pas en place des pratiques de gestion et de traitement de ces données.
Le Data Warehouse n’utilise que des données structurées. Cette architecture ne conserve pas de données inutiles ou non exploitables, réduisant ainsi l'espace de stockage nécessaire et permettant de mieux maîtriser les coûts.
Le Data Lakehouse combine les caractéristiques des Data Lake et des Data Warehouse. Il permet de stocker des données brutes ainsi que des données structurées dans un même environnement. Cette approche offre la flexibilité de traitement des Data Lake tout en assurant la qualité et la performance des Data Warehouse.
L'exploitation des Data Lake, compte tenu de leur complexité, est généralement réservée aux Data Scientists, capables de traiter les informations et de les utiliser selon les besoins précis de l'entreprise.
Les Data Warehouse sont accessibles à tous les spécialistes travaillant en interne dans l'organisation. Les données y sont souvent synthétisées sous forme de graphiques, de tableaux, ce qui permet à n'importe qui, ayant une bonne maîtrise du secteur ou du métier concerné, de les lire et de les comprendre.
Les Data Lakehouses sont utilisés par une combinaison de Data Engineers, Data Scientists et analystes BI. Cette approche hybride permet aux différents spécialistes de collaborer plus efficacement en utilisant un environnement commun pour les différentes étapes de traitement et d'analyse des données.
Un Data Lake est facile à manipuler en raison de l'absence de structure des données, permettant diverses modifications selon les besoins. Les restrictions sont minimales pour les Data Scientists.
Un Data Warehouse impose plus de restrictions, les données étant préalablement catégorisées et structurées. Les modifications de structure sont souvent complexes et coûteuses. Cependant, cette rigidité permet un traitement et une compréhension plus simples des données.
Un Data Lakehouse offre une flexibilité accrue en permettant des modifications dynamiques tout en maintenant une certaine structure. Cela permet aux utilisateurs de bénéficier de la flexibilité des Data Lakes tout en profitant de la rigueur des Data Warehouses.
Les informations dans un Data Lake ne sont pas toujours destinées à un usage spécifique immédiat. Elles peuvent être collectées pour répondre à un besoin futur ou simplement pour être disponibles en cas de besoin.
Dans un Data Warehouse, les données sont prétraitées pour servir un objectif spécifique. Toutes les informations retenues après ce processus sont destinées à être utilisées immédiatement pour des analyses ou des rapports spécifiques.
Les Data Lakehouses permettent de traiter les données pour des besoins immédiats tout en conservant la possibilité d'exploiter des données brutes pour des analyses futures. Cette approche hybride offre une plus grande flexibilité et une meilleure exploitation des Big Data.
Voici un tableau récapitulatif qui vous permettra de mieux discerner les différences entre ces espaces de stockage :
| Aspect | Data Warehouse | Data Lake | Data Lakehouse |
|---|---|---|---|
| Type de données | Structurées (OLAP) | Structurées, semi-structurées, non structurées (OLAP, OLTP) | Structurées, semi-structurées, non structurées (OLAP, OLTP) |
| Modèle de schéma | Schéma en écriture (schema-on-write) | Schéma en lecture (schema-on-read), stockage sous forme de fichiers plats | Schéma flexible, supporte les modèles en écriture et en lecture avec support ACID (Atomicité, Cohérence, Isolation, Durabilité) |
| Format de stockage | Formats optimisés pour l'analytique (Parquet, ORC) | Formats variés (JSON, XML, CSV, Avro, Parquet, ORC) | Formats optimisés pour l'analytique et le ML (Parquet, ORC, Delta Lake, Hudi, Iceberg) |
| Stockage | Stockage SAN/NAS haute performance, disques SSD | Stockage distribué et scalable | Stockage scalable et performant, supporte le stockage cloud hybride |
| Mécanismes d’indexation | Indexation avancée (B-trees, bitmap indexes) | Indexation limitée, basé sur les métadonnées | Indexation avancée avec support des index secondaires et des structures de données adaptatives |
| Performance des requêtes | Haute performance avec optimisation des requêtes SQL, indexes, partitions | Variable, dépend de l'outil utilisé | Haute performance avec optimisations intégrées |
| Stockage | Stockage SAN/NAS haute performance, disques SSD | Stockage distribué et scalable | Stockage scalable et performant, supporte le stockage cloud hybride |
| Gestion des métadonnées | Catalogues de données robustes | Catalogues de données rudimentaires ou externes | Catalogues de données intégrés et avancés |
| Sécurité et gouvernance | Sécurité au niveau des colonnes et des lignes, audits, contrôle d'accès basé sur les rôles | Sécurité et gouvernance variées, nécessitant des configurations supplémentaires | Sécurité et gouvernance unifiées, avec contrôle d'accès fin |
| Pipeline de données | ETL (Extract, Transform, Load) | ELT (Extract, Load, Transform) | ELT/ETL hybrides avec support des workflows de streaming et batch |
| Conformité et audits | Fort soutien pour la conformité réglementaire (GDPR, HIPAA) avec des fonctionnalités de traçabilité et d'audit | Varie, dépend des outils et configurations supplémentaires pour la conformité | Conformité et audits intégrés avec logs d'audit détaillés et traçabilité des données (GDPR, HIPAA, CCPA) |
| Cohérence et intégrité | Transactions ACID, contrôle de version, gestion des anomalies | Cohérence éventuelle, dépend des systèmes de fichiers distribués | Transactions ACID, gestion des versions de données, prise en charge des transactions multi-table (Delta Lake, Iceberg) |
| Utilisateurs cibles | Analystes de données, spécialistes BI, décideurs | Data scientists, ingénieurs de données, analystes exploratoiress | Utilisateurs mixtes : analystes de données, data scientists, ingénieurs de données, décideurs |
| Utilisation typique | Rapports, BI, analyses historiques | Analyses exploratoires, Machine Learning, Big Data | BI, Machine Learning, analyses en temps réel, stockage unifié |
| Coût | Élevé en raison du stockage et des performances optimisées | Bas, stockage de grande capacité à faible coût | Modéré, avec un coût optimisé pour la performance et la capacité |
Ces trois architectures servent à stocker et exploiter les données mais répondent à des logiques différentes. Le critère discriminant est le moment où la structuration s'applique : avant le stockage (Warehouse), jamais (Lake), ou de manière hybride (Lakehouse).
Ces trois architectures ne sont pas des concurrentes nées en même temps mais des réponses successives aux limites de leurs prédécesseurs. Cette chronologie aide à comprendre pourquoi le Lakehouse existe aujourd'hui.
Le type de données acceptées est l'un des critères les plus discriminants entre ces trois architectures. Il conditionne directement les cas d'usage envisageables et le profil des utilisateurs cibles.
L'architecture interne conditionne la façon dont les données sont organisées, accédées et requêtées. Ces différences techniques expliquent pourquoi chaque solution répond à des besoins distincts.
Les profils utilisateurs varient fortement selon l'architecture choisie, car chacune requiert un niveau de compétence technique différent. Cette distinction est essentielle pour calibrer les besoins en recrutement et en formation.
Le choix d'architecture découle des cas d'usage prioritaires de l'organisation. Une entreprise centrée sur le reporting n'a pas les mêmes besoins qu'une organisation qui veut industrialiser ses modèles d'IA.
Les schémas en étoile et en flocon de neige sont des techniques de modélisation utilisées dans les Data Warehouses pour organiser les données et optimiser les requêtes. Ce sont les standards historiques du reporting BI.
Le choix dépend du niveau de maturité data, des cas d'usage prioritaires et des compétences disponibles. Dans les organisations matures, les trois architectures coexistent souvent, chacune servant un besoin spécifique dans la chaîne de valeur.
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
%20copie.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
