Le Data Warehouse : le standard historique
Le Data Warehouse (entrepot de donnees) est apparu dans les annees 1980 pour repondre a un besoin simple : centraliser des donnees structurees issues de multiples systemes operationnels et les rendre exploitables pour le reporting et l'analyse. Bill Inmon en a pose les bases theoriques, Ralph Kimball a popularise la modelisation dimensionnelle (star schema, snowflake schema).
Un Data Warehouse est optimise pour les requetes analytiques OLAP (Online Analytical Processing). Il stocke des donnees structurees, soigneusement modelisees en tables de faits et de dimensions. Son atout majeur : des performances de requete excellentes grace aux index, partitions et optimisations columnar.
Les Data Warehouses modernes dans le cloud
Les architectures modernes ont fait migrer les DWH on-premise (Oracle, Teradata, IBM DB2) vers le cloud. Snowflake, Google BigQuery et Amazon Redshift dominent ce marche. Ils separent le stockage du compute (scaling elastique), proposent du SQL standard, et s'integrent nativement avec les outils BI (Tableau, Looker, Power BI). Snowflake a ete valorise 120 milliards de dollars a son IPO en 2020, signe de l'engouement du marche.
Le star schema (tables de faits au centre, dimensions autour) reste le modele le plus courant en DWH analytique. Il optimise les jointures pour les requetes BI. Le snowflake schema normalise davantage les dimensions mais complexifie les requetes.
Le Data Lake : stocker tout, transformer apres
Le Data Lake a emerge vers 2010 avec la popularisation d'Hadoop et de HDFS, puis s'est impose dans le cloud avec Amazon S3, Azure Data Lake Storage et Google Cloud Storage. L'idee centrale : stocker toutes les donnees dans leur format natif (structure, semi-structure, non structure) a un cout tres faible, sans schema impose en amont.
Le Data Lake applique le principe 'schema on read' : on ne definit le schema des donnees qu'au moment de les lire et de les analyser. C'est l'inverse du Data Warehouse (schema on write). Cette flexibilite permet d'ingerer des logs applicatifs, des fichiers JSON, des images, des flux Kafka, sans phase de modelisation prealable.
Le danger du Data Swamp
Sans gouvernance, un Data Lake devient rapidement un Data Swamp (marecage de donnees) : des terabytes de fichiers non documentes, sans lineage, sans qualite verifiee, qui deviennent inutilisables en pratique. C'est le risque majeur des initiatives Data Lake mal gouvernees. Les equipes passent plus de temps a chercher et valider les donnees qu'a les analyser.
Selon une etude Gartner de 2019, 85% des projets Big Data echouaient a creer de la valeur. Une des causes principales : des Data Lakes transforms en Data Swamps faute de gouvernance, de catalogage et de controle qualite.
Gartner, 2019Le Lakehouse : les performances du DWH sur la flexibilite du Lake
Le Lakehouse est apparu vers 2020 pour resoudre les limites des deux architectures precedentes. Le concept, formalise par Databricks, combine la flexibilite et le faible cout du Data Lake avec les performances, la fiabilite et les capacites analytiques du Data Warehouse.
Techniquement, le Lakehouse repose sur des formats de table ouverts (Delta Lake, Apache Iceberg, Apache Hudi) qui ajoutent des couches ACID, le versioning, le schema enforcement et l'optimisation des requetes directement sur le stockage objet (S3, ADLS, GCS). On ecrit des fichiers Parquet ou ORC dans un bucket S3, et on les interroge avec des performances proches d'un DWH grece aux statistiques de fichiers et aux index embarques.
Delta Lake, Apache Iceberg et Apache Hudi
Delta Lake (cree par Databricks, open-source depuis 2019) est le format le plus adopte dans les architectures Spark. Il offre les transactions ACID, le time travel (requeter l'etat passe des donnees), le schema enforcement et l'optimisation automatique des petits fichiers (compaction). Apache Iceberg, initie par Netflix, est prefere dans les ecosystemes AWS (Athena, EMR) et gagne du terrain. Apache Hudi, cree par Uber, excelle pour les scenarios upsert frequents (CDC - Change Data Capture).
Outils Lakehouse : Databricks, Amazon Lake Formation, Azure Synapse
Databricks Data Intelligence Platform est la reference du marche. Elle combine Spark, Delta Lake, une couche ML (MLflow) et un moteur SQL haute performance (Photon). Sur AWS, Lake Formation avec S3 + Glue + Athena offre une alternative serverless. Azure Synapse Analytics integre le Lakehouse dans l'ecosysteme Microsoft. Google BigLake permet d'interroger des donnees S3 ou ADLS depuis BigQuery.
Le terme 'Lakehouse' a ete formalise dans le papier 'Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics' publie par Databricks en 2021 (VLDB 2021).
Armbrust et al., VLDB 2021Data Lake vs Data Warehouse vs Lakehouse : tableau comparatif
Voici les cinq dimensions sur lesquelles ces trois architectures different fondamentalement.
Schema : on write vs on read
Le Data Warehouse impose un schema strict a l'ecriture (schema on write) : les donnees doivent etre conformes au modele avant chargement. Le Data Lake ne definit le schema qu'a la lecture (schema on read). Le Lakehouse permet les deux : schema enforcement optionnel pour les tables critiques, schema on read pour les zones d'exploration.
Types de donnees supportes
Le DWH est limite aux donnees structurees (tables SQL). Le Data Lake accepte tout : structure, semi-structure (JSON, Parquet, Avro), non structure (images, videos, logs). Le Lakehouse ajoute un support natif des workflows ML/AI sur les donnees brutes, ce qui permet d'alimenter directement des modeles depuis le Lake.
Structure des couts
Le stockage dans un DWH cloud (Snowflake, BigQuery) coute environ 20 a 40 fois plus cher que le stockage objet (S3, ADLS). Le Data Lake et le Lakehouse utilisent du stockage objet, d'ou des couts de stockage tres bas. En contrepartie, les requetes ad hoc sur un DWH restent plus rapides et moins couteuses en compute pour des schemas bien optimises.
Comment choisir votre architecture de stockage
Le choix ne se fait pas en theorie mais en fonction de vos besoins concrets : volume, types de donnees, types d'usages (BI, ML, streaming), competences equipe et budget.
Choisir le Data Warehouse pur
Recommande si : vos besoins sont 100% BI/reporting sur donnees structurees, votre equipe est SQL-first sans competences Spark, vous avez des SLAs stricts sur les temps de requete. Snowflake et BigQuery sont excellents pour ce profil.
Choisir le Data Lake pur
Recommande si : vous stockez des volumes massifs de donnees non structurees (logs, images, audio), vos usages principaux sont le Machine Learning sur des donnees brutes, et vous avez une equipe capable de gerer la gouvernance.
Choisir le Lakehouse
Le Lakehouse est le choix par defaut pour les nouvelles architectures en 2026. Il est recommande si vous voulez combiner BI et ML sur la meme plateforme, profiter du faible cout du stockage objet avec des performances DWH, et conserver les donnees brutes avec une gouvernance robuste via les formats ouverts.
Ancrer ces concepts avec la repetition espacee
La distinction entre Data Lake, Data Warehouse et Lakehouse est un sujet frequent dans les entretiens Data Engineering et Architecture data. Les concepts sont clairs en surface mais s'entremêlent rapidement en pratique. Les flashcards Memia sur l'architecture data vous permettent d'ancrer ces distinctions dans la memoire a long terme.
Les comparaisons les plus utiles a maitriser : schema on write vs on read, ACID dans un Data Lake (impossible sans format comme Delta Lake), Time Travel dans Delta Lake, difference entre partitioning et clustering dans BigQuery.
Questions frequentes sur Data Lake, Data Warehouse et Lakehouse
Quelle est la difference entre un Data Lake et un Data Warehouse ?
Le Data Warehouse stocke uniquement des donnees structurees avec un schema defini a l'avance (schema on write), optimise pour les requetes SQL analytiques. Le Data Lake stocke tout type de donnees (structure, semi-structure, non structure) dans leur format natif sans schema prealable (schema on read), a tres faible cout.
Qu'est-ce qu'un Lakehouse ?
Un Lakehouse combine les avantages du Data Lake (stockage objet bon marche, flexibilite, tous types de donnees) et du Data Warehouse (transactions ACID, performances SQL, schema enforcement). Il repose sur des formats de table ouverts comme Delta Lake, Apache Iceberg ou Apache Hudi.
Qu'est-ce qu'un Data Swamp ?
Un Data Swamp est un Data Lake devenu inutilisable faute de gouvernance : donnees non documentees, sans lineage, sans qualite verifiee, sans catalogage. Les equipes ne savent plus ce qu'il contient ni comment l'utiliser. C'est le risque principal d'un Data Lake sans strategie de metadata management.
Delta Lake ou Apache Iceberg : lequel choisir ?
Delta Lake est prefere dans les ecosystemes Databricks et Spark. Apache Iceberg est davantage adopte dans les ecosystemes AWS (Athena, EMR, Glue) et beneifcie d'un support croissant de Snowflake et BigQuery. Les deux offrent ACID, time travel et schema evolution - le choix depend principalement de votre cloud et de vos outils existants.
Snowflake est-il un Data Warehouse ou un Lakehouse ?
Snowflake a commence comme un cloud Data Warehouse pur. Il evolue vers le Lakehouse avec des fonctionnalites comme Iceberg Tables (stockage S3 + requetes Snowflake), mais reste principalement positionne comme DWH analytique haute performance.
Le Lakehouse remplace-t-il completement le Data Warehouse ?
Pas encore. Pour des usages 100% BI/SQL avec des donnees tres structurees, le DWH pur (Snowflake, BigQuery) offre de meilleures performances. Le Lakehouse est optimal quand on combine BI et ML sur la meme plateforme. En pratique, beaucoup d'organisations maintiennent les deux en complementarite.
Qu'est-ce que le time travel dans Delta Lake ?
Le time travel est la capacite de requeter l'etat passe d'une table Delta Lake. Par exemple : SELECT * FROM ma_table VERSION AS OF 10 ou SELECT * FROM ma_table TIMESTAMP AS OF '2026-01-01'. C'est rendu possible par le transaction log que Delta Lake maintient pour chaque operation d'ecriture.
Article precedent : ETL vs ELT
Article suivant : Data Governance - definition et mise en oeuvre