Stockage & modèles de données : Lakehouse vs Warehouse

Dans Microsoft Fabric, deux objets couvrent les principaux modes de stockage et de traitement analytique : le Lakehouse et le Warehouse.

Lakehouse :

Un Lakehouse dans Microsoft Fabric combine la flexibilité d’un Data Lake avec les capacités analytiques d’un Data Warehouse. Il stocke les données au format ouvert Delta Lake (Parquet) dans OneLake, permettant à la fois l’ingestion massive de données brutes et l’analyse structurée. Il supporte une architecture médaillée (Bronze, Silver, Gold) et offre un accès multi-protocole via Spark, SQL Endpoint automatique et Power BI en mode DirectLake, ce qui le rend idéal pour l’exploration, la préparation de données et les scénarios de data science.

Warehouse :

Un Warehouse dans Microsoft Fabric est un entrepôt de données optimisé pour les requêtes analytiques . Il propose un modèle relationnel structuré (tables, vues, procédures stockées) avec un moteur SQL pour l’analytique. Il offre une gouvernance renforcée et une sécurité au niveau des lignes/colonnes, avec une compatibilité T-SQL complète, ce qui le rend idéal pour la consommation BI et les rapports d’entreprise.

Ils s’appuient tous deux sur OneLake, mais répondent à des besoins différents en termes de préparation, de gouvernance et de consommation BI.

Critère	Lakehouse	Warehouse
Rôle	Préparer et unifier des données variées (souvent des fichiers).	Organiser et servir un modèle d’entreprise stable pour les tableaux de bord.
Types de données	Fichiers (CSV, Excel, logs) + tables Delta.	Tables relationnelles structurées.
Accès aux données / langage	Lecture SQL possible ; préparation surtout via notebooks (Spark).	SQL complet (T-SQL), procédures et transactions.
Performance & volume	Adapté à des volumes importants et des chargements réguliers de fichiers.	Prend en charge de nombreux utilisateurs en même temps et des requêtes régulières.
Sécurité& gouvernance	Contrôles d’accès par équipes ; filtrage côté modèle BI.	Affichage filtré par utilisateur, avec possibilité de masquer les colonnes sensibles au niveau des tables/vues.
Coûts & exploitation	Coût d’entretien des tables Delta (éviter les petits fichiers, compacter/optimiser).	Coût lié aux requêtes SQL et aux chargements réguliers des données .
Mises à jour & transactions	Mises à jour SQL limitées ; préférer les transformations Spark pour modifier les données.	Mises à jour et transactions rapides (jointure/mise à jour /suppression ) sur les tables.
Évolution du schéma	Flexible (ajouts/évolutions) mais nécessite des règles de schéma pour éviter les ruptures.	Schéma encadré et stable (règles strictes, adapté au long terme).
Cas d’usage typiques	Quand on part de fichiers, qu’il faut préparer et intégrer des sources variées (flexibilité, multi-cloud via raccourcis).	Quand on veut un modèle d’entreprise stable, indicateurs certifiés et beaucoup d’utilisateurs.
à éviter	Multiplication de petits fichiers, schémas changeants sans contrat.	Tout faire en T-SQL si la préparation est lourde (mieux la faire en amont dans le Lakehouse).