Formats de table ouverts expliqués : Iceberg vs Delta vs Hudi

Les formats de table ouverts sont des couches de métadonnées qui se superposent aux fichiers de données dans le stockage objet, apportant les transactions ACID, l'évolution des schémas et le voyage dans le temps (time travel) aux données stockées dans un lac de données. Apache Iceberg, Delta Lake et Apache Hudi sont les trois principaux formats de table ouverts utilisés en production aujourd'hui. Chacun d'eux transforme une collection de fichiers Parquet ou ORC en une table qui se comporte comme une base de données : les lecteurs obtiennent des résultats cohérents, les rédacteurs peuvent mettre à jour et supprimer des lignes en toute sécurité, et chaque modification est suivie afin que les versions antérieures restent interrogeables.

Cet aperçu explique le fonctionnement des principaux formats de table ouverts, compare leur prise en charge des transactions ACID et de l'évolution des schémas, et détaille leur lien avec l'architecture de lakehouse de données — en s'appuyant sur les innovations de la couche de stockage telles que les validations coordonnées par catalogue, le lignage des lignes (row lineage) et les métadonnées unifiées pour montrer où Delta Lake et Apache Iceberg convergent.

Qu'est-ce qu'un lac de données et pourquoi les formats de table ouverts sont-ils importants ?

Un lac de données est un référentiel centralisé basé sur un stockage objet économique — Amazon S3, Azure Data Lake Storage ou Google Cloud Storage — qui conserve des données structurées, semi-structurées et non structurées sous leur forme brute d'origine. Les entreprises ont adopté les lacs de données car le stockage objet offre une mise à l'échelle économique et sépare le stockage du calcul, permettant à n'importe quel moteur de requête de lire les mêmes données. Cependant, le stockage objet n'a jamais été conçu pour garantir la cohérence : il ne possède aucun concept natif de table, de schéma ou de transaction.

Un lakehouse de données superpose une structure de type table, de la gouvernance et des performances à ce stockage brut, combinant le faible coût d'un lac de données avec la fiabilité d'un entrepôt de données (data warehouse). Le pont entre les deux est le format de table ouvert : il transforme des fichiers isolés du stockage objet en tables gouvernées et interrogeables, sans copier les données dans un entrepôt propriétaire.

Avant l'apparition des formats de table ouverts, l'exécution d'analyses sur des lacs de données traditionnels posait des problèmes persistants : des écritures simultanées pouvaient corrompre les données en cours d'écriture, les mises à jour et les suppressions nécessitaient de réécrire des partitions entières, et il n'existait aucun moyen fiable de savoir quels fichiers représentaient l'état actuel et correct d'une table. Les formats de table ouverts gèrent les métadonnées des fichiers de données dans le stockage objet, en suivant précisément quels fichiers appartiennent à une table — une standardisation qui a enfin permis aux lacs de données de prendre en charge des fonctionnalités de type base de données, comme les mises à jour au niveau de l'enregistrement.

Les formats de table et de fichier ouverts que vous devez connaître

Apache Iceberg

Apache Iceberg, développé à l'origine chez Netflix et aujourd'hui projet de la Apache Software Foundation, a été conçu pour rendre les tables volumineuses et à évolution lente rapides à interroger et sûres à faire évoluer. Apache Iceberg utilise une structure en arbre pour une gestion efficace des métadonnées : des fichiers manifestes (manifest files) et des listes de manifestes (manifest lists) suivent chaque fichier de données d'une table, permettant aux moteurs de requête d'exclure les données non pertinentes avant le début d'un scan. Les tables Iceberg prennent en charge l'évolution des schémas et des partitions sans réécriture des fichiers sous-jacents.

Delta Lake

Delta Lake, créé par Databricks et publié en open source, a apporté les transactions ACID aux charges de travail Apache Spark grâce à un journal de transactions d'écriture anticipée (write-ahead transaction log). Delta Lake est né chez Databricks et s'intègre nativement à Spark, bien qu'il prenne désormais en charge un large éventail de moteurs via des connecteurs indépendants. Les tables Delta Lake enregistrent chaque écriture sous la forme d'une entrée de journal ordonnée et atomique, offrant aux lecteurs une vue cohérente même pendant l'écriture de nouvelles données.

Apache Hudi

