Choisir entre lake, lakehouse et warehouse

Résumé

Un lakehouse se justifie quand les données sont modifiées souvent (mises à jour, CDC, suppressions), que plusieurs moteurs lisent les mêmes tables, ou que la maîtrise du stockage compte (souveraineté, coût de sortie). Sinon, un lac bien organisé ou un entrepôt managé est plus simple. Le lakehouse échange un coût d’éditeur contre un coût d’exploitation : voir Maintenance d’un lakehouse.

Prérequis

Data lake vs lakehouse pour les définitions et les composants.

Logique de décision

flowchart TD
    A{"Mutations fréquentes ?<br/>MERGE, CDC, suppressions"} -- non --> L["Lac organisé<br/>fichiers + partitionnement"]
    A -- oui --> B{"Plusieurs moteurs<br/>sur les mêmes tables ?"}
    B -- oui --> H["Lakehouse<br/>format de table + catalogue"]
    B -- non --> C{"Un moteur managé<br/>couvre-t-il tout le besoin ?"}
    C -- oui --> W["Warehouse managé"]
    C -- non --> H
    H --> D{"Équipe capable d'exploiter<br/>catalogue et maintenance ?"}
    D -- oui --> SH["Lakehouse auto-hébergé"]
    D -- non --> MG["Lakehouse managé<br/>par un éditeur"]

Le diagramme suppose de gros volumes bruts ; à petit volume et avec une équipe réduite, le tableau « Cas typiques » ci-dessous oriente plutôt vers un warehouse managé.

Critères

Critère	Vers le lac	Vers le lakehouse	Vers le warehouse
Mutations	Rares, ajouts seuls	Fréquentes	Fréquentes, un seul moteur
Nombre de moteurs	Un	Plusieurs sur les mêmes tables	Un
Volumétrie	Très gros volumes bruts	Gros volumes avec historique	Tous volumes (les warehouses cloud gèrent des pétaoctets)
Équipe	Petite, peu d’exploitation	Capable d’exploiter ou offre managée	Veut zéro exploitation
Format de stockage	Ouvert	Ouvert	Souvent propre au produit
Souveraineté et localisation	Au choix	Au choix, données portables	Dépend de l’éditeur
Catalogue	Sans objet	Managé, sinon à auto-héberger	Intégré
Adapter dbt	Sans objet	À vérifier selon le moteur (voir dbt et le lakehouse)	Souvent first-party

Cas typiques

Situation	Orientation
Données brutes massives, peu de mutations	Lac organisé
CDC, historique long, plusieurs moteurs	Lakehouse
ML sur données non structurées et BI	Lakehouse
Petit volume, une équipe, besoin de simplicité	Warehouse managé
Brut en stockage maîtrisé et BI exigeante	Montage mixte : lakehouse pour l’historique, moteur dédié pour le service BI
Latence inférieure à la seconde	Hors sujet pour un lakehouse : base opérationnelle ou moteur de streaming (Kafka, Flink), non traités dans ce vault

Choisir son format de table

• Iceberg par défaut quand moteurs et catalogues doivent rester ouverts.
• Delta quand l’écosystème est Databricks ou Spark ; UniForm expose des métadonnées Iceberg en lecture.
• Hudi ou Paimon quand le besoin dominant est l’upsert fréquent ou le streaming, et que les moteurs retenus les supportent.

Offres managées

Les trois grands éditeurs proposent un lakehouse managé autour d’Iceberg, avec un catalogue intégré, ce qu’un fournisseur comme Scaleway ne propose pas (voir Lakehouse auto-hébergé sur Scaleway). Leur valeur : le catalogue et la maintenance automatisée. Leur coût : le couplage à un éditeur, une région et une juridiction.

Comparaison datée (relevé du 22 octobre 2026), à revérifier

Les statuts « disponibilité générale » ou « préversion » changent vite ; contrôler la documentation de chaque éditeur.

	BigQuery (Lakehouse)	Snowflake	Databricks
Catalogue	Lakehouse runtime catalog, API REST Iceberg	Horizon (managé) et Open Catalog (Polaris managé)	Unity Catalog, accès REST Iceberg
Écriture par des moteurs externes	Via le catalogue REST ; DML depuis BigQuery en préversion	Lecture des tables managées via Horizon, écritures limitées (pas de deletes d’égalité ni de CREATE TABLE AS SELECT)	Lecture seule pour du Delta exposé par UniForm, lecture et écriture pour les tables Iceberg managées
Maintenance	Automatique (taille des fichiers, clustering, ramasse-miettes, métadonnées) ; gestion automatique des tables en préversion	Compaction automatique sur les tables managées ; suppression des fichiers orphelins non prise en charge	Gérée par l’éditeur sur les tables managées
Déclaration côté dbt	Catalogue biglake_metastore dans catalogs.yml	Catalogue Horizon dans catalogs.yml	Catalogue Unity dans catalogs.yml

Renommage : depuis le 20 avril 2026, BigLake s’appelle « Lakehouse » et BigLake metastore « Lakehouse runtime catalog », d’après les notes de version de Google Cloud. Les noms d’API, de CLI et d’IAM restent « BigLake », et les anciens noms subsistent dans des tutoriels et dans la documentation dbt.

Maillage entre éditeurs

La documentation dbt décrit des maillages entre plateformes (Snowflake avec Databricks via Unity Catalog, avec Athena via Glue, avec BigQuery via le catalogue BigLake) : deux plateformes pointent vers la même table Iceberg. Écrire dans un catalogue externe est généralement plus lent et peut poser des problèmes de fiabilité à grande échelle. Le plus sûr : un catalogue maître par table et un seul moteur qui écrit.

Ce que cela change pour le choix

• Données et équipes déjà chez un éditeur : ses tables Iceberg managées apportent l’ouverture du format sans exploitation supplémentaire, au prix de son catalogue comme point de coordination.
• Contrainte de souveraineté ou de coût de sortie : object storage européen plus format ouvert gardent les données portables, mais la charge du catalogue et de la maintenance revient à l’équipe.
• Offres européennes managées : OVHcloud présente un service Lakehouse Manager sur Iceberg ; son statut n’est pas confirmé (seule la variante serverless est présentée comme « coming soon »).

Notes liées

• Data lake vs lakehouse : définitions.
• Écosystème lakehouse, formats, catalogues et moteurs : formats de table, catalogues, moteurs.
• Data mesh : quand la responsabilité de la donnée est répartie par domaine.
• Maintenance d’un lakehouse : ce que coûte le modèle en exploitation, et les pièges.
• Lakehouse auto-hébergé sur Scaleway : l’alternative auto-hébergée.
• dbt et le lakehouse : adapters selon le moteur.
• MOC Data Engineering : carte du vault.