Formats Data Lake : Des Fichiers aux Abstractions Tabulaires
#data-engineering#data-lake#parquet#iceberg#delta-lake
Le lakehouse moderne repose sur deux couches de choix de format : le format de fichier qui stocke les octets sur disque, et le format de table qui ajoute une sémantique transactionnelle par-dessus. Bien choisir détermine la vitesse des requêtes, le coût de stockage, la flexibilité du schéma et la compatibilité écosystème.
Comparaison des Formats de Fichiers
| Caractéristique | Parquet | ORC | Avro | CSV / JSON |
|---|---|---|---|---|
| Modèle de stockage | Colonnaire | Colonnaire | Par ligne | Par ligne |
| Compression | Excellente (Snappy, Zstd) | Excellente (Zlib, Snappy) | Bonne | Mauvaise |
| Évolution du schéma | Limitée (ajout colonnes) | Limitée | Forte (compatibilité complète) | Aucune |
| Performance lecture (analytique) | Excellente — élagage de colonnes | Excellente | Faible | Très faible |
| Support écosystème | Universel (Spark, Flink, Trino, DuckDB) | Hive/Spark-centrique | Kafka, outils Avro-natifs | Universel mais lent |
| Cas d'usage idéal | Analytique, stockage lakehouse | Workloads Hive | Streaming, schema registry | Échange, debug |
Parquet est devenu le standard de fait pour le stockage analytique. Son layout colonnaire permet le predicate pushdown et l'élagage de colonnes, réduisant les I/O de 90%+ sur les tables larges.
Comparaison des Formats de Table
| Caractéristique | Apache Iceberg | Delta Lake | Apache Hudi |
|---|---|---|---|
| Gouvernance | Fondation Apache | Linux Foundation (origine Databricks) | Fondation Apache |
| Transactions ACID | Oui | Oui | Oui |
| Time travel | Oui — base de snapshots | Oui — journal de versions | Oui — base de timeline |
| Évolution du schema | Complete (ajout, suppression, renommage) | Ajout/renommage | Ajout colonnes |
| Ãvolution de partition | Oui — partitionnement cache | Non — nécessite recriture | Limite |
| Moteurs de requête | Spark, Flink, Trino, DuckDB, Athena, BigQuery | Spark, Flink, Trino | Spark, Flink, Trino |
| Dynamique communautaire (2026) | Très élevée — convergence industrielle | Élevée — écosystème Databricks | Modérée |
Chronologie d'Évolution
2009 ──── Apache Avro 1.0
2010 ──── Apache Parquet (inspiration papier Dremel)
2013 ──── Format ORC introduit (projet Hive)
2016 ──── Apache Hudi créé chez Uber
2017 ──── Delta Lake créé chez Databricks
2018 ──── Apache Iceberg créé chez Netflix
2022 ──── Iceberg adopté par AWS, Snowflake, Dremio
2024 ──── Delta Lake UniForm lit les métadonnées Iceberg
2026 ──── Convergence industrielle : Iceberg comme format d'échange
Cadre de Décision
Avez-vous besoin de transactions ACID sur votre lac ?
├── Non → Fichiers Parquet/ORC bruts suffisent
└── Oui
├── Stack centré Databricks ? → Delta Lake
├── Multi-moteur / multi-cloud ? → Apache Iceberg
└── Forte charge upsert (CDC) ? → Apache Hudi ou Iceberg MoR
Bonnes Pratiques de Layout Stockage
| Pratique | Impact | Détails |
|---|---|---|
| Viser des fichiers de 128-512 Mo | Performance lecture | Les petits fichiers causent un overhead métadonnées |
| Partitionnement caché (Iceberg) | Vitesse + flexibilité | Partitionner par transformation (jour, bucket) |
| Activer les statistiques de colonnes | Predicate pushdown | Stats min/max permettent de sauter les fichiers non pertinents |
| Compacter régulièrement | Maintenance performance | Fusionner les petits fichiers produits par le streaming |
| Expirer les anciens snapshots | Coût stockage | L'historique de time travel croît sans limite sans nettoyage |
Ressources
- Documentation Apache Iceberg
- Documentation Delta Lake
- Specification Format Parquet
- Tabular — Pourquoi Apache Iceberg
:::