Apache Hudi, court pour Hadoop Upserts Deletes and Incrementals, est conçu pour des mises à jour rapides et fréquentes au niveau de l'enregistrement. Apache Hudi optimise les mises à jour fréquentes et les données en streaming en maintenant des index qui localisent le fichier exact contenant un enregistrement donné, permettant des mises à jour efficaces au niveau de l'enregistrement sans scan complet de la table. Cette conception fait de Hudi un choix courant pour les pipelines de capture de données modifiées (CDC) et l'ingestion en quasi-temps réel.

Parquet et ORC

Parquet et ORC sont des formats de fichiers colonnaires, et non des formats de tables : ils définissent l'organisation des fichiers de données individuels, et non la manière dont ces fichiers forment une table gouvernée. Iceberg, Delta Lake et Hudi reposent tous sur des fichiers Parquet — Iceberg et Hudi prennent également en charge ORC — en utilisant les statistiques au niveau du fichier stockées par Parquet pour élaguer les données avant qu'un moteur de requête ne les lise. Cette distinction entre format de fichier et format de table dissipe la plupart des confusions au sein des entreprises quant aux limites de responsabilité de chaque couche.

Iceberg vs Delta Lake vs Hudi : comparaison rapide

Les trois principaux formats de table ouverts partagent désormais plus de fonctionnalités qu'ils n'en diffèrent, mais le tableau ci-dessous met en évidence les aspects où l'historique de leur conception reste visible.

Au cœur d'Apache Iceberg : tables et métadonnées

L'arbre de métadonnées d'Iceberg

Une table Iceberg est définie par un arbre de métadonnées, et non par un fichier unique : un fichier de métadonnées pointe vers une liste de manifestes, qui pointe à son tour vers des fichiers manifestes répertoriant les fichiers de données réels qui composent un instantané (snapshot). Cette structure en couches permet à un moteur de requête d'élaguer les manifestes et les fichiers de données non pertinents à l'aide des statistiques de colonnes stockées sans ouvrir un seul fichier, ce qui améliore les performances des requêtes sur les tables contenant des millions de fichiers.

Instantanés (snapshots) et voyage dans le temps (time travel)

Chaque écriture dans une table Iceberg crée un nouvel instantané (snapshot) — un enregistrement immuable des fichiers de données existants à ce moment précis — et l'arbre de métadonnées conserve l'historique des instantanés précédents. Cela permet le voyage dans le temps (time travel) : les moteurs peuvent interroger une table telle qu'elle existait à un ID d'instantané ou à un horodatage spécifique, facilitant l'audit, les ensembles d'entraînement ML reproductibles et le retour au dernier état stable après une mauvaise écriture.

Évolution des partitions

Iceberg dissocie le partitionnement physique d'une table de ses modèles de requête grâce à l'évolution des partitions, permettant aux équipes de modifier le partitionnement des nouvelles données sans réécrire les fichiers existants ni perturber les requêtes basées sur l'ancien schéma. Le partitionnement masqué (hidden partitioning) signifie que les analystes n'ont pas besoin de référencer directement les colonnes de partition physique pour bénéficier de l'élagage des partitions.

Fonctionnement interne et maintenance des tables Iceberg

Puisque chaque écriture produit un nouvel instantané avec sa propre liste de manifestes, une table Iceberg activement mise à jour peut accumuler des milliers de petits fichiers de manifestes et de données si elle n'est pas gérée. Les moteurs de requête devant toujours ouvrir et évaluer chaque fichier manifeste pertinent, la prolifération des manifestes dégrade les gains de performance de requête que l'arbre de métadonnées était censé apporter.

Le remède standard est la compaction planifiée : une tâche de maintenance qui réécrit les petits fichiers de données en un nombre réduit de fichiers plus volumineux et consolide les manifestes, exécutée chaque nuit ou chaque heure selon le volume d'ingestion. Associer la compaction à l'expiration régulière des instantanés — en supprimant les métadonnées au-delà d'une fenêtre de rétention — permet de maîtriser la taille du stockage et des métadonnées sans limiter la portée historique du voyage dans le temps.

Delta Lake et les transactions ACID

Le journal des transactions de Delta Lake

