Qu'est-ce qu'un Data Lakehouse ? Architecture et Avantages
Découvrez le Data Lakehouse, une architecture moderne qui combine la fiabilité des entrepôts de données avec la scalabilité des lacs de données. Apprenez ses composants clés, ses avantages et les défis opérationnels.
Introduction
Un Data Lakehouse est une architecture de données moderne qui vise à offrir la fiabilité et les capacités de gestion des entrepôts de données (Data Warehouses) tout en conservant la flexibilité et la scalabilité des lacs de données (Data Lakes). Il permet aux équipes d'utiliser une seule couche de stockage pour des charges de travail diverses, allant de l'analytique rapide au Machine Learning, réduisant ainsi la duplication des données et la complexité opérationnelle.
Précis de configuration
| Élément | Version / Lien |
|---|---|
| Stockage d'objets | AWS S3, Google Cloud Storage (GCS), Azure Data Lake Storage (ADLS) |
| Formats de table ouverts | Apache Iceberg, Delta Lake, Apache Hudi |
| Moteurs de traitement | Apache Spark, Trino |
| Outils de gouvernance | AWS Lake Formation, Databricks Unity Catalog |
| Sources de données | Bases de données, Logs, Images, Vidéos, Audio, Texte |
| Ingestion | ETL, Kafka (Streaming) |
| Consommateurs | BI/Tableaux de bord, Machine Learning |
Guide étape par étape
Systèmes de données traditionnels
Traditionnellement, les entreprises utilisaient deux systèmes distincts pour gérer leurs données :
- Data Warehouse (entrepôt de données) : Stocke des données organisées, nettoyées et prêtes pour l'analyse. Il supporte généralement les transactions ACID et est optimisé pour des requêtes SQL rapides, idéal pour les rapports financiers quotidiens.
- Data Lake (lac de données) : Stocke des données brutes, semi-structurées et non structurées à grande échelle, utilisant un stockage d'objets bon marché. Il est utilisé par les équipes de science des données pour stocker des millions de logs et entraîner des modèles de Machine Learning.
Le problème survient lorsque la plateforme grandit. Chaque changement de schéma nécessite de modifier deux chemins d'ingestion, deux vérifications de qualité et deux modèles d'accès, ce qui entraîne une charge de travail importante pour les ingénieurs de données qui doivent maintenir la synchronisation entre ces systèmes séparés.
Architecture d'un Data Lakehouse
Un Data Lakehouse est une architecture moderne qui vise à maintenir une seule couche de données partagée tout en préservant la fiabilité d'un Data Warehouse et la scalabilité d'un Data Lake.
Étape 1 — Stockage unifié
Tout commence par une couche de stockage unique. Pour une plateforme e-commerce, par exemple, les événements de commande bruts et les tables analytiques organisées résident désormais sur une seule couche de stockage d'objets (comme AWS S3 ou Google Cloud Storage).
Les données brutes sont traitées par un moteur de traitement (comme Apache Spark) et les résultats polis sont sauvegardés dans le stockage d'objets sous forme de fichiers optimisés (comme Parquet). Cela élimine la duplication des copies de données entre les systèmes séparés.
Étape 2 — Tables transactionnelles (Format de table ouvert)
Le stockage d'objets est hautement disponible, durable et évolue à moindre coût, mais il ne gère que des fichiers bruts et ne connaît pas la notion de table de base de données. Si une écriture échoue à mi-chemin, les lecteurs peuvent voir une vue incomplète ou incohérente de la table.
Pour remédier à cela, on ajoute un format de table ouvert (comme Apache Iceberg, Delta Lake ou Apache Hudi) au-dessus du stockage d'objets. Ces formats maintiennent des métadonnées de table, des instantanés (snapshots) et un historique des commits. Cela garantit que chaque écriture réussit ou échoue complètement, et les lecteurs obtiennent toujours une vue cohérente, même pendant des mises à jour concurrentes. Ils gèrent également l'évolution du schéma comme des opérations de métadonnées (par exemple, renommer une colonne sans réécrire les fichiers de données historiques).
Étape 3 — Catalogue partagé
Avec des tables fiables en place, la question est de savoir comment les différents outils les trouvent. Cela nécessite un catalogue partagé. Un catalogue mappe un nom de table (comme orders) à ses métadonnées, son schéma et sa version actuelle.
Quand un outil (comme Trino pour les requêtes rapides ou Apache Spark pour l'ingestion massive) veut lire ou écrire, il demande d'abord au catalogue où se trouve la dernière version. Cela crée une source unique de vérité, permettant à tous les outils de voir les mêmes données à jour.
Étape 4 — Gouvernance
Avec des métadonnées partagées, le prochain défi est la gouvernance à l'échelle de l'équipe. La gouvernance répond à des questions opérationnelles critiques :
- Quels ensembles de données existent ?
- D'où viennent-ils ?
- Qui peut lire des champs sensibles (comme les informations de paiement) ?
Des outils comme AWS Lake Formation ou Databricks Unity Catalog offrent un endroit centralisé pour gérer ces règles et verrouiller des colonnes spécifiques. De nombreuses équipes exigent que chaque humain et application passe par le catalogue de gouvernance centralisé. Sans cela, les politiques d'accès peuvent dériver et la propriété devenir floue.
Étape 5 — Opérations
Un Data Lakehouse réduit la duplication, mais ce n'est pas une base de données entièrement gérée. Vous assumez de nouvelles responsabilités de plateforme :
- Gestion des petits fichiers : À mesure que de nouvelles commandes arrivent, le stockage d'objets se remplit de milliers de petits fichiers, ce qui rend les requêtes lentes. Votre équipe doit planifier des tâches en arrière-plan pour fusionner périodiquement les petits fichiers en des fichiers plus grands et plus efficaces.
- Impact des mises à jour de schéma : Étant donné que le système est profondément partagé, une mauvaise mise à jour de schéma peut simultanément casser les tableaux de bord financiers et les pipelines de Machine Learning. Des normes strictes de type de données et des tests rigoureux sont essentiels.
Tableaux comparatifs
| Caractéristique | Data Warehouse | Data Lake | Data Lakehouse |
|---|---|---|---|
| Vitesse d'analyse | Rapide | Lente | Rapide |
| Coût de stockage | Élevé | Faible | Faible |
| Types de données | Structurées | Brutes, semi-structurées, non structurées | Tous types (structurées, semi-structurées, non structurées) |
| Fiabilité (ACID) | Oui | Non | Oui |
| Évolution du schéma | Complexe | Non gérée nativement | Facile (opérations de métadonnées) |
| Gouvernance | Intégrée | Manuelle/Ad-hoc | Intégrée |
| Cas d'usage principal | BI, rapports financiers | Machine Learning, stockage brut | BI, ML, streaming, analytique avancée |
| Effort d'ingénierie | Faible (géré) | Élevé (pour la fiabilité) | Élevé (pour la maintenance de la plateforme) |
⚠️ Erreurs fréquentes et pièges
- Vues de données incohérentes : Sans un format de table transactionnel, les écritures partielles sur le stockage d'objets peuvent laisser les lecteurs avec des données incomplètes ou incorrectes.
- Solution : Utiliser des formats de table ouverts comme Apache Iceberg, Delta Lake ou Apache Hudi qui garantissent les propriétés ACID.
- Problèmes d'évolution du schéma : Les changements de schéma dans les systèmes traditionnels peuvent casser les pipelines en aval. Dans un Data Lakehouse, une mauvaise gestion peut avoir un impact sur tous les consommateurs.
- Solution : Les formats de table ouverts gèrent l'évolution du schéma comme des opérations de métadonnées, mais il est crucial d'établir des normes strictes de type de données et de tester les changements.
- Performances de requête lentes dues aux petits fichiers : Le stockage d'objets se remplit de nombreux petits fichiers, ce qui ralentit considérablement les requêtes.
- Solution : Planifier des tâches en arrière-plan pour fusionner périodiquement les petits fichiers en des fichiers plus grands et plus efficaces.
- Manque de gouvernance centralisée : Sans un catalogue de gouvernance centralisé, il devient difficile de savoir qui a accès à quelles données, où elles proviennent et comment elles sont utilisées, ce qui peut entraîner des problèmes de conformité et de sécurité.
- Solution : Mettre en place un catalogue de gouvernance (comme AWS Lake Formation ou Databricks Unity Catalog) pour gérer les politiques d'accès et la lignée des données.
Glossaire
Data Lakehouse : Architecture de données combinant la scalabilité d'un Data Lake avec la fiabilité et la gestion d'un Data Warehouse.
Transactions ACID : Propriétés (Atomicité, Cohérence, Isolation, Durabilité) garantissant la fiabilité des transactions de base de données.
Format de table ouvert : Spécification de format de fichier et de métadonnées (comme Iceberg, Delta Lake, Hudi) qui ajoute des capacités transactionnelles et de gestion de schéma au-dessus du stockage d'objets.
Points clés à retenir
- Un Data Lakehouse unifie le stockage de données brutes et organisées sur une seule couche de stockage d'objets.
- Les formats de table ouverts (Iceberg, Delta Lake, Hudi) apportent des garanties transactionnelles ACID et une gestion de schéma flexible.
- Un catalogue partagé est essentiel pour une source unique de vérité, permettant à divers moteurs de traitement d'accéder aux mêmes données.
- La gouvernance des données est cruciale pour gérer les accès, la lignée et la sécurité des données à l'échelle.
- Bien qu'il offre flexibilité et scalabilité, un Data Lakehouse nécessite un effort d'ingénierie dédié pour la maintenance et l'optimisation (par exemple, la gestion des petits fichiers).
- Des normes strictes de type de données et des tests sont nécessaires pour assurer la compatibilité entre les différents moteurs de requête.