Data lakehouse
Aussi : Lakehouse, Data lakehouse, Maison du lac de donnees, Lac-entrepot de donnees
Une architecture hybride qui combine la flexibilité d'un data lake et les capacités analytiques d'un data warehouse, sur une seule couche de stockage.
De quoi il s'agit
Un data lakehouse est une architecture de données qui réunit deux mondes jusque-là séparés :
- Le data lake : un stockage peu coûteux et scalable (généralement un stockage objet comme Amazon S3, Azure Data Lake Storage ou Google Cloud Storage) qui conserve les données brutes dans n'importe quel format (tables structurées, JSON, images, logs, vidéo).
- Le data warehouse : un système gouverné et performant, optimisé pour l'analytique SQL, avec des schémas, des transactions et des requêtes rapides.
Le lakehouse garde toutes les données dans des formats de fichiers ouverts (comme Parquet) sur du stockage à bas coût, puis ajoute par-dessus une couche de métadonnées et de transactions (des formats de table ouverts comme Apache Iceberg, Delta Lake ou Apache Hudi). Cette couche apporte au lake des fonctionnalités dignes d'un warehouse : transactions ACID, contrôle des schémas, versioning et gouvernance.
Pourquoi c'est important
Avant le lakehouse, les organisations exploitaient souvent deux stacks : un lake pour la data science et le stockage brut, et un warehouse séparé pour la business intelligence. Les données étaient copiées de l'un à l'autre, d'où un stockage dupliqué, des pipelines supplémentaires, des coûts plus élevés et plusieurs versions de la vérité.
Le lakehouse promet :
- Une seule copie des données au service des dashboards BI, du SQL ad hoc et du machine learning.
- Un coût réduit, en utilisant du stockage objet plutôt que le stockage propriétaire d'un warehouse.
- Des formats ouverts qui évitent le vendor lock-in.
- Gouvernance et qualité appliquées une seule fois, de façon cohérente.
Comment on l'utilise en pratique
Les équipes organisent généralement le lakehouse en niveaux, souvent appelés bronze, silver, gold :
- Bronze : données brutes ingérées, telles que reçues.
- Silver : données nettoyées, dédupliquées, conformées.
- Gold : agrégats et métriques prêts pour le business et le reporting.
Les analystes interrogent les tables gold en SQL. Les data scientists entraînent leurs modèles sur les données silver ou bronze. Les deux utilisent les mêmes fichiers sous-jacents.
Exemple concret détaillé
Un distributeur envoie en streaming ses transactions de point de vente, son clickstream web et ses flux de stock vers un stockage objet (bronze). Un pipeline les nettoie et les joint dans des tables silver, en s'appuyant sur un format de table ouvert qui garantit un snapshot cohérent même pendant l'arrivée de nouvelles données.
- L'équipe finance interroge les tables gold pour le chiffre d'affaires et la marge quotidiens.
- L'équipe marketing construit des segments clients à partir du même clickstream.
- L'équipe data science entraîne un modèle de churn sur l'historique brut des événements.
Aucune donnée n'est copiée dans un warehouse séparé. Une plateforme gouvernée, de nombreux consommateurs.
Voir aussi
Questions fréquentes
Qu'est-ce qu'un data lakehouse, en clair ?
Un data lakehouse est une architecture qui stocke toutes les données dans des formats de fichiers ouverts sur du stockage objet peu coûteux (Amazon S3, Azure Data Lake Storage, Google Cloud Storage), puis ajoute par-dessus une couche de métadonnées et de transactions qui lui donne le comportement d'un entrepôt de données. Cette couche apporte au lac les transactions ACID, le contrôle de schéma, le versionnement et la gouvernance. Résultat : une seule copie des données alimente la BI, le SQL ad hoc et le machine learning.
Quelle différence entre data lake, entrepôt de données et lakehouse ?
Un data lake est un stockage peu coûteux et extensible pour des données brutes de tout format (tables, JSON, images, logs, vidéo), sans les garanties d'un entrepôt. Un entrepôt de données est un système gouverné et performant, optimisé pour l'analytique SQL, avec schémas, transactions et requêtes rapides. Le lakehouse conserve le stockage et les formats ouverts du lac, et y ajoute les fonctions de l'entrepôt : plus besoin d'entretenir deux stacks séparées.
Pourquoi abandonner un fonctionnement avec un lac et un entrepôt en parallèle ?
Parce que deux stacks impliquent de recopier les données de l'une vers l'autre : stockage dupliqué, pipelines supplémentaires, coûts en hausse et plusieurs versions de la vérité. Le lakehouse conserve une seule copie gouvernée, s'appuie sur du stockage objet plutôt que sur le stockage propriétaire d'un entrepôt, utilise des formats ouverts qui limitent le vendor lock-in, et applique gouvernance et qualité une seule fois.
Que signifient les couches bronze, silver et gold dans un lakehouse ?
Ce sont les trois niveaux utilisés pour organiser les données d'un lakehouse. Bronze contient les données brutes telles qu'elles arrivent, silver les données nettoyées, dédoublonnées et conformées, gold les agrégats et indicateurs prêts pour le reporting. Les analystes interrogent les tables gold en SQL, les data scientists entraînent leurs modèles sur silver ou bronze, tout le monde sur les mêmes fichiers sous-jacents.
Quelles technologies rendent un lakehouse possible ?
Deux briques : un format de fichier ouvert comme Parquet pour les données, et un format de table ouvert comme Apache Iceberg, Delta Lake ou Apache Hudi pour la couche de métadonnées et de transactions. C'est le format de table qui garantit les transactions ACID, le contrôle de schéma et des snapshots cohérents : un pipeline peut lire une vue stable d'une table pendant que de nouvelles données arrivent.