Les tables Delta Lake stockent un journal des transactions ordonné et en ajout uniquement (append-only) — une séquence d'entrées JSON enregistrant chaque ajout, suppression et modification de métadonnées — ainsi que des fichiers de point de contrôle (checkpoint files) périodiques qui résument le journal pour des lectures plus rapides. Historiquement, le système de fichiers lui-même faisait office de coordinateur de validation (commit coordinator), ce qui signifie que tout client disposant d'un accès au niveau des fichiers pouvait écrire directement dans une table Delta, sans passer par un catalogue de gouvernance.

Le comportement des transactions ACID dans Delta Lake

Les transactions ACID garantissent la cohérence des données lors d'écritures simultanées en exigeant que chaque rédacteur vérifie la version actuelle du journal, génère une nouvelle entrée et ne la valide que si aucune modification conflictuelle n'est survenue entre-temps ; si un conflit est détecté, le rédacteur réessaie. La conformité ACID prévient la corruption des données car un lecteur ne voit jamais une table Delta Lake dans un état partiellement écrit, et les transactions ACID permettent des opérations de données complexes sans conflits sur des partitions qui se chevauchent.

De l'intégration native Spark à la prise en charge multi-moteur

Comme le modèle de validation d'origine de Delta Lake dépendait de l'accès au système de fichiers, les moteurs tiers en dehors d'Apache Spark devaient accéder aux tables via des chemins de fichiers statiques plutôt que par un catalogue de gouvernance — laissant ces accès non gouvernés et susceptibles de rompre silencieusement les relations de schéma. Databricks a résolu ce problème avec les validations par catalogue (catalog commits), un standard ouvert permettant à un catalogue tel que Unity Catalog de faire office de coordinateur de validation, de sorte que chaque demande de lecture, d'écriture et de découverte soit autorisée de manière centralisée. Les validations par catalogue sont désormais généralement disponibles, alignant Delta Lake sur l'approche orientée catalogue qu'Iceberg utilise depuis le début et débloquant les transactions multi-tables.

Principes fondamentaux des formats de fichiers : comment Parquet permet l'omission de données (data skipping)

Un fichier Parquet organise les données tabulaires par colonne plutôt que par ligne, en regroupant les valeurs d'une même colonne dans des blocs contigus appelés groupes de lignes (row groups). Le stockage en colonnes permet à un moteur de requête de lire uniquement les colonnes référencées par une requête, en ignorant le reste — une raison majeure pour laquelle Parquet surpasse les formats orientés lignes pour les charges de travail gourmandes en balayages (scans).

Chaque groupe de lignes contient des statistiques — valeurs minimales et maximales, nombre de valeurs nulles et distributions des valeurs par colonne — écrites dans le pied de page des métadonnées du fichier. Ces statistiques permettent à un moteur de déterminer, sans décompresser aucune donnée, si un groupe de lignes est susceptible de correspondre au filtre d'une requête.

Les formats de table ouverts étendent ce principe à un niveau supérieur : les fichiers manifestes d'Iceberg et le journal des transactions de Delta Lake mettent tous deux en cache les statistiques au niveau de Parquet dans la couche de métadonnées, de sorte qu'un moteur peut ignorer des fichiers de données entiers avant de les lister à partir du stockage d'objets. Ce saut de données à deux niveaux contribue grandement à l'amélioration des performances des requêtes sur les grandes tables. Databricks a également étendu le modèle avec le type de données Variant — qui fait désormais partie de Parquet, Delta Lake et Iceberg — en stockant des charges utiles semi-structurées sous forme binaire typée plutôt qu'en JSON brut, afin que les moteurs puissent extraire les champs imbriqués sans analyse coûteuse.

Versionnage des données, Time Travel et traitement incrémentiel

Le versionnage des données est la capacité d'un format de table ouvert à conserver un historique de chaque état précédent de la table plutôt que d'écraser les données sur place, et le Time Travel permet de lire n'importe laquelle de ces versions précédentes par numéro de version, ID de snapshot ou horodatage. Les formats de table ouverts permettent par conception le Time Travel et le versionnage des ensembles de données, car chaque écriture crée déjà un nouveau snapshot ou une nouvelle entrée de journal adressable indépendamment.

