Data Lakehouse : Le Meilleur des Deux Mondes ?
#data-architecture#data-engineering#cloud#analytics
La Séparation Historique
Pendant deux décennies, les organisations ont choisi entre deux paradigmes :
- Data Warehouse : structuré, schema-on-write, SQL rapide, stockage coûteux, gouverné
- Data Lake : semi/non structuré, schema-on-read, stockage économique, flexible, souvent chaotique
Le pattern lakehouse a émergé pour unifier les deux : apporter la structure et la performance du warehouse au stockage à l'échelle du lake.
Ce qui Définit un Lakehouse
Un lakehouse ajoute une couche de métadonnées et de transactions au-dessus du stockage objet (S3, GCS, ADLS). Les capacités clés :
| Capacité | Fonctionnement |
|---|---|
| Transactions ACID | Les logs de métadonnées tracent les commits, permettant rollback et cohérence |
| Application du Schéma | Schema-on-write appliqué au niveau de la table |
| Évolution du Schéma | Ajout/renommage de colonnes sans réécriture des données |
| Time Travel | Requêter des snapshots historiques de n'importe quelle table |
| Batch & Streaming Unifiés | Les mêmes tables supportent écriture batch et upserts streaming |
| Formats Ouverts | Données stockées en Parquet/ORC, lisibles par tout moteur |
tadata
Extrait de la fiche « Data Formats and Pipelines » · Demander la fiche complète
Les Trois Formats de Table
| Caractéristique | Delta Lake | Apache Iceberg | Apache Hudi |
|---|---|---|---|
| Origine | Databricks | Netflix | Uber |
| Gouvernance | Linux Foundation | Apache Foundation | Apache Foundation |
| Support Moteurs | Fort Spark, croissant autres | Le plus large multi-moteur | Fort Spark/Flink |
| Évolution Partition | Limitée | Native (partitions cachées) | Limitée |
| Dynamique Communauté (2026) | Très forte | Très forte | Modérée |
Lake vs Warehouse vs Lakehouse
| Dimension | Data Lake | Data Warehouse | Lakehouse |
|---|---|---|---|
| Coût stockage | Faible | Élevé | Faible |
| Performance requêtes | Variable | Élevée | Élevée (avec optimisation) |
| Application schema | Aucune | Stricte | Configurable |
| Types de données | Tous | Structuré uniquement | Tous |
| Transactions ACID | Non | Oui | Oui |
| Lock-in fournisseur | Faible | Élevé | Faible-Moyen |
Quand Choisir Quoi
Choisir un warehouse quand :
- Vos charges sont purement analytiques SQL
- Vous avez besoin de performance maximale sur données structurées
- Votre équipe est SQL-first avec capacité d'ingénierie limitée
Choisir un lakehouse quand :
- Vous avez besoin d'analytics et de ML sur les mêmes données
- Le coût à grande échelle compte (gamme pétaoctet)
- Vous voulez des formats ouverts et de la flexibilité moteur
- Vous devez supporter streaming et batch
Architecture en Medallion
- Bronze -- ingestion brute, append-only, transformation minimale
- Silver -- nettoyé, dédupliqué, conforme, clés métier appliquées
- Gold -- agrégé, prêt pour le métier, optimisé pour la consommation
tadata
Extrait de la fiche « DP-750 Domain 3a: Model and Ingest Data in Unity Catalog » · Demander la fiche complète
Décisions Clés
- Format de table : Iceberg a le support moteur le plus large ; Delta a l'intégration Spark la plus profonde
- Moteur de calcul : Spark, Trino, DuckDB, Snowflake (avec Iceberg), Athena
- Catalogue : AWS Glue, Hive Metastore, Nessie, Unity Catalog, Polaris
- Stratégie de compaction : automatisée vs manuelle, fréquence vs coût