Iceberg vs Delta vs Hudi : la guerre des open table formats

Pendant dix ans, les data lakes posaient des fichiers Parquet dans S3 et priaient pour que les requêtes tiennent. Les open table formats — Apache Iceberg, Delta Lake, Apache Hudi — apportent enfin transactions ACID, schema evolution, time travel et compaction à ces lacs. Mais leur adoption a une conséquence stratégique : elle reconfigure le choix entre Snowflake, Databricks, BigQuery et redonne du pouvoir aux architectures multi-engine. Voici un comparatif structurant.

Pourquoi un open table format

Sans table format, un dossier Parquet est un dossier Parquet : pas de transaction, pas de schema evolution propre, lecture instable en cas d'écriture concurrente. Un open table format ajoute une couche de métadonnées au-dessus des fichiers (Parquet, ORC) qui apporte :

• Transactions ACID sur le lake.
• Schema evolution (ajout, renommage, type change contrôlés).
• Partition evolution sans réécriture totale.
• Time travel : interroger l'état d'une table à un instant T.
• Compaction automatique de petits fichiers.
• Lecture cohérente même en cas d'écriture concurrente.

Les 3 formats en bref

Apache Iceberg

• Né chez Netflix, projet Apache top-level depuis 2020.
• Spécifié de façon ouverte, indépendant d'un moteur.
• Catalogues multiples : REST catalog, Hive, Nessie, AWS Glue, Polaris.
• Support natif : Snowflake, Databricks, Trino, Starburst, Dremio, Flink, Spark, DuckDB, ClickHouse, BigQuery (lecture).
• Tendance de fond du marché en 2025-2026.

Delta Lake

• Créé par Databricks, désormais Linux Foundation.
• Excellente intégration Spark / Databricks (DBR optimisé pour Delta).
• UniForm : Delta peut être lu as Iceberg depuis des moteurs externes.
• Très mature pour le streaming (Auto Loader, Change Data Feed).
• Adoption forte dans les organisations Databricks-centric.

Apache Hudi

• Né chez Uber pour des cas d'usage CDC à grande échelle.
• MoR (Merge-on-Read) et CoW (Copy-on-Write) : choix fin selon latence vs lecture.
• Indexation intégrée (record index, bucket index).
• Très bon pour les patterns d'upserts massifs et les workloads CDC streaming.
• Communauté plus petite que Iceberg / Delta mais cas d'usage très solides.

Comparatif structurant

Critère	Iceberg	Delta Lake	Hudi
Origine	Netflix → Apache	Databricks → Linux Foundation	Uber → Apache
Indépendance moteur	Forte	Moyenne (best with Spark/Databricks)	Forte
Snowflake natif	Oui (Iceberg tables)	Lecture via UniForm	Non natif
Databricks natif	Oui	Format historique	Oui (moins optimisé)
BigQuery	Lecture (BigLake)	Lecture limitée	Lecture limitée
Trino / Starburst / Dremio	Excellent	Bon (UniForm)	Bon
Streaming / CDC	Bon	Très bon	Excellent
Branching / merge (data DevOps)	Via Nessie / Polaris	Limité	Limité
Maturité écosystème	Très forte (2025-2026)	Très forte	Forte
Catalog standardisé	REST catalog spec	Unity / Delta sharing	HMS, Glue

Conséquences sur le choix de plateforme

Snowflake

• Bascule progressive vers Iceberg tables natives (lecture + écriture).
• Permet d'héberger ses propres données dans son S3 tout en gardant Snowflake comme moteur d'analytique.
• Réduit le lock-in historique, démocratise les architectures multi-engine.

Databricks

• Pousse Delta + UniForm (Delta lisible comme Iceberg).
• Polaris Catalog (Iceberg REST catalog open source) pour fédérer les moteurs.
• Reste la plateforme la plus mature pour Spark + streaming + ML sur lakehouse.

BigQuery

• Support BigLake sur Iceberg en lecture (et évolutions en cours côté écriture).
• Permet de combiner BigQuery (moteur) et Iceberg (format ouvert dans GCS).
• Stratégie ouverte mais maturité Iceberg en deçà de Snowflake / Databricks.

Trino / Starburst / Dremio / DuckDB / ClickHouse

• Tous misent sur Iceberg comme format universel.
• Permettent des architectures multi-engine où chaque moteur lit le même format.

Stratégie multi-engine : ce que ça change concrètement

Adopter un open table format standardisé (Iceberg en priorité aujourd'hui) ouvre des architectures où :

• L'ingestion se fait avec Flink, Spark Structured Streaming ou Kafka Connect.
• Le stockage est sur S3 / GCS / Azure Blob, dans un format ouvert.
• Plusieurs moteurs lisent la même donnée : Snowflake pour le BI, Databricks pour le ML, DuckDB pour le local, Trino pour l'ad-hoc.
• Le catalog Iceberg REST (Polaris, Nessie) sert d'autorité unique.

C'est la principale rupture par rapport à 2020 : on ne choisit plus un produit qui possède la donnée, on choisit un format ouvert et plusieurs moteurs autour.

Critères de décision

1. Stack existante : 80 % Databricks → Delta natif + UniForm est pragmatique. Cible multi-engine → Iceberg.
2. Patterns d'écriture : upserts massifs streaming → Hudi mérite l'évaluation.
3. Stratégie souveraineté / portabilité : Iceberg pour minimiser le lock-in.
4. Maturité de l'équipe : Delta sur Databricks reste le chemin le plus simple.
5. BI exécutif : si Snowflake reste la couche de service, Iceberg natif est le meilleur choix.

Pièges classiques

• Mélanger des formats sans gouvernance (Iceberg + Delta + Parquet brut dans le même lake).
• Sous-estimer la compaction et le tuning des petits fichiers.
• Oublier que le catalog est aussi critique que le format (REST catalog vs HMS vs Glue).
• Choisir un format par effet de mode sans valider le moteur cible.
• Ignorer les coûts S3 liés aux opérations métadata et au listing.

Profils mobilisés

• Data Platform Engineer : pose le lakehouse, choisit le format et le catalog.
• Data Engineer : écrit les pipelines (Spark, Flink, dbt).
• Architecte data : arbitre Iceberg / Delta / Hudi, définit la stratégie multi-engine.
• DataOps / FinOps data : surveille la compaction, le coût stockage et requêtes.

Voir FinOps de la donnée.

Conclusion : 2026, l'année où le format prime sur le moteur

Le débat n'est plus tant "Snowflake ou Databricks" que "quel format ouvert sous quels moteurs". Iceberg s'impose comme standard de fait pour la portabilité ; Delta reste premier choix dans les écosystèmes Databricks-centric, avec UniForm pour s'ouvrir ; Hudi conserve sa niche sur les workloads CDC très exigeants. La bonne décision est rarement religieuse — elle se prend en regardant ce qu'on écrit, qui lit, et où on veut être dans 3 ans.

Pour aller plus loin :

• Data Mesh en pratique
• Migration legacy → cloud data platform
• FinOps de la donnée : maîtriser Snowflake, BigQuery, Databricks
• CDC & streaming temps réel

ForTeam IT positionne des architectes lakehouse, data engineers et data platform engineers capables d'arbitrer Iceberg, Delta, Hudi sur des contextes grands comptes. Si c'est votre terrain, vous êtes au bon endroit.

Rejoindre ForTeam IT