Le traitement incrémentiel lit uniquement les lignes qui ont changé depuis le dernier traitement d'une table plutôt que de rescanner un ensemble de données entier — c'est le modèle derrière la capture des changements de données (CDC), où les pipelines consomment uniquement les insertions, les mises à jour et les suppressions appliquées à une table source. Le lignage des lignes (row lineage) et les vecteurs de suppression (deletion vectors), introduits dans Delta Lake et apportés à Iceberg via Iceberg v3, ont rendu cela moins coûteux : le lignage des lignes suit quelles lignes ont changé depuis le dernier balayage d'une table, et les vecteurs de suppression représentent les lignes supprimées sous forme de bitmap compact au lieu de réécrire les fichiers de données.

Conserver indéfiniment chaque version historique coûte cher, c'est pourquoi les formats de table ouverts associent le versionnage à des politiques de rétention et à une opération de nettoyage (vacuum) ou d'expiration des snapshots qui supprime les données qui ne sont plus référencées dans la fenêtre de rétention. Exécuter vacuum de manière trop agressive peut interrompre les requêtes de Time Travel qui font encore référence à des versions plus anciennes, c'est pourquoi les fenêtres sont définies pour correspondre à la requête la plus longue qui pourrait en avoir besoin.

Une cadence raisonnable pour les tables de production associe le traitement incrémentiel à des intervalles adaptés à l'ingestion — souvent toutes les 5 à 15 minutes pour l'ingestion de données en continu (streaming) — avec un vacuum et une expiration des snapshots exécutés quotidiennement, en dehors des heures de pointe des requêtes.

Gestion des métadonnées et optimisation des performances

Les formats de table ouverts améliorent les performances des requêtes grâce à une gestion des métadonnées organisée en couches : les fichiers manifestes ou les entrées de journal décrivent les fichiers de données individuels, les snapshots ou les versions de journal décrivent l'état de la table à un instant donné, et un catalogue suit quelle version fait actuellement autorité. Unity Catalog gère aujourd'hui plus de 17 exaoctets de données dans des formats de table ouverts à travers les déploiements d'entreprises — ce qui donne une idée de la quantité de métadonnées qu'un catalogue de lakehouse moderne gère désormais.

À mesure que les tables grandissent, les fichiers manifestes et les points de contrôle (checkpoints) du journal des transactions peuvent eux-mêmes ralentir la planification des requêtes. La maintenance doit donc inclure la réécriture des manifestes dans des fichiers moins nombreux et plus volumineux, ainsi que l'ajustement des intervalles de points de contrôle en fonction de la fréquence d'écriture. Databricks et la communauté open-source développent une structure de métadonnées unifiée pour Delta Lake et Iceberg, prévue en version préliminaire (preview) au troisième trimestre, combinant le journal d'écriture rapide de Delta Lake avec l'arbre de manifestes de lecture rapide d'Iceberg.

La mise en cache des métadonnées — qui consiste à conserver en mémoire les manifestes, les points de contrôle ou les réponses de catalogue récemment consultés — réduit la latence des requêtes répétées en évitant un parcours complet de l'arborescence des métadonnées à chaque demande, ce qui est particulièrement important pour les charges de travail BI qui émettent de nombreuses petites requêtes sur les mêmes grandes tables.

Transactions ACID et contrôle de la concurrence

Apache Iceberg, Delta Lake et Apache Hudi garantissent tous une isolation sérialisable ou de snapshot pour les écritures sur une seule table, de sorte que les lecteurs simultanés voient toujours une version complète et cohérente, et jamais une écriture partielle. Là où ils diffèrent, c'est au niveau de la coordination : Iceberg a toujours utilisé le catalogue comme source unique de vérité, Hudi utilise son propre service de chronologie (timeline), et Delta Lake s'appuyait sur l'atomicité du système de fichiers avant que les validations (commits) de catalogue ne l'alignent sur le modèle coordonné par le catalogue.

Les trois formats utilisent un contrôle de concurrence optimiste : plutôt que de verrouiller une table avant d'écrire, un rédacteur lit la version actuelle, prépare sa modification et ne la valide (commit) que si aucun autre rédacteur n'a validé de modification conflictuelle entre-temps. Si un conflit est détecté, la transaction échoue en toute sécurité et soit réessaie par rapport à la version la plus récente, soit s'annule, ne laissant jamais la table dans un état incohérent.

