340 % de croissance d’adoption en deux ans. C’est le chiffre que DB-Engines attribue aux formats de table ouverts (OTF) dans son rapport de juin 2026. Apache Iceberg, Delta Lake et Apache Hudi ne sont plus des projets expérimentaux : ils sont devenus le socle sur lequel reposent les architectures lakehouse d’Airbnb, Netflix, Uber, Apple et des milliers d’entreprises. Mais, concrètement, lequel choisir — et pourquoi maintenant ? Décryptage.

Pourquoi les formats de table ouverts explosent en 2026

Pendant des années, le choix était binaire : le data warehouse (Snowflake, BigQuery, Redshift) pour la performance analytique, ou le data lake (S3, HDFS) pour la flexibilité et le coût. Les formats de table ouverts abolissent cette frontière en apportant les propriétés ACID, le versioning, le time travel et le partitionnement avancé directement sur des fichiers Parquet/ORC stockés dans un lac de données.

En 2026, trois projets dominent le paysage :

  • Apache Iceberg — incubé par Netflix, adopté par Apple, Snowflake, AWS, Google BigQuery, Dremio, Tabular (racheté par Databricks en 2024)
  • Delta Lake — créé par Databricks, open-source sous Linux Foundation depuis 2022, moteur du lakehouse Databricks
  • Apache Hudi — né chez Uber, taillé pour l’ingestion incrémentale et les cas d’usage streaming

Tableau comparatif : les fondamentaux

Critère Apache Iceberg Delta Lake Apache Hudi
Création Netflix, 2017 Databricks, 2019 Uber, 2016
Gouvernance Apache Software Foundation Linux Foundation Apache Software Foundation
Version OSS actuelle Iceberg 1.7 (mars 2026) Delta 4.0 (avril 2026) Hudi 1.0 (janvier 2026)
Format de fichier Parquet, ORC, Avro Parquet (principal) Parquet, ORC, HFile
Mécanisme de commit Optimistic concurrency via catalog Optimistic concurrency via transaction log Optimistic concurrency via timeline
Time Travel ✅ Par snapshot ID ou timestamp ✅ Par version ou timestamp ✅ Par instant time
Partitionnement Hidden partitioning (automatique) Generated columns + partitioning Multi-level, clustering
Moteurs supportés Spark, Flink, Trino, Presto, Dremio, Snowflake, BigQuery, Athena, DuckDB Spark, Flink, Trino, Presto, Dremio, Hive Spark, Flink, Presto, Trino, Hive
Compaction automatique ✅ Via rewrite_data_files ✅ OPTIMIZE command ✅ Nativement intégré (clustering + cleaner)
Upserts / CDC ✅ MERGE INTO (Iceberg 1.4+) ✅ MERGE INTO (performant) ✅ Nativement, excellente perf

Iceberg : l’interopérabilité comme arme absolue

Apache Iceberg a joué une carte maîtresse : être le format pivot que tout le monde supporte. En 2026, Snowflake a annoncé le support natif d’Iceberg en lecture/écriture via son catalogue Polaris. Google BigQuery a suivi avec BigLake. AWS propose Iceberg comme format par défaut pour Athena et Glue. Même Databricks — après avoir racheté Tabular (la société derrière Iceberg) — supporte Iceberg en lecture via Unity Catalog.

Le hidden partitioning d’Iceberg est probablement sa killer feature la plus sous-estimée : vous écrivez WHERE event_date = '2026-06-05' et Iceberg résout automatiquement la partition, sans que vous ayez à connaître le schéma de partitionnement physique. Plus besoin de WHERE year=2026 AND month=6 AND day=5 — le moteur s’en charge.

-- Iceberg : partitionnement invisible pour l'utilisateur
CREATE TABLE logs.events (
  event_id    BIGINT,
  event_type  STRING,
  event_date  DATE,
  payload     STRING
) USING iceberg
PARTITIONED BY (months(event_date));  -- Partitionnement déclaratif

-- La requête suivante utilise automatiquement le partitionnement
SELECT COUNT(*) FROM logs.events
WHERE event_date = DATE '2026-06-05';
-- Iceberg lit UNIQUEMENT la partition concernée

Quand choisir Iceberg

  • Vous utilisez plusieurs moteurs (Spark + Trino + Snowflake + DuckDB)
  • Vous voulez éviter le vendor lock-in à tout prix
  • Vos données sont principalement analytiques (batch, rapports, dashboards)
  • Vous êtes dans un écosystème multi-cloud

Delta Lake : l’écosystème Databricks, et bien plus

Delta Lake 4.0, publié en avril 2026, a introduit Liquid Clustering — une alternative au partitionnement traditionnel qui adapte automatiquement la distribution des données en fonction des patterns de requêtes, sans maintenance manuelle. Couplé à Delta Sharing (protocole ouvert de partage de données entre organisations), Delta Lake se positionne comme la colonne vertébrale de l’écosystème Databricks — mais aussi comme un standard à part entière.

