Le problème que résout l’architecture lakehouse
Pendant des années, les entreprises aux besoins d’analyse avancée ont dû choisir entre deux architectures aux compromis opposés :
L’entrepôt de données (data warehouse) classique offre d’excellentes performances en SQL, une gouvernance solide, une qualité de données garantie et des outils de BI matures. Mais il coûte cher à grande échelle, s’adapte mal aux données non structurées et n’est pas conçu pour l’entraînement de modèles de machine learning.
Le data lake offre un stockage peu coûteux pour tout type de données (structurées, semi-structurées, non structurées), de la souplesse pour les charges de machine learning et une capacité de montée en charge sur des volumes massifs. Mais sans gestion rigoureuse, il devient un « data swamp » : des données sans qualité, sans schéma, sans gouvernance, difficiles à exploiter de façon productive.
L’architecture lakehouse est née pour résoudre précisément ce dilemme, en réunissant le meilleur des deux approches dans une plateforme unique.
Ce qu’est le lakehouse et comment il fonctionne
Le lakehouse stocke les données dans un data lake à faible coût (généralement un stockage objet cloud comme S3, Azure Data Lake Storage ou GCS), mais y ajoute une couche de métadonnées et de gouvernance qui apporte les capacités de l’entrepôt de données : transactions ACID, respect du schéma, requêtes SQL performantes, gestion des versions et lignage des données.
Les formats de table ouverts qui rendent cela possible sont :
Delta Lake : développé par Databricks, désormais open source. C’est le format de référence de Microsoft Fabric, de Databricks et d’Azure. Il prend en charge les transactions ACID, le time travel (consulter l’état des données à n’importe quel moment passé), les évolutions de schéma et l’optimisation automatique des fichiers.
Apache Iceberg : développé par Netflix et largement adopté dans l’écosystème AWS (Athena, EMR, Glue). Il offre des fonctionnalités proches de Delta Lake, avec un accent particulier sur l’interopérabilité entre moteurs de requête.
Apache Hudi : développé par Uber, axé sur les mises à jour incrémentales et l’intégration avec Spark. Particulièrement utile pour les cas d’usage de CDC (Change Data Capture).
Lakehouse ou entrepôt de données classique : comparatif
| Critère | Entrepôt de données | Lakehouse |
|---|---|---|
| Coût de stockage | Élevé | Faible (stockage objet) |
| Types de données | Principalement structurées | Structurées, semi-structurées, non structurées |
| Machine learning et data science | Limité | Natif |
| Performances SQL | Très élevées | Élevées (avec optimisation) |
| Gouvernance | Mature | En cours de maturation |
| Souplesse du schéma | Faible | Élevée |
Pour beaucoup d’entreprises, l’architecture lakehouse est l’évolution naturelle d’un entrepôt de données qui ne parvient plus à absorber la diversité et le volume des données actuelles, sans avoir à maintenir deux plateformes distinctes avec les coûts et la complexité que cela implique.
Les offres lakehouse du marché
Les principaux fournisseurs qui proposent une architecture lakehouse sont :
- Databricks Lakehouse Platform : l’implémentation de référence, avec Delta Lake comme format natif.
- Microsoft Fabric : OneLake au format Delta Parquet, avec un accès unifié depuis tous les services.
- Snowflake : parti de l’entrepôt de données pur, il a évolué vers des capacités lakehouse avec la prise en charge des données non structurées et du machine learning.
- AWS Lake Formation + Apache Iceberg/Hudi : une pile open source sur AWS.
Le choix entre ces offres dépend de l’écosystème cloud en place, des compétences de l’équipe et des exigences propres à chaque cas d’usage.
Quand adopter le lakehouse
Plusieurs signes indiquent qu’il est temps d’évaluer une architecture lakehouse : l’équipe data doit combiner SQL analytique et Python/machine learning sur les mêmes données, le coût de l’entrepôt de données actuel pose problème, l’entreprise doit stocker et analyser des données non structurées (images, texte, logs), ou elle souhaite éviter de maintenir deux plateformes distinctes (un data lake pour le machine learning et un entrepôt pour la BI).
Questions fréquentes
Le lakehouse remplace-t-il entièrement l’entrepôt de données ? Souvent, mais pas toujours. Pour les organisations aux charges SQL très intensives, l’entrepôt de données classique reste plus rapide sur les requêtes complexes portant sur des données structurées. L’écart de performances s’est toutefois nettement réduit grâce aux optimisations de Delta Lake et d’Iceberg. La décision doit reposer sur la combinaison de charges de travail propre à chaque entreprise.
Quel format de table ouvert choisir : Delta Lake, Iceberg ou Hudi ? Cela dépend de l’écosystème. Delta Lake est le choix naturel avec Databricks, Azure ou Microsoft Fabric. Iceberg est préférable sur AWS. Hudi présente des avantages pour les cas d’usage comportant de nombreuses mises à jour incrémentales. Bonne nouvelle : les trois formats convergent sur le plan fonctionnel et leur interopérabilité ne cesse de progresser.
Comment migrer un entrepôt de données existant vers un lakehouse sans interrompre l’activité ? La migration la plus sûre est progressive : on maintient l’entrepôt existant en service, on construit le lakehouse en parallèle avec les nouveaux flux de données, puis on migre peu à peu les charges de travail de l’entrepôt vers le lakehouse, par domaine ou par équipe. Chaque étape peut ainsi être validée avant la suivante, ce qui réduit le risque opérationnel.