Amazon Redshift stocke ses vues matérialisées en tables Iceberg lisibles par tous les moteurs
Depuis le 5 octobre 2026, Redshift peut écrire le résultat de ses vues matérialisées sous forme de tables Apache Iceberg dans S3, interrogeables par Athena, Spark, Glue ou SageMaker sans copie. Pour une équipe qui veut garder ses agrégats précalculés ouverts à tous ses moteurs plutôt que verrouillés dans Redshift, c’est une bascule concrète.
5 octobre 2026. AWS annonce dans son blog Big Data les vues matérialisées Iceberg d’Amazon Redshift : une même agrégation précalculée peut désormais être stockée comme une table Apache Iceberg dans S3, lisible par Athena, Spark, Glue ou SageMaker — sans copie ni pipeline intermédiaire. Le mot d’ordre du billet est « materialize once, query anywhere ». Pour une équipe data dont les transformations vivent dans Redshift mais dont les consommateurs sont éparpillés, c’est la fin d’un arbitrage qu’on croyait structurel : la performance et l’ouverture cessaient toujours de se rencontrer quelque part.
Ce que fait précisément la fonctionnalité
Une vue matérialisée (MV) précalcule une jointure ou une agrégation coûteuse une fois, puis sert ce résultat au lieu de relancer le calcul à chaque requête. Jusqu’ici, chez Redshift, ce résultat vivait dans le stockage propriétaire Redshift Managed Storage (RMS) : rapide, mais illisible par tout moteur extérieur. La nouveauté tient dans une clause : CREATE MATERIALIZED VIEW … USING ICEBERG. Le résultat devient une table Iceberg standard dans S3 ou dans un bucket S3 Table, enregistrée dans le AWS Glue Data Catalog.
Concrètement, le flux se lit ainsi. Redshift calcule l’agrégation une fois, en SQL que vos équipes écrivent déjà. Le résultat est stocké comme une table Iceberg ordinaire, gouvernée et découverte comme n’importe quelle table du catalogue Glue. Athena, Spark sur EMR, Glue, SageMaker AI — et tout moteur compatible Iceberg — lisent cette même table directement. Quand de nouvelles données arrivent, un refresh incrémental ne recalcule que ce qui a changé, au lieu de réécrire la vue entière.
Le gain se résume à un mot : interopérabilité. Le poste d’une équipe d’analytique sur Redshift n’avait pas de moyen simple de partager ses résultats précalculés les plus coûteux avec le groupe data science sur Spark ou l’équipe de reporting ponctuel sur Athena — sinon exporter des copies ou monter une seconde pile de transformation. Désormais, la même table Iceberg sert de source de vérité unique pour la requête la plus chère, partagée par tous les moteurs.
Le contexte : Redshift RG et l’écriture Iceberg
La fonctionnalité n’arrive pas dans un vide. AWS a lancé plus tôt dans l’année Redshift RG, propulsé par Graviton, avec un moteur de requête vectorisé dédié aux data lakes : scans Parquet vectorisés, préchargement intelligent des E/S, élagage par partition et par fichier, filtres Bloom améliorés, et collecte automatique de statistiques Iceberg via JIT Analyze. Le bilan annoncé : des requêtes Iceberg jusqu’à 2,4× plus rapides que sur RA3, à 30 % de coût en moins par vCPU, et sans frais de scan par téraoctet sur les requêtes du lac.
Sur cette base, Redshift savait déjà écrire dans des tables Iceberg avec alignement ACID complet : INSERT, CTAS, UPDATE, DELETE, MERGE. Les vues matérialisées Iceberg complètent le dispositif en rendant l’accélération elle-même portable. L’optimisation ne reste plus enfermée dans un format de stockage propriétaire : elle est écrite dans un standard ouvert que les autres moteurs de l’organisation lisent nativement.
Les vues matérialisées Iceberg sont prises en charge sur Redshift Serverless et sur les instances RG — pas sur RA3 ni DC2. La gouvernance s’appuie sur les permissions IAM du rôle du schéma externe.
RMS ou Iceberg : deux outils, deux usages
La vraie question pour un architecte n’est pas « laquelle est la meilleure », mais « où le résultat est-il consommé ». AWS lui-même trace la ligne de partage, et elle est limpide.
Utilisez une MV Redshift classique (RMS) quand vous n’interrogez que depuis Redshift, que vous cherchez la latence de lecture la plus basse — tableaux de bord interactifs, lectures sous la seconde — et que vous voulez l’option la plus simple pour une charge Redshift-seule. Lire une table dans RMS est nettement plus rapide que lire une table Iceberg depuis S3.
Utilisez une MV Iceberg quand vous voulez que le résultat précalculé soit lisible par des moteurs extérieurs à Redshift sans copie, que vous standardisez sur Apache Iceberg pour l’interopérabilité, ou que vous voulez faire tourner un pipeline de bout en bout dans un seul moteur et partager le même résultat ouvert avec tous les consommateurs en aval.
Les deux approches sont complémentaires. Un schéma courant consiste à construire et transformer les données en MV Iceberg pour l’ouverture, puis à charger les résultats les plus sensibles à la latence dans une MV RMS pour les tableaux de bord interactifs. Le principe tient en une phrase : ouvert par défaut, rapide là où ça compte.
Le piège opérationnel à connaître
Une subtilité de nettoyage mérite d’être notée, parce qu’elle coûte cher si on la découvre trop tard. DROP MATERIALIZED VIEW supprime l’entrée du catalogue Glue, mais ne supprime pas les données sous-jacentes dans S3. Pour réellement libérer le stockage, il faut effacer le préfixe S3 manuellement :
# Supprimer la MV du catalogue Glue…
DROP MATERIALIZED VIEW iceberg_schema.sales_by_region;
# …puis libérer les données dans S3 (à faire à la main)
aws s3 rm s3://mon-bucket/iceberg_mv_blog/ --recursiveC’est un détail de facturation, pas de théorie : une table Iceberg laissée en place continue d’occuper du stockage S3 et de générer des coûts, alors même que la vue n’apparaît plus nulle part dans le catalogue. Les équipes qui suppriment des MV « pour nettoyer » sans purger S3 se retrouvent avec un lac qui grossit tout seul.
Un exemple concret, et ce que ça change pour la facture
Le passage à l’acte tient en une requête. La table source doit être une table Iceberg — une table native Redshift ne peut pas servir de source —, et l’exemple type est une table de commandes orders agrégée par région pour un reporting quotidien :
CREATE MATERIALIZED VIEW iceberg_schema.sales_by_region
USING ICEBERG
AS
SELECT region, SUM(amount) AS total_amount, COUNT(*) AS orders
FROM orders
GROUP BY region;Ce cas précis est le plus favorable : le refresh incrémental n’est pris en charge que pour les agrégats COUNT et SUM avec GROUP BY et les jointures internes. Dès qu’une vue utilise DISTINCT, une jointure externe, une fonction de fenêtre ou un agrégat autre que COUNT/SUM, Redshift bascule sur un refresh complet. Le choix des colonnes et des agrégats n’est donc pas neutre : il détermine si vous recalculez tout ou seulement le delta.
Autre point qui décide de l’exploitation : il n’y a pas d’auto-refresh. Contrairement aux vues matérialisées RMS, une MV Iceberg doit être rafraîchie à la main :
REFRESH MATERIALIZED VIEW iceberg_schema.sales_by_region;C’est aussi un choix de coût. Une MV Iceberg sur un volume important ne se rafraîchit pas gratuitement : chaque refresh consomme du calcul Redshift. En ne réécrivant que le delta, le refresh incrémental évite le coût d’un recalcul complet à chaque chargement — et, surtout, il supprime le coût caché des copies et des pipelines redondants montés pour partager le résultat avec d’autres moteurs. L’optimisation devient portable, donc les autres moteurs n’ont plus à la recalculer de leur côté.
Verdict
Si toutes vos requêtes restent dans Redshift, ne changez rien : la MV RMS reste l’option la plus rapide et la plus simple. Si vos résultats précalculés sont consommés par plusieurs moteurs — un groupe Spark, une équipe Athena, un pipeline ML — basculez ces agrégats vers des MV Iceberg : vous calculez une fois, tout le monde lit la même table ouverte, et vous supprimez les copies et les pipelines redondants. Si vous vendez l’argument de la sortie de verrouillage à votre direction, c’est le cas d’usage le plus parlant depuis longtemps : l’optimisation de requête elle-même devient un actif portable, écrit dans un standard que la concurrence lit aussi. La prudence, elle, reste un réflexe d’opérateur — surveillez le refresh incrémental, gouvernez l’accès via IAM, et n’oubliez jamais que DROP ne libère pas S3.