S3 Tables adopte Apache Iceberg V3 et ses types variant, géométrie et vecteurs de suppression
Le 30 septembre 2026, Amazon S3 Tables prend en charge tous les types de données de la spécification Apache Iceberg V3, des vecteurs de suppression au type variant en passant par la géométrie et le row lineage. Les tables V2 se migrent atomiquement, mais seuls les moteurs basés sur Spark 4.0 et le format Parquet exploitent les nouveaux types.
30 septembre 2026. Amazon S3 Tables annonce la prise en charge de tous les types de données de la spécification Apache Iceberg V3. Vecteurs de suppression, row lineage, type variant, géométrie, géographie, horodatage à la nanoseconde : tout devient natif, et les tables V2 se migrent atomiquement vers V3. Apache Spark 4.0. C’est le prérequis moteur pour exploiter les nouveaux types, qui restent limités au format Parquet. Pourquoi c’est important : une requête de conformité qui supprime 50 000 lignes d’une table de deux milliards n’écrit plus des milliers de petits fichiers de delete, et le semi-structuré cesse d’être une chaîne JSON à reparser à chaque requête.
Ce que V2 laissait en plan
Apache Iceberg est devenu le standard ouvert de la gestion des grands jeux de données analytiques : tables à l’échelle du pétaoctet, évolution de schéma, partitionnement caché, time travel, le tout sur des fichiers Parquet stockés dans un lac de données objet. S3 Tables est la couche de stockage qu’AWS a bâtie pour rendre ces tables performantes et économiques à mesure qu’elles grossissent, avec la compaction, la maintenance, la réplication et le tiering automatisés.
Mais les équipes qui tournent sur Iceberg V2 se heurtent aux mêmes limites quand les données grossissent. Première limite : une demande de conformité qui supprime 50 000 enregistrements d’une table de deux milliards de lignes laisse derrière elle des fichiers de delete positionnels qui ralentissent les requêtes jusqu’à la prochaine compaction. Deuxième limite : les événements semi-structurés atterrissent comme des chaînes JSON que chaque requête doit reparser. Troisième limite : les coordonnées géospatiales et les horodatages à la nanoseconde sont encodés en chaînes ou en entiers. Chaque contournement ajoute du coût de stockage, de la latence et du code de pipeline.
Ces coûts ne sont pas théoriques. Le fichier de delete positionnel est un héritage du modèle V2, où chaque suppression devait pointer une à une les lignes à ignorer ; à l’échelle d’un pétaoctet, ces fichiers se multiplient et repoussent la compaction. Le JSON semi-structuré, lui, oblige chaque moteur à reparser le document entier pour en extraire un champ — une opération redondante quand le champ aurait pu être stocké typé dès l’écriture.
Ce que V3 apporte
Iceberg V3 s’attaque frontalement à ces trois points. Les vecteurs de suppression remplacent les fichiers de delete positionnels de V2 par un format binaire compact : la suppression de 50 000 lignes écrit désormais un seul fichier de vecteur au lieu de milliers de petits deletes, ce qui réduit fortement le temps de compaction et la charge de fichiers. Le row lineage ajoute automatiquement les colonnes _row_id et _last_updated_sequence_number à chaque enregistrement : vos pipelines aval peuvent interroger ces champs pour trouver les lignes modifiées sans balayer la table entière.
Les nouveaux types permettent de stocker nativement le semi-structuré, le géospatial et la précision nanoseconde, au lieu de les encoder en chaînes ou en entiers. Le type variant stocke le semi-structuré en colonnes : à l’écriture, le moteur « déchiquette » les données variant en colonnes cachées et collecte des statistiques ; à la lecture, ces statistiques autorisent un élagage de fichiers qui réduit nettement les entrées-sorties par rapport au parsing de JSON brut. S’y ajoutent timestamp(tz) pour la nanoseconde, geometry et geography pour le géospatial, et unknown pour les colonnes sans type connu.
Le variant et le row lineage en pratique
L’exemple fourni par AWS est celui d’une équipe d’analyse retail qui suit des événements web et mobile aux structures hétérogènes : une page vue a une URL et une durée, un achat a des articles et des montants, une recherche a des termes et un nombre de résultats. Avec le type variant, tous ces schémas cohabitent dans une seule table sans schéma prédéfini :
CREATE TABLE my_catalog.namespace.clickstream (
event_id bigint,
event_time timestamp,
user_id string,
payload variant
) USING iceberg TBLPROPERTIES ('format-version' = '3');Les lectures se font ensuite sans PARSE_JSON : sur Amazon EMR Spark, la fonction variant_get extrait directement un champ typé du document.
Pour les suppressions, activer le mode merge-on-read fait écrire un petit vecteur de suppression plutôt qu’une réécriture de fichiers de données, et la compaction de S3 Tables traite ces vecteurs automatiquement au cycle de maintenance suivant. Côté incrémental, une requête filtrant sur _last_updated_sequence_number > 42 ne renvoie que les lignes modifiées après la séquence 42 — le checkpoint de vos jobs aval devient un simple entier.
La migration V2 vers V3
AWS a soigné la bascule. L’upgrade est atomique et se fait sans réécrire les données :
ALTER TABLE my_catalog.namespace.existing_table
SET TBLPROPERTIES ('format-version' = '3');Les lecteurs V2 existants continuent de fonctionner sur la table migrée jusqu’à ce que vous adoptiez pleinement les fonctionnalités V3. Au cycle de compaction suivant, S3 Tables supprime les anciens fichiers de delete V2, et les nouvelles modifications utilisent automatiquement les vecteurs de suppression. Les champs de row lineage s’initialisent à la première modification après l’upgrade. C’est une opération à sens unique : la spécification Iceberg ne permet pas de revenir de V3 à V2 — vérifiez donc que tous les moteurs qui accèdent à la table supportent V3 avant de migrer.
Deux contraintes d’exploitation à connaître. D’abord, les nouveaux types exigent un moteur basé sur Apache Spark 4.0 ou plus — AWS Glue 6.0 et Amazon EMR 8.1 et au-delà. Ensuite, ils ne sont supportés que pour les tables au format Parquet, pas ORC ni Avro ; et les colonnes variant, geometry, geography ou à horodatage nanoseconde ne peuvent pas figurer dans l’ordre de tri de la compaction.
Ce que ça change pour un opérateur
Premièrement, le gain est concret pour qui gère des suppressions de conformité ou des données semi-structurées : moins de fichiers de delete, moins de JSON à parser, moins de code d’encodage géospatial. Deuxièmement, la bascule V2 → V3 est réversible en lecture pendant la transition — vous pouvez migrer la table et laisser vos lecteurs V2 continuer à tourner. Troisièmement, l’interopérabilité reste large : S3 Tables et AWS Glue Data Catalog exposent l’API Iceberg REST Catalog (IRC), ce qui permet aux moteurs de se brancher quel que soit le point d’entrée du catalogue. La fonctionnalité est disponible dans toutes les régions où S3 Tables est proposé, sans surcoût au-delà de la tarification standard. En pratique, la bascule se résume à une checklist : vérifier la version du moteur, confirmer le format Parquet, valider que chaque lecteur comprend V3, puis basculer la propriété format-version — le service absorbe la transition au cycle de compaction suivant.
Verdict
Si vos pipelines souffrent des fichiers de delete positionnels ou du parsing de JSON semi-structuré, la migration vers V3 est le chantier le plus rentable à court terme : elle supprime une classe entière de latence sans ré-architecture. Si vous devez préserver des lecteurs non-Spark ou des formats ORC/Avro, restez en V2 le temps de vérifier la compatibilité de chaque moteur — l’upgrade est à sens unique. Si vous montez de nouveaux lacs analytiques, créez directement en V3 avec un moteur Spark 4.0 : c’est désormais l’état de l’art du stockage analytique sur S3, et le coût d’entrée est nul. Le message d’AWS tient en une phrase : les workarounds de V2 n’ont plus de raison d’être pour qui peut adopter Spark 4.0.