Les tables Hive sont des dossiers de fichiers plus une entrée dans un metastore. Elles fonctionnent, mais n'ont pas de transactions, changer le partitionnement oblige à tout réécrire, et lister des millions de fichiers ralentit chaque requête. Apache Iceberg règle cela avec une vraie couche de table : commits atomiques, changements de schéma et de partitions sans réécriture, voyage dans le temps et planification rapide. En 2026, c'est aussi le format que Snowflake, Databricks, BigQuery, AWS, DuckDB et Polars lisent et écrivent. Le 4 novembre, AWS a fait de la migration une fonction gérée d'Amazon S3 Tables. Ce guide couvre cette option et les deux méthodes classiques.
Méthode 1 : sur place, avec les procédures Spark
Iceberg fournit des procédures Spark qui transforment une table Hive existante en table Iceberg sans copier les données. Elles lisent la liste des fichiers, écrivent les métadonnées et manifestes Iceberg et enregistrent la nouvelle table. Les fichiers de données doivent être en Parquet, ORC ou Avro.
-- Step 1: try it safely. Creates db.sales_iceberg pointing at the same files.
-- The original Hive table is untouched.
CALL spark_catalog.system.snapshot('db.sales', 'db.sales_iceberg');
-- Test queries, row counts and downstream jobs against db.sales_iceberg...
-- Step 2: convert for real. Replaces db.sales with an Iceberg table
-- (the old Hive table is kept as a backup with a _BACKUP_ suffix).
CALL spark_catalog.system.migrate('db.sales');
-- Alternative: add existing files to an Iceberg table you created yourself
CALL spark_catalog.system.add_files(
table => 'db.sales_new',
source_table => 'db.sales'
);Méthode 2 : réécriture complète avec CREATE TABLE AS SELECT
Si la table Hive a des problèmes que vous voulez corriger de toute façon, comme des milliers de petits fichiers, de mauvaises partitions ou une compression ancienne, écrivez plutôt une nouvelle table Iceberg :
CREATE TABLE lake.db.sales
USING iceberg
PARTITIONED BY (days(order_ts)) -- hidden partitioning: no extra date column needed
TBLPROPERTIES ('write.parquet.compression-codec' = 'zstd')
AS SELECT * FROM spark_catalog.db.sales;Chaque octet est lu et réécrit, donc c'est plus long et le stockage double jusqu'à la suppression de l'ancienne table. En échange, vous obtenez des fichiers bien dimensionnés, une compression moderne et un partitionnement caché : les requêtes filtrent sur order_ts et Iceberg élague les partitions automatiquement, si bien que les utilisateurs n'ont plus à connaître une colonne de partition séparée.
Méthode 3 : migration gérée dans Amazon S3 Tables
Nouveau depuis le 4 novembre 2026. Si vos tables Hive sont enregistrées dans AWS Glue et stockées en Parquet, S3 Tables peut mener toute la migration :
- Coût : vous ne payez que les données copiées par la tâche ; la conversion Hive vers Iceberg est gratuite. Les fichiers source en S3 Intelligent-Tiering gardent leur niveau d'accès.
- De meilleurs fichiers : les tables compressées en Snappy sont recompressées en Zstandard et compactées, ce qui réduit le stockage et le nombre d'objets.
- Limites au lancement : tables Hive enregistrées dans Glue, en Parquet, dans le même compte et la même région AWS, dans 10 régions dont l'Irlande, Francfort et Stockholm en Europe.
- Pour les agents IA : AWS a aussi publié une compétence de migration pour qu'un agent puisse mener le processus, avec votre accord.
Quelle méthode choisir ?
| Sur place (migrate) | Réécriture (CTAS) | S3 Tables gérée | |
|---|---|---|---|
| Copie les données | Non | Oui | Oui |
| Vitesse | Minutes | Des heures pour les grosses tables | Tourne en arrière-plan |
| Corrige petits fichiers et partitions | Non | Oui | Compacte et recompresse |
| Retour arrière | Depuis la table de sauvegarde | Gardez l'ancienne table | Intégré |
| Où | Tout Spark avec Iceberg | Tout moteur Iceberg | AWS uniquement, Glue et Parquet |
La liste de contrôle de la bascule
- 1
Listez chaque lecteur et rédacteur
Tableaux de bord, tâches Spark, requêtes Athena ou Trino, exports. Chacun doit prendre en charge Iceberg avant la bascule.
- 2
Arrêtez ou suspendez les écritures
Migrez pendant une période calme, ou utilisez la synchronisation de S3 Tables pour rattraper les changements avant la bascule.
- 3
Comparez les résultats
Nombre de lignes, sommes des colonnes clés et quelques requêtes types sur l'ancienne et la nouvelle table.
- 4
Changez le nom
Faites pointer les tâches vers la nouvelle table, ou laissez migrate remplacer le nom pour vous.
- 5
Planifiez la maintenance
Iceberg demande un compactage et une expiration des snapshots réguliers ; S3 Tables, Databricks et Snowflake peuvent le faire automatiquement.
- 6
Supprimez l'ancienne table plus tard
Gardez la sauvegarde une ou deux semaines avant de l'effacer.
Testez vos connaissances
1/3Que fait la procédure migrate d'Iceberg des fichiers de données ?
C'est une conversion des seules métadonnées ; la table d'origine est conservée en sauvegarde.
2/3Pourquoi choisir plutôt une réécriture complète ?
CTAS lit et réécrit tout, ce qui permet de changer l'organisation.
3/3Que payez-vous avec la migration gérée de S3 Tables ?
La conversion de Hive vers Iceberg n'est pas facturée.
Vous avez 0 bonne(s) réponse(s) sur 3.
À lire aussi : Apache Iceberg v3, DuckDB, Polars ou Spark et comment choisir une base de données.
Sources : AWS, « Amazon S3 Tables now provide a simple, cost-effective path for data lake modernization » (4 novembre 2026) ; documentation d'Apache Iceberg sur les procédures Spark (snapshot, migrate, add_files) et les propriétés de table ; blog Google Cloud (4 novembre 2026) pour le chiffre de talabat. Testez les procédures sur une copie avant de les lancer sur des tables de production.
Alessandro Ecclesie AgazziÉcrit par Alessandro Ecclesie Agazzi, analytics engineer à Londres. Mis à jour le 9 novembre 2026. À propos