La force de Delta Lake, c’est son transaction log (le _delta_log) qui enregistre chaque opération de manière ordonnée et rejouable. Cela permet un time travel granulaire, des rollbacks instantanés, et une cohérence garantie même en cas d’écritures concurrentes.

-- Delta Lake : Time Travel et Liquid Clustering
CREATE TABLE sales.transactions
CLUSTER BY (customer_id, transaction_date)  -- Liquid Clustering
AS SELECT * FROM parquet.`s3://raw/transactions/`;

-- Optimisation automatique
OPTIMIZE sales.transactions;

-- Time travel : revenir 3 versions en arrière
SELECT * FROM sales.transactions
VERSION AS OF 42;

-- Restaurer une version précédente
RESTORE TABLE sales.transactions TO VERSION AS OF 42;

Quand choisir Delta Lake

  • Vous êtes dans l’écosystème Databricks (Unity Catalog, MLflow, Delta Sharing)
  • Vous avez besoin du Liquid Clustering pour des données à forte cardinalité
  • Le data sharing entre organisations est critique dans votre usage
  • Vous combinez analyse SQL et machine learning sur les mêmes données

Apache Hudi : le roi du streaming et des upserts

Si Iceberg et Delta Lake excellent en analytique batch, Apache Hudi est imbattable sur les cas d’usage temps réel. Conçu chez Uber pour ingérer des milliards d’événements de courses par jour avec des upserts (mises à jour incrémentales), Hudi 1.0 a atteint une maturité remarquable en 2026.

La spécificité de Hudi, c’est son timeline — un journal horodaté de toutes les actions effectuées sur la table — et ses deux modes d’écriture : Copy-on-Write (CoW) pour les lectures rapides, et Merge-on-Read (MoR) pour les écritures rapides. Les index Hudi (Bloom, Bucket, Simple) permettent de localiser les enregistrements à mettre à jour sans scanner toute la table.

# Apache Hudi : ingestion streaming avec upserts en Python (PySpark)
from pyspark.sql import SparkSession

spark = SparkSession.builder 
    .config("spark.serializer", "org.apache.spark.serializer.KryoSerializer") 
    .getOrCreate()

# Lecture d'un flux Kafka
df = spark.readStream 
    .format("kafka") 
    .option("kafka.bootstrap.servers", "kafka:9092") 
    .option("subscribe", "orders") 
    .load()

# Écriture en continu vers Hudi avec upserts
hudi_options = {
    'hoodie.table.name': 'orders',
    'hoodie.datasource.write.recordkey.field': 'order_id',
    'hoodie.datasource.write.precombine.field': 'event_ts',
    'hoodie.datasource.write.operation': 'upsert',
    'hoodie.datasource.write.table.type': 'MERGE_ON_READ',
    'hoodie.cleaner.commits.retained': 10,
}

df.writeStream 
    .format("hudi") 
    .options(**hudi_options) 
    .option("checkpointLocation", "s3://checkpoints/orders/") 
    .start("s3://datalake/orders/") 
    .awaitTermination()

Quand choisir Hudi

  • Votre workload est fortement streaming (Kafka, Kinesis, Pulsar)
  • Vous avez besoin d’upserts massifs (millions d’enregistrements modifiés par heure)
  • La latence entre ingestion et disponibilité est critique (< 1 minute)
  • Vous gérez des pipelines CDC (Change Data Capture) depuis des bases transactionnelles

Le verdict : quel format choisir en 2026 ?

La bonne nouvelle, c’est que ces trois formats convergent. Iceberg améliore ses upserts (MERGE INTO en 1.4+), Delta Lake se dote de capacités streaming (Delta Live Tables), et Hudi muscle son interopérabilité (support Trino, Presto, Flink). La guerre n’est pas un jeu à somme nulle : de nombreuses entreprises utilisent deux formats en parallèle selon les cas d’usage.

Voici un arbre de décision pragmatique :

  1. Vous priorisez l’interopérabilité et le multi-moteur → Apache Iceberg
  2. Vous êtes dans l’écosystème Databricks et faites du ML → Delta Lake
  3. Votre cœur de métier, c’est le streaming avec upserts → Apache Hudi
  4. Vous démarrez un nouveau projet sans contrainte forte → Iceberg (le plus universel)

Ce qui est certain, c’est que le format de table ouvert est devenu la nouvelle norme — au même titre que Parquet a remplacé le CSV il y a dix ans. La question n’est plus « faut-il en adopter un ? » mais « lequel — ou lesquels — pour quel usage ? ».

Sources et références

📖 À lire aussi : Pipeline ETL Python avec Polars et PostgreSQL : le guide complet en 30 minutes

W
WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.