AWS ajoute à S3 Tables une migration gérée de Hive vers Iceberg : périmètre de lancement : tables Parquet enregistrées dans Glue, même compte et même région, dix régions, destination en lecture seule jusqu’à la finalisation

Le 4 novembre 2026, AWS a annoncé la migration gérée de tables Apache Hive vers Apache Iceberg dans Amazon S3 Tables. L’annonce What’s New et le billet de lancement du blog AWS News la décrivent comme une opération pilotée par API : S3 Tables valident la source, convertissent les types de données, copient les données, les recompressent et compactent les petits fichiers, tandis que les charges de production continuent de tourner. AWS dit que passer de Hive à Iceberg exigeait auparavant des semaines d’ingénierie, car chaque table demandait son propre pipeline de migration. Cette durée est une déclaration d’AWS et les billets n’en donnent aucune mesure.

Le périmètre de lancement est étroit et doit être lu en premier. Au lancement, la fonction prend en charge les tables Hive enregistrées dans AWS Glue, stockées au format Parquet, dans le même compte AWS et la même région. Elle est disponible dans dix régions : USA Est (Virginie du Nord, Ohio), USA Ouest (Oregon), Asie-Pacifique (Mumbai, Singapour, Sydney, Tokyo) et Europe (Francfort, Irlande, Stockholm). Les tables Hive dans d’autres formats, dans un autre compte ou dans une région absente de cette liste sortent du périmètre indiqué. Les billets ne disent pas quand cela changera.

Le flux comporte trois étapes : démarrage, synchronisation et finalisation. Au démarrage, S3 Tables identifient tous les objets source concernés et produisent des rapports de compatibilité avant de copier la moindre donnée. Par défaut, la tâche se poursuit automatiquement après la planification ; un indicateur de revue la met en pause pour lire d’abord les rapports. La destination est une nouvelle table Iceberg dans un compartiment de tables, créée avec les valeurs par défaut recommandées, et elle est en lecture seule pendant la migration. On peut appeler la synchronisation aussi souvent que l’on veut, et chacune ne copie que ce qui a changé. À la finalisation, la table de destination passe en lecture-écriture. Athena et Amazon SageMaker Unified Studio s’intègrent directement dans la console, et tout moteur compatible avec l’API REST d’Iceberg peut interroger le résultat.

Les sources ne décrivent pas tout à fait de la même façon la perturbation de la table source. Le guide du développeur dit que la table source reste inchangée et pleinement disponible en lecture et en écriture pendant une tâche de migration. Le billet de lancement dit qu’on peut synchroniser autant de fois que nécessaire sans arrêter les écritures sur la source, sauf quelques minutes au moment du basculement. Ces affirmations ne se contredisent pas, mais elles ne sont pas identiques : la documentation parle de la tâche, le billet du basculement final. Les équipes qui n’acceptent même pas une courte pause d’écriture au basculement doivent planifier cette étape et ne pas supposer une interruption nulle. Les billets disent aussi qu’on peut revenir aux données source, ce qui concorde avec la source laissée intacte selon la documentation.

Le traitement des types et du schéma est explicite. La migration fait correspondre le schéma et le partitionnement Hive à un schéma et à une spécification de partition Iceberg ; on peut fournir un schéma de destination ou laisser la migration en générer un compatible à partir du schéma Glue. Une politique de migration décide de ce qui se passe en cas d’écart, et l’exemple du billet règle les politiques de champs non appariés et de valeurs incompatibles sur l’échec. C’est une valeur d’exemple dans une requête type, pas une valeur par défaut déclarée. La requête type montre aussi des paramètres de maintenance réglables : un compactage avec une taille de fichier cible de 512 Mo et une gestion des instantanés qui en garde au moins trois et les fait expirer après 168 heures. Après la copie, un rapport de migration d’objets donne le résultat pour chaque objet source.

Le coût est décrit de façon qualitative. On ne paie que les données copiées par la tâche, sans frais pour la conversion Hive vers Iceberg elle-même, et les objets sources en S3 Intelligent-Tiering restent dans leur niveau d’accès actuel et conservent leur compteur de jours depuis le dernier accès. Pas de frais de conversion ne veut pas dire migration gratuite : les données copiées sont facturées aux tarifs S3, et les billets renvoient à la page de tarifs sans donner de prix au gigaoctet. Si les tables utilisent la compression Snappy, S3 Tables les recompressent en Zstandard et les compactent, ce qui, selon AWS, réduit le stockage et le nombre d’objets et améliore les performances des requêtes ; AWS ne donne aucun chiffre avant et après.

Les agents font partie de l’argumentaire. Une compétence de migration de l’Agent Toolkit for AWS permet à un agent de code comme Kiro d’analyser les politiques IAM existantes et de recommander des politiques équivalentes pour la destination, de valider le plan, d’exécuter les appels de démarrage, de synchronisation et de finalisation et de suivre l’avancement, avec des garde-fous. Cette compétence est un guide pour un agent qui appelle les mêmes API, pas un autre moteur de migration.

Notre lecture : la fonction supprime l’étape de construction d’un pipeline, et les limites indiquées décident si elle vous concerne. Vérifiez quatre points avant de vous y fier : la table est enregistrée dans Glue, les données sont en Parquet, la source et la destination partagent compte et région, et la région figure dans la liste. Planifiez ensuite la fenêtre de basculement, lisez les rapports de compatibilité avant la copie si le schéma contient des types inhabituels, et estimez le coût de copie d’après votre volume de données. La destination étant en lecture seule pendant la migration, la nouvelle table ne peut pas recevoir d’écritures avant la finalisation.