Présentation d'Apache Iceberg

Apache Iceberg est un format de table ouvert pour les grands jeux de données analytiques stockés sur des systèmes de fichiers distribués. Il apporte la fiabilité des bases de données — transactions ACID, évolution de schéma, voyage dans le temps et évolution des partitions — aux données résidant dans HDFS, Ozone ou un stockage objet, tout en restant lisible par plusieurs moteurs simultanément. ODP 1.3.1.0 intègre Iceberg 1.6.1.

Qu'est-ce qu'Iceberg ?

Iceberg définit comment les fichiers de données (Parquet, ORC, Avro) et leurs métadonnées sont organisés sur un système de fichiers. Plutôt que de s'appuyer sur des conventions de nommage de répertoires et un Metastore central pour suivre les partitions (comme le font les tables Hive traditionnelles), Iceberg stocke un arbre de métadonnées autonome aux côtés des données :

table/
├── metadata/
│   ├── v1.metadata.json        ← historique des snapshots, schéma, spécification de partition
│   ├── snap-*.avro             ← listes de manifestes (pointeurs vers les fichiers manifestes)
│   └── manifests/
│       └── *.avro              ← fichiers manifestes (listes des fichiers de données + statistiques)
└── data/
    └── *.parquet               ← fichiers de données réels

Cette architecture permet des opérations de table atomiques et cohérentes sans nécessiter de verrou sur le Metastore, et permet à tout moteur disposant d'un lecteur Iceberg d'interroger correctement la table sans coordination.

Pourquoi Iceberg plutôt que les tables Hive traditionnelles ?