Le moyen le plus efficace de réduire les conflits d'écriture consiste à réduire le chevauchement entre les rédacteurs simultanés : partitionnez les tâches d'ingestion afin que différents pipelines écrivent dans des partitions différentes, regroupez (batch) les petites écritures dans des validations (commits) moins nombreuses et plus volumineuses, et limitez les opérations de fusion (merge) aux seules partitions qu'elles touchent. Les validations de catalogue aident également ici, car les transactions multi-tables permettent de valider ensemble les mises à jour associées au lieu d'entrer en concurrence sous forme d'écritures distinctes provenant de plusieurs processus.

Choisir un format de table pour votre data lake

Apache Iceberg a tendance à mieux convenir là où l'accès en lecture multi-moteur est le plus important — les organisations qui interrogent les mêmes tables à partir de Trino, Snowflake, Flink et Spark côte à côte. Delta Lake convient mieux aux pipelines centrés sur Spark nécessitant des transactions multi-tables et une gouvernance fine. Apache Hudi convient mieux aux charges de travail d'insertion/mise à jour (upsert) à haute fréquence au niveau des enregistrements, telles que la réplication CDC, où son indexation sur mesure surpasse les opérations de fusion (merge) à usage général.

La compatibilité des moteurs doit être évaluée par rapport aux moteurs de requête déjà en production, et pas seulement par rapport à une liste de fonctionnalités — un format techniquement supérieur dépourvu de connecteur mature pour le moteur principal d'une équipe ajoute plus de risques qu'il n'en élimine. Delta Kernel, une bibliothèque open-source en Java et Rust, est devenue un moyen courant pour les moteurs d'ajouter le support de Delta Lake sans réimplémenter le protocole ; elle alimente déjà les intégrations DuckDB et ClickHouse, et les deux implémentations convergent vers un cœur Rust partagé.

Avant de standardiser sur un format, réalisez un proof of concept (PoC) sur une table de production représentative et modérément désordonnée : mesurez la latence d'écriture sous charge simultanée, confirmez que les moteurs cibles lisent le format de manière native plutôt qu'à travers un connecteur lent, et validez que l'évolution du schéma et le Time Travel se comportent comme prévu.

Interopérabilité, catalogues et considérations relatives aux fournisseurs

Options de catalogue et interopérabilité entre formats

Un catalogue est le système d'enregistrement qui suit quelles tables existent, où vivent leurs données et quel snapshot fait autorité — les options incluent le Hive Metastore d'origine, AWS Glue Data Catalog et Unity Catalog, qui régit ensemble les tables Delta Lake et Apache Iceberg sous un seul ensemble de politiques d'accès. Delta Lake UniForm va plus loin, en permettant à une seule copie des données Delta Lake d'être lue nativement comme une table Iceberg sans dupliquer le stockage, répondant ainsi au problème de dépendance vis-à-vis du format (format lock-in) qui pousse les équipes à retarder la standardisation.

Risques de dépendance vis-à-vis des fournisseurs (vendor lock-in) et comment les atténuer

Le moyen le plus clair d'atténuer le risque de dépendance vis-à-vis d'un fournisseur est de choisir un format disposant de plus d'une implémentation de moteur indépendante, et de confirmer que l'accès au catalogue — et pas seulement l'accès aux fichiers — est portable sur les plateformes dont une équipe pourrait avoir besoin plus tard. Parce qu'Iceberg et Delta Lake sont open-source, le stockage des données dans l'un ou l'autre ne verrouille pas en soi une organisation dans un seul moteur de traitement, bien que les couches de gouvernance construites par-dessus puissent varier en termes de portabilité.

Opérations, surveillance et bonnes pratiques

La maintenance des tables doit être codifiée sous forme de runbook, et non de tâche ad hoc : définissez quelles tables ont besoin d'une compaction et à quel seuil de taille de fichier, définissez des fenêtres de rétention pour le vacuum et l'expiration des snapshots en fonction de l'ancienneté des données interrogées par les tâches, et planifiez les deux en dehors des fenêtres de pointe des requêtes.

La surveillance de la santé des tables doit suivre le nombre de fichiers et la taille moyenne des fichiers par table, les taux d'échec des validations (commits) et l'âge du fichier de données le plus ancien par rapport à un calendrier de compaction, en alertant lorsque le nombre de petits fichiers ou les taux de conflit grimpent en flèche. Ces métriques permettent de détecter le gonflement des métadonnées et les conflits d'écriture avant qu'ils ne se manifestent sous forme de requêtes lentes.

