Le Data Warehouse : le standard historique de l'analytique
Le Data Warehouse (entrepot de données) est apparu dans les années 1980 pour répondre a un besoin fondamental : centraliser des données structurées issues de multiples systèmes opérationnels (ERP, CRM, applications métier) et les rendre exploitables pour le reporting et l'analyse decisionnelle. Bill Inmon en a pose les bases théoriques avec sa définition classique du DWH comme 'collection de données orientées sujet, intégrées, non volatiles et historisées'. Ralph Kimball a ensuite popularise une approche plus pragmatique avec la modélisation dimensionnelle.
Un Data Warehouse est optimise pour les requetes analytiques OLAP (Online Analytical Processing), par opposition aux systèmes transactionnels OLTP. Il stocke des données structurées, soigneusement modelisées en tables de faits et de dimensions, avec un schema impose avant toute ecriture. Son atout majeur : des performances de requete exceptionnelles grâce aux index, partitions, encodages columnar et aux statistiques de colonnes.
Modélisation dimensionnelle : Kimball vs Inmon
L'approche Kimball (bottom-up) construit le DWH par datamarts métier — chaque departement dispose de son propre ensemble de tables optimise pour ses requetes. Le star schema place une table de faits (transactions, ventes, événements) au centre, entourée de tables de dimensions (clients, produits, dates, geographies). Les jointures sont simples et rapides. Le snowflake schema normalise davantage les dimensions pour réduire la redondance, au prix de jointures plus complexes.
L'approche Inmon (top-down) préconise d'abord la creation d'un modèle de données d'entreprise normalise (3NF), puis la derivation de datamarts a partir de ce modèle centralise. C'est plus rigoureux mais aussi plus long et couteux. En pratique, la majorite des équipes data choisissent l'approche Kimball pour sa rapidite de mise en oeuvre et ses bonnes performances analytiques.
Les Data Warehouses cloud : Snowflake, BigQuery, Redshift
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 avec des approches differentes. Snowflake a impose l'architecture de separation compute/storage : les clusters de calcul (virtual warehouses) sont indépendants du stockage, ce qui permet de scaler le compute sans impacter les données. BigQuery est entièrement serverless : pas de cluster a gerer, facturation a la quantité de données scannées. Redshift Serverless rejoint cette tendance. Ces trois plateformes supportent le SQL ANSI avec des extensions analytiques avancées (fonctions de fenetrage, QUALIFY, PIVOT) et s'integrent nativement avec les outils BI majeurs (Tableau, Looker, Power BI, Metabase).
Le star schema (table de faits centrale, dimensions non normalisées autour) reste le modèle dominant en DWH analytique car il minimise le nombre de jointures pour les requetes BI. Le snowflake schema normalise les dimensions en sous-tables pour réduire la redondance et la taille de stockage, mais complexifie les requetes SQL et peut degrader les performances sur de grands volumes.
Le Data Lake : stocker tout, transformer après
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 Gen2 et Google Cloud Storage. L'idée centrale : stocker toutes les données dans leur format natif (structure, semi-structure, non structure) a un coût très faible, sans schema impose en amont. Un terabyte dans S3 coute environ 23 dollars par mois — contre 400 a 1 000 dollars dans un DWH cloud équivalent.
Le Data Lake applique le principe 'schema on read' : on ne définit le schema des données qu'au moment de les lire et de les analyser, via Spark, Athena ou un autre moteur de requete. C'est l'inverse du Data Warehouse (schema on write). Cette flexibilité permet d'ingerer des logs applicatifs, des fichiers JSON imbriques, des flux Kafka, des images, des modèles de machine learning, sans phase de modélisation prealable — une capacité particulièrement precieuse pour les équipes Data Science.
Formats de fichiers : Parquet, ORC, Avro et JSON
Le choix du format de fichier dans un Data Lake impacte directement les performances de requete et les coûts de compute. Parquet est le format columnar open-source de référence : il stocke les données colonne par colonne (plutot que ligne par ligne), ce qui permet de ne lire que les colonnes nécessaires a une requete et de compresser efficacement des valeurs repetitives. Une requete sur 3 colonnes d'une table de 100 colonnes scanne seulement 3 % des données — des gains de performance et de coût considerables sur BigQuery ou Athena.
ORC (Optimized Row Columnar) est l'équivalent Parquet dans l'écosystème Hive/Presto — même principe columnar, compression très efficace sur les grandes tables. Avro est un format row-based serialise en binaire, idéal pour les flux Kafka et les schemas qui évoluent souvent (gestion des types nullable, schema évolution intégrée). JSON et CSV restent utilises pour l'ingestion brute mais ne sont jamais recommandés pour le stockage final en raison de leurs performances mediocres pour les requetes analytiques.
Le danger du Data Swamp : gouvernance ou neant
Sans gouvernance, un Data Lake devient rapidement un Data Swamp (marecage de données) : des terabytes de fichiers non documentés, sans lineage, sans qualité vérifiée, qui deviennent inutilisables en pratique. Les équipes passent plus de temps a chercher et valider les données qu'a les analyser. Les fichiers s'accumulent, les schemas changent sans notification, les partitions sont mal conçues et les requetes Spark deviennent prohibitivement lentes et couteuses.
Éviter le Data Swamp requiert trois ingredients : un data catalog (Apache Atlas, DataHub, AWS Glue Data Catalog, Dataplex) pour documenter chaque dataset ; une stratégie de partitioning claire (par date, par entité métier) pour accélérer les requetes ; et des tests de qualité automatisés sur chaque pipeline d'ingestion. L'absence de l'un de ces trois éléments suffit a degrader l'utilisabilite du Lake.
Un constat fréquemment relaye dans l'industrie data de la fin des années 2010 est qu'une part très importante des projets Big Data echouaient a creer de la valeur métier mesurable. Une des causes principales : des Data Lakes transformes en Data Swamps faute de gouvernance, de catalogage et de contrôle qualité. Le Data Lake n'est pas une solution 'store and forget' — c'est une infrastructure qui nécessite autant de rigueur qu'un DWH.
Le Lakehouse : performances DWH sur flexibilité Lake
Le Lakehouse est apparu vers 2020 pour resoudre les limites des deux architectures precedentes. Le concept, formalise par Databricks dans un papier de recherche présente au VLDB 2021, combine la flexibilité et le faible coût du Data Lake avec les performances, la fiabilité ACID et les capacités analytiques SQL du Data Warehouse — le tout sur du stockage objet standard (S3, ADLS, GCS).
Techniquement, le Lakehouse repose sur des formats de table ouverts (Delta Lake, Apache Iceberg, Apache Hudi) qui ajoutent une couche de metadata au-dessus des fichiers Parquet sur le stockage objet. Cette couche de metadata porte les transactions ACID, le versioning des données, le schema enforcement optionnel, l'optimisation des requetes via des statistiques de fichiers et les index embarqués (Z-order clustering dans Delta Lake). On ecrit des fichiers Parquet dans un bucket S3, et on les interroge avec des performances proches d'un DWH grâce a ces optimisations.
Delta Lake, Apache Iceberg et Apache Hudi : différences et cas d'usage
Delta Lake (créé par Databricks, open-source depuis 2019) est le format le plus adopte dans les écosystèmes Spark et Databricks. Il offre les transactions ACID via un transaction log JSON, le time travel (requeter l'état passe des données avec VERSION AS OF ou TIMESTAMP AS OF), le schema enforcement et l'évolution, et l'optimisation automatique des petits fichiers via la compaction (OPTIMIZE). Le Z-order clustering permet de co-localiser les données fréquemment filtrées ensemble pour réduire les IO.
Apache Iceberg, initie par Netflix et maintenant standard Apache, est prefere dans les écosystèmes AWS (Athena, EMR, Glue) et beneficie d'un support croissant de Snowflake et BigQuery via leurs integrations Iceberg natives. Son avantage clé est la gestion des partitions hidden (invisibles pour les requetes) et une meilleure interoperabilite entre moteurs. Apache Hudi (créé par Uber) excelle pour les scénarios upsert fréquents dans les pipelines CDC (Change Data Capture) : il supporte des modes d'ecriture Copy-on-Write et Merge-on-Read pour equilibrer les performances de lecture et d'ecriture selon le cas d'usage.
Outils Lakehouse : Databricks, Amazon, Azure et Google
Databricks Data Intelligence Platform est la référence du marche Lakehouse. Elle combine Apache Spark, Delta Lake, une couche ML intégrée (MLflow pour le tracking, Feature Store pour les features ML), et Photon — un moteur d'exécution SQL C++ haute performance. Unity Catalog (2022) ajoute la gouvernance centralisée des métadonnées, le lineage fin et le contrôle d'accès unifie sur toutes les ressources data.
Sur AWS, l'équivalent est Lake Formation avec S3 comme stockage, Glue pour le catalogue et l'ETL, Athena pour les requetes SQL serverless et EMR pour Spark. Azure Synapse Analytics intègre le Lakehouse dans l'écosystème Microsoft avec Azure Data Lake Storage Gen2, Apache Spark managée et SQL Serverless. Google BigLake (et BigQuery Omni) permet d'interroger des données Parquet sur S3, ADLS ou GCS directement depuis BigQuery, unissant le DWH et le Lake dans une experience unifiée.
Le terme 'Lakehouse' a ete formalise dans le papier 'Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics', présente au VLDB 2021 par Armbrust et al. de Databricks. Ce papier documente comment les formats de table ouverts permettent d'atteindre des performances OLAP proches des DWH commerciaux sur du stockage objet.
Armbrust et al. - Lakehouse: A New Generation of Open Platforms, VLDB 2021Data Lake vs Data Warehouse vs Lakehouse : 5 dimensions clés
Ces trois architectures different sur cinq dimensions qui impactent directement les choix d'infrastructure, de tooling et d'organisation des équipes data.
1. Schema : on write vs on read vs hybride
Le Data Warehouse impose un schema strict a l'ecriture (schema on write) : les données doivent être conformes au modèle defini avant tout chargement. Toute modification du schema nécessite une migration structurée. Le Data Lake ne définit le schema qu'a la lecture (schema on read) : les fichiers sont ecrits tels quels, et chaque lecteur interpretes les colonnes selon ses besoins. Le Lakehouse propose une approche hybride : schema enforcement optionnel pour les tables critiques (garantie de qualité a l'ecriture), schema on read pour les zones d'exploration brute. Delta Lake et Iceberg permettent de choisir le niveau de strictness par table.
2. Types de données supportes
Le DWH est limite aux données structurées (tables SQL avec types définis). Le Data Lake accepte tout : structure (CSV, Parquet, tables SQL exportées), semi-structure (JSON, Avro, XML, logs applicatifs), et non structure (images, videos, fichiers audio, texte brut, PDFs). Le Lakehouse ajoute un support natif des workflows ML/AI directement sur les données brutes du Lake — un Data Scientist peut entrainer un modèle directement sur un Delta Lake Table sans ETL supplémentaire vers un DWH.
3. Structure des coûts
Le stockage dans un DWH cloud (Snowflake, BigQuery) coute de 20 a 40 fois plus cher que le stockage objet (S3, ADLS, GCS). Un terabyte dans S3 coute environ 23 dollars par mois ; dans Snowflake, le même volume peut atteindre 400 dollars. Le Data Lake et le Lakehouse utilisent du stockage objet, d'ou des coûts de stockage très bas. En contrepartie, les requetes ad hoc bien optimisées restent souvent plus rapides et moins couteuses en compute dans un DWH (grece a la pre-materialisation des agregats et aux statistiques de colonnes pre-calculées).
4. Garanties ACID et fiabilité
Le Data Warehouse offre des garanties ACID natives (Atomicite, Cohérence, Isolation, Durabilite) depuis ses origines. Le Data Lake classique sur S3 n'offre aucune garantie ACID : deux jobs d'ecriture concurrents peuvent corrompre un fichier Parquet, une lecture pendant une ecriture peut renvoyer des données partielles. Le Lakehouse réintroduit les garanties ACID dans le Data Lake via le transaction log de Delta Lake ou Iceberg, rendant les opérations de mise a jour (UPDATE, DELETE, MERGE) fiables et les lectures cohérentes même en cas d'ecritures concurrentes.
5. Performances analytiques
Le DWH reste le champion des performances pour les requetes SQL bien définies sur des schemas stables et optimisés. Les statistiques de colonnes, les index materiaux et les caches de résultats de Snowflake et BigQuery offrent des temps de réponse sub-seconde sur des milliards de lignes. Le Data Lake pur (Parquet sur S3 + Athena) est plus lent sur les requetes non optimisées : sans partitioning adequat, Athena scanne tout le Lake. Le Lakehouse comble cet écart avec le Z-order clustering, la compaction des petits fichiers et les index de plage de valeurs (min/max statistics) intègres dans le transaction log.
Integrer le streaming : Lambda, Kappa et Lakehouse streaming
Les architectures data modernes doivent gerer deux types de données : les données historiques (batch) et les données en temps réel (streaming). Cette dualite a donne naissance a deux paradigmes architecturaux — Lambda et Kappa — qui s'appliquent différemment selon que l'on utilise un Data Lake, un DWH ou un Lakehouse.
Architecture Lambda vs Kappa
L'architecture Lambda (Nathan Marz, 2011) maintient deux chemins de traitement en parallèle : un batch layer qui recalcule les vues historiques périodiquement (toutes les heures, chaque nuit) et un speed layer qui traite les événements en temps réel avec un léger délai (Kafka + Spark Streaming ou Flink). Les deux couches sont reconciliées dans une serving layer pour les requetes. L'avantage est la fiabilité — le batch layer corrige les erreurs du speed layer. L'inconvenient est la duplication du code de transformation entre les deux chemins.
L'architecture Kappa (Jay Kreps, 2014) simplifie l'approche en n'utilisant qu'un seul chemin de traitement en streaming. Kafka stocke l'historique complet des événements (rétention longue durée), et le même job de traitement streaming recalcule les vues historiques et les vues temps réel. C'est plus simple a maintenir mais plus exigeant en infrastructure Kafka et Flink/Spark Streaming. Le Lakehouse avec Delta Lake + Spark Structured Streaming permet aujourd'hui d'implementer une architecture Kappa robuste a moindre complexité.
Le streaming dans le Lakehouse : Kafka + Spark + Delta Lake
Le Lakehouse est devenu le choix de référence pour les architectures qui combinent batch et streaming. Kafka capture les événements en temps réel (clics, transactions, événements IoT). Spark Structured Streaming les consomme et les ecrit en continu dans des tables Delta Lake avec des garanties exactly-once. Les mêmes tables Delta Lake sont ensuite interrogées par les jobs Spark batch et par les requetes SQL analytiques — une seule source de vérité, un seul code de transformation.
Databricks propose le concept de 'streaming tables' dans Delta Live Tables (DLT), un framework déclaratif qui unifie le traitement batch et streaming dans un même pipeline. Flink est une alternative a Spark Streaming pour les architectures qui nécessitent une très faible latence (millisecondes vs secondes). Amazon Kinesis + S3 + Athena propose une version serverless de cette architecture dans l'écosystème AWS.
Lambda est prefere quand la correction a posteriori des données est critique (finance, sante) et quand les latences batch sont acceptables pour les cas d'usage historiques. Kappa est prefere quand le même code de transformation doit s'appliquer a l'historique et au temps réel, et quand l'équipe veut éviter la duplication de logique métier. En 2026, le Lakehouse avec Spark Structured Streaming tend vers une approche Kappa simplifiée.
Comment choisir votre architecture de stockage data
Le choix ne se fait pas en théorie mais en fonction de vos besoins concrets : volume et types de données, usages analytiques (BI seule, ML, streaming), competences de l'équipe, contraintes réglementaires et budget. Voici les critères qui orientent ce choix en pratique.
Choisir le Data Warehouse pur
Recommande si vos besoins sont 100 % BI et reporting sur des données structurées, si votre équipe est SQL-first sans competences Spark ou Python data engineering, si vous avez des SLAs stricts sur les temps de requete BI (sub-seconde pour les tableaux de bord), et si votre volume de données reste inférieur a quelques centaines de terabytes. Snowflake et BigQuery sont d'excellents choix pour ce profil. Le DWH pur convient également aux organisations avec des obligations de conformité strictes sur la localisation et la gouvernance des données, car Snowflake et BigQuery offrent des contrôles d'accès et d'audit très granulaires.
Choisir le Data Lake pur
Recommande si vous stockez des volumes massifs de données non structurées (logs applicatifs, images, audio, flux IoT) que vous n'avez pas encore besoin d'analyser en SQL, si vos usages principaux sont l'entraînement de modèles de Machine Learning sur des données brutes, si vous avez une équipe Data Engineering capable de mettre en place et maintenir la gouvernance (catalogage, qualité, lineage), et si le budget est une contrainte forte car le stockage objet est de loin la solution la moins couteuse.
Choisir le Lakehouse
Le Lakehouse est le choix par defaut pour les nouvelles architectures en 2026. Il est recommande dans tous les cas ou vous combinez BI et ML sur la même plateforme, ou vous voulez profiter du faible coût du stockage objet avec des performances SQL proches d'un DWH, ou vous avez besoin de garanties ACID sur vos pipelines (upserts CDC, corrections de données en production), ou votre équipe maîtrise Spark et SQL. Databricks, Snowflake avec Iceberg Tables ou BigLake sont les choix leaders.
Si votre DWH Snowflake ou BigQuery fonctionne bien pour vos usages actuels, une migration vers Databricks Lakehouse peut introduire une complexité opérationnelle non justifiée. Le Lakehouse est optimal quand vous avez un besoin réel de combiner BI et ML, ou quand les coûts de stockage DWH deviennent prohibitifs. Migrer par conviction technologique plutot que par besoin métier est une erreur courante qui créé de la dette opérationnelle.
Ancrer ces concepts avec la répétition espacée
La distinction entre Data Lake, Data Warehouse et Lakehouse est l'un des sujets les plus fréquents dans les entretiens Data Engineering et Data Architecture. Les concepts sont clairs en surface mais s'entremelent rapidement en pratique — notamment sur les formats de fichiers, les garanties ACID et le role des formats ouverts. Les flashcards Memia sur l'architecture data vous permettent d'ancrer ces distinctions dans la mémoire a long terme et de les restituer avec précision en situation d'entretien ou de comite d'architecture.
Les decks 'Data Lake, Data Warehouse et Lakehouse' et 'Architecture data' de Memia couvrent les définitions, les formats (Parquet, Delta Lake, Iceberg), les modèles (Kimball, Inmon), les outils (Snowflake, Databricks, BigQuery) et les patterns (Lambda, Kappa, medallion). Chaque carte est formulée pour tester la compréhension et non la simple memorisation.
Les comparaisons les plus utiles a maîtriser : schema on write vs schema on read, ACID dans un Data Lake (impossible sans Delta Lake ou Iceberg), time travel dans Delta Lake (VERSION AS OF), différence entre partitioning et Z-order clustering, Lambda vs Kappa architecture, et les cas d'usage spécifiques de Hudi vs Iceberg vs Delta Lake.
Approfondir le cluster Data & IA
Questions fréquentes sur Data Lake, Data Warehouse et Lakehouse
Quelle est la différence entre un Data Lake et un Data Warehouse ?
Le Data Warehouse stocke uniquement des données structurées avec un schema defini a l'avance (schema on write), optimise pour les requetes SQL analytiques OLAP. Le Data Lake stocke tout type de données (structure, semi-structure, non structure) dans leur format natif sans schema prealable (schema on read), a très faible coût sur du stockage objet (S3, ADLS). Le DWH est optimal pour le BI, le Data Lake pour le ML sur données brutes et le stockage massif.
Qu'est-ce qu'un Lakehouse ?
Un Lakehouse combine les avantages du Data Lake (stockage objet bon marche, flexibilité, tous types de données) 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 qui ajoutent une couche de metadata ACID au-dessus des fichiers Parquet sur le stockage objet.
Qu'est-ce qu'un Data Swamp ?
Un Data Swamp est un Data Lake devenu inutilisable faute de gouvernance : données non documentées, sans lineage, sans qualité vérifiée, sans catalogage. Les équipes ne savent plus ce qu'il contient ni comment l'utiliser. C'est le risque principal d'un Data Lake lance sans stratégie de metadata management, de partitioning et de contrôle qualité des pipelines d'ingestion.
Delta Lake ou Apache Iceberg : lequel choisir ?
Delta Lake est prefere dans les écosystèmes Databricks et Spark — il beneficie d'une intégration profonde avec Databricks et d'un outillage mature (OPTIMIZE, Z-order, VACUUM). Apache Iceberg est davantage adopte dans les écosystèmes AWS (Athena, EMR, Glue) et beneficie d'un support croissant de Snowflake et BigQuery via leurs integrations natives. Les deux offrent ACID, time travel et schema évolution — le choix depend principalement de votre cloud et de vos outils existants.
Qu'est-ce que le format Parquet et pourquoi est-il dominant ?
Parquet est un format de fichier columnar open-source créé par Cloudera et Twitter. Il stocke les données colonne par colonne, ce qui permet de ne lire que les colonnes nécessaires a une requete (plutot que toute la ligne) et de compresser efficacement des valeurs repetitives. Pour une requete sur 3 colonnes d'une table de 100 colonnes, Parquet scanne seulement 3 % des données vs 100 % pour un CSV. C'est le format de facto pour les Data Lakes et Lakehouses — Delta Lake et Iceberg stockent tous deux les données en Parquet.
Snowflake est-il un Data Warehouse ou un Lakehouse ?
Snowflake a commence comme un cloud Data Warehouse pur. Il évolue vers le Lakehouse avec Iceberg Tables (stocker les données en Parquet sur S3 et les requeter depuis Snowflake), mais reste principalement positionne comme DWH analytique haute performance. Pour les usages purement BI, Snowflake surpasse le Lakehouse. Pour les usages ML, Databricks reste la référence.
Le Lakehouse remplace-t-il complètement le Data Warehouse ?
Pas encore. Pour des usages 100 % BI/SQL avec des schemas stables et bien optimisés, le DWH pur (Snowflake, BigQuery) offre de meilleures performances et une experience SQL plus mature. Le Lakehouse est optimal quand on combine BI et ML sur la même plateforme et quand les coûts de stockage DWH deviennent prohibitifs. 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 capacité de requeter l'état 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 opération d'ecriture. Utile pour auditer les changements, rejouer des transformations sur un état passe, ou corriger des erreurs de pipeline.
Qu'est-ce que l'architecture Lambda ?
L'architecture Lambda (Nathan Marz, 2011) maintient deux chemins de traitement en parallèle : un batch layer qui recalcule les vues historiques périodiquement, et un speed layer qui traite les événements en temps réel avec un léger délai. Les deux sont reconcilies dans une serving layer. Lambda offre une forte fiabilité mais duplique le code de transformation entre les deux chemins — ce que l'architecture Kappa et le Lakehouse streaming cherchent a éliminer.
Qu'est-ce que le partitioning dans un Data Lake ?
Le partitioning consiste a organiser les fichiers du Data Lake en sous-dossiers selon les valeurs d'une ou plusieurs colonnes (ex: année/mois/jour pour les événements temporels, pays pour les données geographiques). Quand une requete filtre sur la colonne de partitionnement, seuls les fichiers des partitions correspondantes sont lus — ce qui réduit dramatiquement le volume scanne et donc les coûts sur Athena ou BigQuery. Un mauvais partitionnement (trop granulaire, mauvaises colonnes) est l'une des causes les plus fréquentes de performances mediocres sur un Data Lake.
Article précédent : ETL vs ELT
Article suivant : Data Governance - définition et mise en oeuvre