Capacité	Tables partitionnées Hive	Iceberg
Transactions ACID	ORC uniquement, limitées	Tous formats, ACID complet
Évolution de schéma	Limitée (ajout de colonnes uniquement)	Ajout, suppression, renommage, réordonnancement, élargissement de types
Évolution des partitions	Nécessite une réécriture complète	Ajout/modification sans réécriture des données
Partitionnement masqué	Non (partition dans la requête)	Oui (transparent pour les requêtes)
Voyage dans le temps	Non	Oui (interrogation de n'importe quel snapshot)
Écrivains concurrents	Non	Contrôle de concurrence optimiste
Suppressions au niveau des lignes	ORC ACID uniquement	Suppressions positionnelles et par égalité (tous formats)
Lectures multi-moteurs	Limitées	Natif (Hive, Spark, Impala, Trino)

Transactions ACID

Iceberg utilise le contrôle de concurrence optimiste : chaque opération d'écriture lit le snapshot courant, effectue les modifications et valide un nouveau snapshot de façon atomique. Si deux écrivains entrent en conflit (tous deux modifient les mêmes lignes), l'une des validations échoue et doit être relancée. Cela garantit un isolement sérialisable pour les opérations INSERT, UPDATE, DELETE et MERGE sans nécessiter un gestionnaire de verrous central.

Évolution de schéma

Iceberg suit les modifications de schéma dans les métadonnées en utilisant des identifiants de champ plutôt que des indices de colonnes positionnels. Cela signifie :

• L'ajout d'une colonne ne nécessite pas de réécriture des fichiers de données existants.
• La suppression d'une colonne est enregistrée dans les métadonnées ; les fichiers existants contiennent toujours les données de la colonne supprimée mais les lecteurs les ignorent.
• Le renommage d'une colonne est une opération purement sur les métadonnées — les fichiers de données restent inchangés.
• L'élargissement d'un type (par exemple INT vers LONG) est sûr et rétrocompatible.

Voyage dans le temps et rollback

Chaque écriture dans une table Iceberg crée un nouveau snapshot. Les anciens snapshots sont conservés jusqu'à leur expiration explicite, permettant :

-- Interroger la table telle qu'elle était le 1er janvier 2025
SELECT * FROM events FOR SYSTEM_TIME AS OF '2025-01-01 00:00:00';

-- Interroger un snapshot spécifique
SELECT * FROM events FOR VERSION AS OF 8462937;

Le voyage dans le temps est utile pour l'audit des données, le débogage des erreurs de pipeline et la reproduction des jeux de données d'entraînement ML à un instant précis. Le rollback restaure la table à un snapshot précédent sans suppression de données.

Évolution des partitions et partitionnement masqué

Les tables Hive traditionnelles intègrent les valeurs de partition dans les noms de répertoires (dt=2025-01-01/), obligeant les auteurs de requêtes à spécifier explicitement les prédicats de partition. Iceberg sépare la spécification de partition de la disposition physique des données :

• Partitionnement masqué : Iceberg dérive les valeurs de partition à partir de transformations de colonnes (bucket(user_id, 16), truncate(event_date, month)) de façon transparente. Les auteurs de requêtes filtrent sur event_date = '2025-01-01' sans connaître le schéma de partitionnement physique.
• Évolution des partitions : à mesure que les données croissent, le schéma de partitionnement peut être modifié (par exemple, de mensuel à quotidien) sans réécrire les données historiques. Les nouvelles données utilisent le nouveau schéma ; les anciennes données restent sur l'ancien schéma. Les lecteurs gèrent les deux de façon transparente.

Iceberg 1.6.1 dans ODP 1.3.1.0

ODP intègre Iceberg comme format de table de premier plan dans toute la pile :

• Hive 4.0.1 : support natif du catalogue Iceberg via le gestionnaire de stockage StoredByIceberg. Les opérations DDL Hive (CREATE TABLE, ALTER TABLE, DROP TABLE) fonctionnent sur les tables Iceberg de façon identique aux tables Hive natives.
• Spark 3.5.6 : Iceberg Spark Runtime inclus. Support complet en lecture/écriture, y compris le voyage dans le temps, l'évolution de schéma et les écritures en streaming.
• Impala 4.5.0 : support en lecture pour les tables Iceberg v2 (suppressions par égalité, suppressions positionnelles).
• Trino 476 : connecteur Iceberg complet avec support lecture/écriture et voyage dans le temps.

Cela signifie qu'un jeu de données écrit par un pipeline Spark est immédiatement interrogeable par Hive, Impala et Trino — avec des garanties ACID cohérentes — sans conversion de format ni copie de données.

Architecture Lakehouse multi-moteurs

La combinaison des métadonnées agnostiques d'Iceberg et de l'intégration multi-moteurs d'ODP permet une véritable architecture lakehouse :

Ingestion NiFi ──► Kafka ──► Spark Streaming ──► Table Iceberg sur HDFS
                                                        │
                    ┌───────────────────────────────────┤
                    │                                   │
              Hive (ETL batch)              Impala (tableaux de bord BI)
              Spark (entraînement ML)       Trino (requêtes fédérées)

Tous les moteurs partagent les mêmes fichiers de données physiques et le même snapshot de métadonnées, éliminant les problèmes de cohérence qui surviennent lorsque les données sont copiées entre systèmes.

Catalogue REST Polaris (à venir dans ODP 1.3.2.0)

ODP 1.3.1.0 utilise le Hive Metastore comme catalogue Iceberg (les tables sont enregistrées dans le HMS). ODP 1.3.2.0 introduira Apache Polaris en aperçu technologique : un catalogue Iceberg basé sur REST qui implémente la spécification du catalogue REST Iceberg.

Le catalogue REST Polaris offre :

• Une API HTTP standard pour les opérations de catalogue (créer/lister/supprimer des espaces de noms et des tables)
• Un contrôle d'accès fin au niveau du catalogue et des espaces de noms
• La prise en charge de plusieurs emplacements d'entrepôt
• La compatibilité avec tout moteur capable de lire Iceberg qui implémente la spécification du catalogue REST

Cas d'usage

Data Lakehouse

Iceberg est le fondement du pattern lakehouse dans ODP : HDFS fournit un stockage évolutif et économique ; Iceberg apporte la couche de fiabilité et de performance de requête qui nécessitait traditionnellement un entrepôt de données. Les équipes peuvent exécuter des analyses SQL directement sur le lac de données sans pipelines ETL vers un système d'entrepôt séparé.

Jeux de données d'entraînement ML

La reproductibilité est une exigence fondamentale pour un ML responsable. La capacité de voyage dans le temps d'Iceberg permet aux data scientists de capturer un instantané d'un jeu de données d'entraînement à un moment précis, garantissant que le jeu de données exact utilisé pour entraîner un modèle peut être reproduit pour le débogage, le ré-entraînement ou la revue réglementaire — même après que les données sous-jacentes ont été mises à jour.

Pistes d'audit via le voyage dans le temps

Les cas d'usage de conformité nécessitent souvent de répondre à des questions sur l'état historique des données : "À quoi ressemblait cet enregistrement à une date précise ?" ou "Qui a modifié cet enregistrement et quand ?". Avec Iceberg, ces questions peuvent recevoir une réponse en interrogeant des snapshots passés sans maintenir une table d'audit séparée.