Un data lakehouse est une architecture de données qui combine le stockage économique et ouvert d'un data lake (fichiers dans un stockage objet de type S3) avec les garanties d'un data warehouse : transactions fiables, schémas, requêtes SQL performantes.
La clé est un format de table ouvert (Apache Iceberg, Delta Lake ou Apache Hudi) posé au-dessus de fichiers Parquet. Cette couche de métadonnées apporte les transactions, le retour à une version passée des données (time travel) et l'évolution du schéma sans tout réécrire.
L'intérêt : une seule copie des données sert à la fois l'analyse BI, la data science et le machine learning, et plusieurs moteurs (Spark, Trino, Snowflake, DuckDB…) peuvent lire les mêmes tables. Cela limite la dépendance à un seul éditeur.
Le terme a été popularisé par Databricks. On le croise dans les entreprises qui manipulent de gros volumes ou qui veulent garder la maîtrise de leur stockage.
Pourquoi ça compte quand on recrute
Un Data Engineer qui a vraiment travaillé sur un lakehouse sait parler de compaction des fichiers, de partitionnement, de gestion des schémas et du coût des requêtes. C'est là qu'on distingue l'expérience réelle d'une simple utilisation de Databricks en surface. Ne confondez pas « connaît Databricks » et « a conçu une architecture lakehouse » : ce sont deux niveaux différents.