Formats Data Lake : Des Fichiers aux Abstractions Tabulaires
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.
Extrait de la fiche « Data Formats and Pipelines » · Demander la fiche complète
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 |
| Format | Origin | Metadata | Distinctive features |
|---|---|---|---|
| Delta Lake | Databricks, 2019; Linux Foundation | _delta_log/ JSON commits + Parquet checkpoints | deep Spark and Databricks integration, change data feed, UniForm can expose Iceberg metadata |
| Apache Iceberg | Netflix, 2018; Apache top-level 2020 | metadata.json → manifest lists → manifests | hidden partitioning, partition evolution, REST catalog; widely adopted across vendors and AWS (Glue, S3 Tables) |
| Apache Hudi | Uber, 2016-2017; Apache top-level 2020 | .hoodie/ timeline | record-level upserts, copy-on-write and merge-on-read tables, incremental pulls |
Extrait de la fiche « Data Formats and Pipelines » · Demander la fiche complète
Chronologie d'Évolution
Cadre de Décision
- Avez-vous besoin de transactions ACID sur votre lac ?
- Non: Des fichiers Parquet/ORC bruts suffisent
- Oui: À quoi ressemble votre stack ?
- Centrée sur Databricks: Delta Lake (intégration native)
- Multi-moteur / multi-cloud: Apache Iceberg
- Forte charge d'upserts (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 |