Apache Hudi vs Apache Iceberg : Quel Format de Table pour l'Ingestion Streaming Kafka ?

Introduction

Dans les architectures data modernes, le choix du format de table lakehouse est une décision structurante. Pour les équipes qui traitent des flux Kafka en temps réel, ce choix peut faire la différence entre une latence de quelques secondes et… plusieurs heures d'attente.

Cet article présente une analyse comparative entre Apache Hudi et Apache Iceberg dans le cadre d'un benchmarking — et explique pourquoi les deux solutions ne jouent pas dans la même cour lorsqu'il s'agit de données en mouvement.

Le Use Case : Streaming Haute Fréquence depuis Kafka

Le contexte est le suivant :

• Source : Topics Apache Kafka avec ingestion continue de données transactionnelles
• Fréquence : Milliers d'événements par seconde
• Opérations : Inserts, Updates, Deletes (upserts) avec déduplication
• Latence cible : Sub-minute pour la disponibilité des données

Ce type de workload est exigeant. Il ne suffit pas de stocker des données — il faut les rendre disponibles, cohérentes, et dédupliquées, en temps quasi réel.

Deux Architectures, Deux Philosophies

Apache Hudi : né pour le streaming

Créé en 2016 chez Uber pour résoudre des problèmes de latence d'ingestion, Apache Hudi est conçu dès l'origine pour les workloads temps réel. Son architecture repose sur trois piliers :

Log-Structured Storage — Les données sont écrites dans des base files (Parquet) complétés par des delta logs (Avro). Cette séparation permet des écritures rapides sans réécriture complète des fichiers.

DeltaStreamer — Un utilitaire d'ingestion natif qui s'intègre directement avec Kafka, Debezium, AWS DMS, JDBC et S3 Events. Une seule commande suffit pour démarrer un pipeline d'ingestion avec exactly-once semantics.

Record-Level Indexing — Des indexes Bloom, hash et range permettent de localiser les enregistrements existants sans scanner l'ensemble du dataset, rendant les upserts jusqu'à 10x plus rapides qu'une approche classique via Spark join.

Hudi propose deux modes de table adaptés à différents profils de charge : Copy-On-Write (CoW) pour les workloads read-heavy, et Merge-On-Read (MoR) pour minimiser le write amplification dans les workloads write-heavy.

Apache Iceberg : né pour l'analytique batch

Développé par Netflix, Apache Iceberg répond à des problématiques différentes : l'évolution de schéma sans interruption, les transactions ACID à grande échelle, et la compatibilité multi-engine. Sa structure repose sur un arbre de métadonnées à trois niveaux qui excelle pour les scans analytiques massifs.

Mais pour le streaming ? Iceberg révèle ses limites :

• Pas d'utilitaire d'ingestion natif : il faut passer par Spark Streaming ou Flink, ce qui implique du code custom et une complexité opérationnelle accrue.
• Upserts coûteux : les mises à jour nécessitent la réécriture des fichiers complets, dégradant les performances sous charge élevée de mutations.
• Latence structurelle : les patterns naturels d'Iceberg conduisent à des latences de 5 à 15 minutes, loin de la cible sub-minute.

Les Chiffres : Ce que Disent les Benchmarks

Sources : données de production Uber, Zoom, Robinhood, Peloton.

Trois Cas Réels qui Parlent d'Eux-Mêmes

Robinhood — CDC avec Kafka

Robinhood avait besoin de passer ses pipelines batch de cadence quotidienne à sub-horaire pour garantir la fraîcheur des données de son data lake. Avec Hudi et DeltaStreamer, l'ingestion incrémentale des changelogs Kafka est devenue opérationnelle avec exactly-once semantics et support CDC natif, sans réécriture de pipeline.

Zoom — Ingestion de logs à très grande échelle

Zoom ingère 150 millions de messages Kafka toutes les 5 minutes (chacun contenant 7 à 25 enregistrements), avec une contrainte GDPR forte : pouvoir supprimer des enregistrements rapidement. Déployé sur Amazon EMR, Hudi ramène la latence des suppressions de plusieurs heures à 1–2 minutes pour 1 000 enregistrements sur un milliard de lignes.

Peloton — Réduction de latence end-to-end

La transition de Peloton vers Apache Hudi a produit trois résultats mesurables :

• Fréquence d'ingestion : de quotidienne à toutes les 10 minutes
• Durée des snapshot jobs : de 1 heure à moins de 15 minutes
• Réduction de latence globale : 75%

Complexité Opérationnelle : Un Critère Souvent Sous-Estimé

Hudi est un système qui se gère en grande partie lui-même pour les workloads streaming : compaction automatique, clustering, et monitoring intégré limitent la charge opérationnelle des équipes data.

Quand Choisir l'Un ou l'Autre ?

Choisissez Apache Hudi si vous avez besoin de :

• Streaming haute fréquence depuis Kafka avec latence sub-minute
• CDC natif (Debezium, AWS DMS, MongoDB)
• Upserts/Deletes fréquents
• Simplicité opérationnelle et mise en production rapide

Choisissez Apache Iceberg si vous avez besoin de :

• Workloads batch analytiques sans contrainte de latence forte
• Append-only (logs, événements sans mises à jour)
• Compatibilité multi-engine stricte (Spark, Flink, Trino…)
• Partition evolution et indépendance maximale vis-à-vis des vendors

Conclusion

Pour un use case d'ingestion streaming en temps réel depuis Kafka, Apache Hudi s'impose comme la solution techniquement supérieure. Sa conception streaming-first, son DeltaStreamer natif, ses indexes record-level et ses preuves en production chez des acteurs majeurs (Uber, Robinhood, Zoom, Peloton) en font le choix naturel pour des pipelines nécessitant latence minimale et mutations fréquentes.

Apache Iceberg reste une excellente technologie — mais pour des workloads analytiques batch et append-only, pas pour du streaming Kafka à haute fréquence.

Références

• Apache Hudi Documentation
• Apache Iceberg Documentation
• Onehouse — Lakehouse Feature Comparison
• Uber Blog — Apache Hudi
• AWS Blog — Zoom Streaming Log Ingestion
• Medium — Comparative Analysis Hudi vs Iceberg vs Delta
• Apache Hudi Blog — 21 Unique Differentiators