Iceberg, Delta Lake ou Hudi : quels critères de choix ?

La réponse courte

Les trois ajoutent une table au-dessus de fichiers (surtout Parquet) : snapshots, schéma, commits, élagage. Ce ne sont pas trois formats d’octets différents. Le critère n’est donc pas « lequel a le meilleur blog », c’est qui lit, qui écrit, et quel motif d’écriture.

Delta Lake. Très fort là où Databricks / Spark / Power BI autour de Unity Catalog sont déjà le centre de gravité. Time travel, OPTIMIZE, deletion vectors, écosystème mature sur le MERGE Spark. Moins naturel dès que le parc est Trino + Flink + un catalog ouvert, même si les lecteurs Delta se multiplient (Delta UniForm, etc.).

Apache Iceberg. Conçu pour être le format de table multi-moteurs : Spark, Trino, Flink, Snowflake, BigQuery, Athena, DuckDB. Catalogs ouverts (Hive, Glue, REST/Polaris, Nessie). Partitionnement caché, évolution de schéma robuste (ids de colonnes), expiration de snapshots claire. Souvent le choix « lac d’entreprise » quand personne ne veut d’un verrou constructeur.

Apache Hudi. Né pour l’upsert / CDC à haut débit ( MoR, index de clés, clustering). Si le problème est « je reproduis une table opérationnelle dans le lac toutes les minutes », Hudi a des réponses plus anciennes que les autres. La contrepartie : une courbe d’exploitation plus rude, et un écosystème de BI ad hoc parfois moins fluide qu’Iceberg aujourd’hui.

Une grille qu’on peut dire à voix haute

1. Moteurs de lecture. Un seul (Spark Databricks) → Delta est simple. Trois moteurs, dont un SQL élastique → Iceberg. Beaucoup de MERGE streaming depuis Kafka → Hudi ou Iceberg Flink, selon l’équipe.
2. Catalog et gouvernance. Unity déjà payé → Delta (ou Iceberg via UniForm). AWS Glue + Athena + Spark EMR → Iceberg colle au discours AWS. Multi-cloud, catalog REST → Iceberg.
3. Motif d’écriture. Append de faits → les trois se valent, Iceberg/Delta suffisent. Upsert massif fréquent → comparer MoR / deletion vectors et le coût de compaction, pas le logo.
4. Sortie. Pouvoir partir : Iceberg a aujourd’hui l’avantage politique. Delta s’ouvre (UniForm vers Iceberg). Hudi reste plus spécialisé.
5. Compétence de l’équipe. Un format mal opéré (VACUUM, compaction, concurrent writers) bat n’importe quel benchmark.

Ce que l’intervieweur vérifie

Que vous refusez le match « Iceberg gagne toujours ». En 2026, les trois convergent : Iceberg a amélioré les upserts, Delta parle aux autres moteurs, Hudi s’intègre aux catalogs. La mauvaise réponse est une guerre de religion. La bonne est une contrainte d’architecture : « nos lecteurs sont Trino et Snowflake, donc Iceberg ; nos data engineers sont sur Databricks et Unity, donc Delta ; notre CDC est le produit, donc on prototype Hudi MoR contre Iceberg Flink. »

La relance : « et le format des fichiers ? » Parquet, presque toujours. ORC/Avro sont des options Iceberg, rarement le différenciateur. Ce qui diffère, ce sont les métadonnées de table (manifestes Iceberg, _delta_log, timeline Hudi).

Le piège

Choisir Hudi « parce que upsert » pour une table append-only de logs. Ou choisir Delta et promettre Athena en lecture native sans avoir vérifié le pont réel (convert, UniForm, copie). Ou empiler deux formats de table sur le même dossier « pour plus tard ». Un préfixe, un protocole.

Dernière phrase utile : vous choisissez un protocole de table et un catalog, pas une extension de fichier.