Parce que les formats de table ouverts prennent en charge l'évolution du schéma sans interrompre les requêtes existantes, les modifications de schéma sont souvent appliquées directement aux tables de production — mais cette facilité permet d'ignorer facilement les tests. Les équipes doivent valider les modifications par rapport à des requêtes en aval représentatives et répéter périodiquement un retour (rollback) à un snapshot antérieur, afin que la récupération après une mauvaise modification soit une procédure maîtrisée, et non une première tentative sous pression.

Conclusion : Compromis des formats de table ouverts et prochaines étapes

Apache Iceberg, Delta Lake et Apache Hudi résolvent le même problème fondamental — apporter des transactions ACID, l'évolution des schémas et le Time Travel aux données stockées dans un stockage d'objets peu coûteux — grâce à des conceptions de métadonnées façonnées par leur point de départ : l'analyse multi-moteur pour Iceberg, les pipelines natifs Spark pour Delta Lake, et les insertions/mises à jour (upserts) à haute fréquence pour Hudi. Parquet reste le format de fichier commun sous-jacent à ces trois formats, et les innovations récentes — vecteurs de suppression, lignage des lignes, Variant et validations (commits) coordonnées par le catalogue — convergent entre les formats plutôt que de rester cloisonnées.

La prochaine étape pratique pour la plupart des équipes consiste à réaliser une preuve de concept ciblée : choisir le format correspondant à l'architecture de moteurs existante, le tester par rapport à des volumes réels de données de production, et confirmer que le catalogue qui le gère pourra s'étendre à un second format par la suite. Le stockage lakehouse ouvert et indépendant du format de Databricks permet aux équipes de stocker les données une seule fois et de les interroger nativement sous forme de Delta Lake ou d'Apache Iceberg, le tout géré sous un seul catalogue, sans dupliquer les données ni s'enfermer dans un format unique.

Questions fréquentes sur les formats de table ouverts

Qu'est-ce qu'un format de table ouvert ?

Un format de table ouvert est une couche de métadonnées open source qui se superpose aux fichiers de données dans le stockage d'objets et ajoute des fonctionnalités de type base de données — transactions ACID, évolution de schéma et voyage dans le temps — à un lac de données. Apache Iceberg, Delta Lake et Apache Hudi sont les trois principaux formats de table ouverts utilisés en production, et chacun transforme une collection de fichiers Parquet ou ORC en une table que tout moteur pris en charge peut lire et écrire en toute sécurité.

Quelle est la différence entre un format de table et un format de fichier ?

Un format de fichier tel que Parquet ou ORC définit la manière dont un fichier de données individuel est compressé et organisé sur le disque, tandis qu'un format de table tel qu'Apache Iceberg ou Delta Lake définit comment plusieurs de ces fichiers forment ensemble une table cohérente et interrogeable. Les formats de table ouverts sont construits sur des formats de fichiers, ajoutant la couche de métadonnées — manifestes, journaux de transactions et catalogues — que les formats de fichiers seuls ne fournissent pas.

Les tables Delta Lake et Apache Iceberg peuvent-elles fonctionner ensemble ?

Oui. Delta Lake UniForm permet de lire nativement une copie unique de données de table Delta Lake sous forme de table Apache Iceberg sans dupliquer le stockage, et des catalogues tels que Unity Catalog peuvent régir les deux formats côte à côte selon un ensemble unique de politiques d'accès. Cette interopérabilité permet aux organisations de standardiser leur gouvernance partagée sans contraindre chaque moteur à utiliser le même format de table.

Quel format de table ouvert dois-je choisir ?

Le meilleur format de table ouvert dépend des moteurs de requête et de la charge de travail déjà en production : Apache Iceberg convient aux analyses multi-moteurs sur des outils comme Trino et Snowflake, Delta Lake convient aux pipelines centrés sur Spark nécessitant des transactions multi-tables, et Apache Hudi convient aux charges de travail d'upsert à haute fréquence au niveau des enregistrements, telles que la réplication CDC. Une preuve de concept sur des données de production réelles permet de confirmer le choix le plus adapté.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original