Data lake vs lakehouse

Data lake vs lakehouse : concepts

Résumé

Un data lake stocke des fichiers bruts sur de l’object storage, sans transactions ni schéma imposé. Un lakehouse garde ces mêmes fichiers mais ajoute un format de table (Iceberg, Delta, Hudi, Paimon) et un catalogue : on obtient des écritures atomiques, un schéma porté par les métadonnées, des mises à jour et un historique. Formule : lakehouse = data lake + format de table + catalogue. Les fichiers restent les mêmes ; c’est la couche de métadonnées qui change le comportement.

Prérequis

Schema-on-Write vs Schema-on-Read et ACID vs BASE. Le vocabulaire est rappelé juste en dessous.

Définitions

Un data lake est un ensemble de fichiers (Parquet, CSV, JSON…) sur de l’object storage. Rien n’empêche deux processus d’écrire en même temps, et le schéma n’est vérifié qu’à la lecture.

Un lakehouse ajoute une couche de table transactionnelle sur ce stockage : ACID par table, schéma dans les métadonnées, UPDATE/DELETE/MERGE, time travel.

Un data warehouse sert de repère. BigQuery et Snowflake séparent déjà stockage et calcul. La différence avec un lakehouse tient surtout au format de stockage : fermé et propre au produit dans le warehouse, ouvert et lisible par plusieurs moteurs dans le lakehouse.

flowchart TB
    M["Moteurs : Spark, Trino, DuckDB, Flink…"] --> C["Catalogue<br/>où est la version courante de chaque table ?"]
    C --> T["Format de table : Iceberg, Delta…<br/>schéma, snapshots, statistiques"]
    T --> F["Fichiers Parquet"]
    F --> S[("Object storage")]

Mini-glossaire pour la suite

• Snapshot : l’état de la table à un instant, défini par une liste de fichiers.
• Manifest : fichier de métadonnées qui liste les fichiers de données et leurs statistiques.
• Copy-on-write : une modification réécrit les fichiers concernés. Merge-on-read : elle écrit un petit delete file, combiné à la lecture.
• Time travel : relire la table telle qu’elle était à un snapshot passé.

La différence de fond

Le lake laisse la qualité à la charge du lecteur ; le lakehouse la fait porter par la table, à l’écriture.

Critère	Data lake	Lakehouse
Stockage	Objet, fichiers ouverts	Objet, fichiers ouverts
Couche de table	Absente	Format de table ouvert
Schéma	Un par fichier, lu à la lecture	Dans les métadonnées de la table, vérifié à l’écriture
Transactions	Non	ACID par snapshot, sur une table
UPDATE / DELETE / MERGE	Réécriture manuelle de fichiers	Natifs
Évolution de schéma	Fragile (par nom de colonne)	Maîtrisée (par identifiant de colonne dans Iceberg)
Historique	Aucun	Time travel, rollback
Plusieurs moteurs	Possible, sans garanties	Possible, avec garanties si le catalogue est partagé
Maintenance	Peu	Compaction, expiration de snapshots, nettoyage d’orphelins
Risque principal	Marécage de données (data swamp)	Complexité d’exploitation

Limites à connaître

L’atomicité porte sur une table : il n’y a pas de transaction sur plusieurs tables. Iceberg n’impose pas de contrainte d’unicité : une clé « unique » se garantit avec un MERGE sur la clé métier, pas par le format. Enfin, les petits fichiers et la latence du catalogue sont des coûts d’exploitation réels.

« Schema on read » : ce que ça veut dire

Un fichier Parquet embarque déjà son schéma. Le lake n’est donc pas sans schéma : il a un schéma par fichier, sans cohérence garantie entre fichiers. Le lakehouse déplace l’autorité : c’est la table, ni le fichier ni le lecteur, qui dit quel est le schéma.

Ce que ça change concrètement

Cinq situations (renommer une colonne, modifier une ligne, relire le passé, écrire en concurrence, lire moins de données) montrent ce qui change entre un lac de fichiers et un lakehouse. Elles sont détaillées avec leurs données dans Lakehouse, cinq situations concrètes. En une phrase : le format de table gère le schéma, les modifications et les statistiques ; le catalogue rend la publication d’une version atomique et arbitre les écritures concurrentes.

Les technos

Formats de fichier, formats de table, catalogues, moteurs de calcul et interopérabilité entre formats sont comparés dans Écosystème lakehouse, formats, catalogues et moteurs.

À lire ensuite

1. Lakehouse, cinq situations concrètes : les différences, données à l’appui.
2. Écosystème lakehouse, formats, catalogues et moteurs : les briques et leur compatibilité.
3. Choisir entre lake, lakehouse et warehouse : quand choisir un lakehouse, et les offres managées.
4. dbt et le lakehouse : transformer dans un lakehouse.
5. Lakehouse auto-hébergé sur Scaleway : une mise en œuvre sans catalogue managé.

Notes liées

• Parquet, le format de fichier colonnaire : le format de fichier sous-jacent, statistiques et row groups.
• Schema-on-Write vs Schema-on-Read : le « schema on read » du lac et ses limites.
• ACID vs BASE : les garanties que la couche de table apporte.
• Staging, ODS, DWH et architecture médaillon : le médaillon sur de l’object storage.
• Glossaire data engineering : définitions de référence.
• MOC Data Engineering : carte du vault.