Data lake, data warehouse, lakehouse : ce qui les distingue vraiment
Les trois termes reviennent partout et se ressemblent sur le papier. Voici comment je les distingue une fois qu'on regarde ce qu'ils font réellement.
Ces trois termes se retrouvent dans presque toutes les offres d’emploi en data, souvent sans définition claire. Voici comment je les distingue, après avoir creusé le sujet pour comprendre où se situent réellement les différences.
Data warehouse : le schéma d’abord
Un data warehouse impose un schéma avant l’écriture des données (“schema-on-write”). Les données y sont structurées, typées, généralement organisées en modèle en étoile ou en flocon pour l’analytique. L’avantage : les requêtes sont rapides et fiables parce que la structure est garantie. L’inconvénient : tout ce qui ne rentre pas facilement dans un schéma relationnel (logs semi-structurés, fichiers texte, données imbriquées) est difficile à y stocker sans travail de transformation préalable.
Data lake : le schéma ensuite
Un data lake stocke les données dans leur format natif — CSV, JSON, Parquet, images, logs — sans imposer de structure à l’écriture. Le schéma est appliqué à la lecture (“schema-on-read”), au moment où quelqu’un interroge les données. C’est ce qui permet de stocker des sources hétérogènes sans les faire rentrer de force dans un moule commun dès le départ.
La contrepartie, c’est que sans discipline, un data lake devient vite un “data swamp” : personne ne sait plus ce que contient chaque fichier ni si les données sont fiables. C’est justement le problème que l’architecture medallion (bronze / silver / gold) essaie de résoudre en imposant une structure progressive plutôt qu’un schéma rigide dès le départ.
Lakehouse : les deux à la fois
Le lakehouse est une tentative de combiner les deux : garder le stockage flexible et peu coûteux d’un data lake (typiquement sur S3 ou équivalent), tout en ajoutant une couche qui apporte les garanties d’un data warehouse — transactions ACID, gestion de schéma, versioning des données. Des formats comme Delta Lake, Apache Iceberg ou Apache Hudi jouent ce rôle de couche intermédiaire.
Concrètement, ça veut dire qu’on peut interroger les mêmes données avec des outils analytiques classiques (SQL, BI) tout en gardant la flexibilité de stocker des données brutes variées sans transformation préalable obligatoire.
Comment je choisis, en pratique
Sur mon projet autour du jeu de données DPE, je pars sur une architecture data lake avec un pattern medallion sur S3 plutôt qu’un data warehouse classique dès le départ, pour deux raisons : le coût de stockage S3 est faible, et les deux sources de données (logements neufs et logements existants) ont des schémas différents que je préfère harmoniser progressivement plutôt que d’imposer un schéma unique dès l’ingestion. Athena me permet ensuite d’interroger cette couche silver en SQL sans avoir besoin d’un data warehouse dédié pour une première itération.
Ce choix n’est pas définitif : si le volume de requêtes analytiques augmentait significativement, basculer une partie des données vers un vrai data warehouse (ou ajouter une couche lakehouse type Iceberg) deviendrait pertinent. C’est le genre d’arbitrage que je documenterai au fur et à mesure dans le portfolio.