Amazon Redshift ne prendra plus en charge l'utilisation des UDF Python après le 30 juin 2026. Nous allons commencer à l'appliquer par étapes. Pour plus d'informations sur les options de fin de vie et de migration de Python, consultez le [billet de blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/) publié le 30 juin 2025.
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Vues matérialisées stockées sous forme de tables Apache Iceberg
Vous pouvez créer des vues matérialisées qui stockent leurs données sous forme de tables Apache Iceberg dans des compartiments de table Amazon S3 ou Amazon S3. Contrairement aux vues matérialisées Amazon Redshift standard, qui stockent les données en interne dans Redshift Managed Storage (RMS), les vues matérialisées Iceberg sont stockées sous forme de tables Iceberg standard et sont accessibles à tout moteur d'analyse prenant en charge le format Iceberg, notamment Apache Spark, Amazon Athena et Trino.
Les vues matérialisées d'Iceberg combinent les fonctionnalités d'optimisation des requêtes et d'actualisation incrémentielle d'Amazon Redshift avec le format de table ouverte d'Iceberg. Vous pouvez créer, actualiser et supprimer des vues matérialisées Iceberg à l'aide des mêmes commandes SQL que les vues matérialisées standard, avec l'ajout de la `USING ICEBERG` clause lors de la création.
Les vues matérialisées Iceberg sont prises en charge sur les clusters Redshift Serverless et provisionnés avec des types d'instances RG. Les types d'instances RA3 et DC2 ne sont pas pris en charge.
Pour plus d'informations sur les commandes SQL utilisées pour créer et gérer les vues matérialisées d'Iceberg, consultez les rubriques relatives aux commandes suivantes :
+ [CREATE MATERIALIZED VIEW](materialized-view-create-sql-command.md)
+ [REFRESH MATERIALIZED VIEW](materialized-view-refresh-sql-command.md)
+ [DROP MATERIALIZED VIEW](materialized-view-drop-sql-command.md)
## Comment fonctionnent les vues matérialisées d'Iceberg
Lorsque vous créez une vue matérialisée d'Iceberg, Amazon Redshift effectue les opérations suivantes :
1. Exécute la requête de définition et écrit les résultats sous forme de fichiers de données Parquet dans Amazon S3.
1. Enregistre la table dans les métadonnées AWS Glue Data Catalog with Iceberg, ce qui la rend détectable par d'autres moteurs.
1. Stocke la définition de la vue matérialisée et l'état d'actualisation AWS Glue pour une gestion indépendante du cluster.
Lorsque vous actualisez une vue matérialisée d'Iceberg, Amazon Redshift compare les instantanés d'Iceberg de la table source actuelle aux instantanés enregistrés lors de la dernière actualisation. Si des modifications sont détectées, Amazon Redshift calcule et applique uniquement les données modifiées (actualisation incrémentielle) ou effectue un recalcul complet.
## Exigences relatives à la table source
Les tables sources pour les vues matérialisées d'Iceberg doivent répondre aux exigences suivantes :
+ Doit être au format Apache Iceberg. Non-Iceberg les tables (tables natives Amazon Redshift, tables externes Hive ou Parquet) ne sont pas prises en charge en tant que tables sources.
+ Doit être dans le même Région AWS compte que la vue matérialisée.
+ Peut être référencé à l'aide d'une notation en trois parties (`awsdatacatalog.{{database}}.{{table}}`), de la notation Amazon S3 Tables (`"{{bucket}}@s3tablescatalog".{{database}}.{{table}}`) ou d'une notation en deux parties via un schéma externe ()`{{external_schema}}.{{table}}`.
## Cross-engine interopérabilité
Les vues matérialisées d'Iceberg créées par Amazon Redshift apparaissent sous forme de tables Iceberg standard dans le. AWS Glue Data Catalog D'autres moteurs d'analyse peuvent les lire à l'aide des modèles d'accès aux tables Iceberg standard sans aucune configuration supplémentaire.
Les restrictions suivantes s’appliquent :
+ Seul Amazon Redshift peut actualiser ou supprimer les vues matérialisées créées par Amazon Redshift.
+ Les vues matérialisées Iceberg créées par d'autres moteurs (tels qu'Apache Spark) peuvent être interrogées par Amazon Redshift sous forme de tables en lecture seule, mais ne peuvent pas être actualisées ou supprimées par Amazon Redshift.
## Actualisation incrémentielle
Amazon Redshift effectue une actualisation incrémentielle lorsque la définition de la vue matérialisée le permet. L'actualisation incrémentielle lit uniquement les données modifiées dans les tables sources depuis la dernière actualisation et applique ces modifications à la vue matérialisée.
L'actualisation incrémentielle est prise en charge pour les vues matérialisées qui utilisent :
+ `SELECT ... FROM ... WHERE ... GROUP BY`avec les fonctions d'agrégation COUNT et SUM
+ Jointures internes entre les tables sources d'Iceberg
Amazon Redshift revient automatiquement à l'actualisation complète lorsque :
+ La vue matérialisée utilise des constructions SQL qui ne sont pas prises en charge pour l'actualisation incrémentielle. Pour plus d'informations, consultez la section Limitations qui suit et[Actualisation d’une vue matérialisée](materialized-view-refresh.md).
+ Les instantanés de la table source issus de la dernière actualisation ont expiré.
+ Les données de vue matérialisées ont été modifiées en dehors d'une opération d'actualisation d'Amazon Redshift.
## Actualisation simultanée
Plusieurs clusters ou groupes de travail Amazon Redshift peuvent tenter d'actualiser simultanément la même vue matérialisée d'Iceberg. Amazon Redshift utilise un contrôle de simultanéité optimiste (OCC) par le biais du mécanisme de mise à jour conditionnelle afin AWS Glue Data Catalog de garantir la réussite d'une seule actualisation. Si une actualisation simultanée est détectée, Amazon Redshift vérifie si la vue matérialisée est toujours obsolète. Si un autre cluster a déjà terminé l'actualisation, l'opération est abandonnée.
## Compactage et entretien des tables
Pour les vues matérialisées Iceberg stockées dans des compartiments de table Amazon S3, Amazon S3 Tables gère automatiquement le compactage et l'optimisation des fichiers de données. Aucune action de l'utilisateur n'est requise.
Pour les vues matérialisées stockées dans des compartiments Amazon S3 à usage général (spécifiés via le `LOCATION` paramètre), Amazon Redshift n'effectue pas de compactage. Au fil du temps, l'actualisation incrémentielle produit de nombreux petits fichiers de données susceptibles de dégrader les performances de lecture. Pour maintenir les performances de lecture, appliquez les pratiques recommandées suivantes :
+ Exécutez le compactage régulièrement à l'aide d'un outil externe tel que la `rewrite_data_files` procédure d'Apache Spark.
+ Configurez l'expiration des instantanés Iceberg pour limiter la croissance du stockage par rapport aux instantanés historiques.
Pour les tables sources, configurez la conservation des instantanés afin de dépasser l'intervalle d'actualisation prévu. Lorsque les instantanés de la table source expirent avant la prochaine actualisation, Amazon Redshift ne peut plus calculer de delta incrémentiel et revient à une actualisation complète.
## Considérations sur la sécurité
### Permissions
Les autorisations suivantes sont requises :
+ **CREATE** — L'appelant a besoin de l'autorisation CREATE TABLE dans la AWS Glue base de données cible. Le rôle IAM associé au schéma externe (le rôle de définition MV) doit disposer de l'autorisation SELECT sur toutes les tables sources, accordée via AWS Lake Formation ou AWS Glue via des politiques de ressources.
+ **REFRESH** — L'appelant a besoin de l'autorisation ALTER sur la vue matérialisée. Le rôle de définition MV (enregistré au moment de la création) doit disposer de l'autorisation SELECT sur toutes les tables sources.
+ **DROP** — L'appelant a besoin de l'autorisation DROP sur la vue matérialisée.
+ **REQUÊTE** — L'appelant a besoin de l'autorisation SELECT sur la vue matérialisée, accordée par le biais AWS Lake Formation de politiques relatives aux AWS Glue ressources.
Pour plus d'informations sur la création de rôles IAM pour Amazon Redshift et l' AWS Lake Formation octroi d'autorisations, consultez. [Mise en route avec Amazon Redshift Spectrum](c-getting-started-using-spectrum.md) Pour vérifier que le rôle IAM dispose des autorisations requises sur les tables sources, utilisez la AWS Lake Formation console ou l'`GetEffectivePermissionsForPath`API. Pour vérifier que la AWS Glue base de données cible existe et que le rôle y a accès, utilisez l'`GetDatabase`API.
L'exemple suivant vérifie que le rôle IAM dispose de l'autorisation SELECT sur une table source via : AWS Lake Formation
```
aws lakeformation list-permissions \
--principal DataLakePrincipalIdentifier=arn:aws:iam::123456789012:role/myspectrum_role \
--resource '{"Table":{"DatabaseName":"mydb","Name":"orders"}}'
```
L'exemple suivant vérifie que la base de AWS Glue données cible existe et est accessible :
```
aws glue get-database --name mydb
```
### Visibilité de l'historique instantané
Les vues matérialisées d'Iceberg stockent les données sous forme de tables Iceberg standard avec un historique complet des instantanés. Un lecteur ayant accès aux fichiers Iceberg sous-jacents peut comparer des instantanés successifs pour observer quelles lignes ont été ajoutées ou supprimées entre les actualisations.
Pour les vues matérialisées agrégées (celles dotées de fonctions GROUP BY et d'agrégation), le delta visible est limité aux modifications des valeurs agrégées, et non aux lignes individuelles du tableau source. Pour les vues matérialisées non agrégées, le delta correspond aux lignes spécifiques qui ont changé dans la sortie de la vue matérialisée.
Ce comportement est inhérent au format de tableau Iceberg. Toute table Iceberg soumise à des écritures incrémentielles expose la même propriété.
Pour atténuer ce comportement, procédez comme suit :
+ Utilisez AWS Lake Formation les autorisations ou les politiques relatives aux compartiments Amazon S3 pour contrôler qui peut accéder aux fichiers de données Iceberg sous-jacents de la vue matérialisée.
+ Pour les vues matérialisées contenant des données sensibles pour lesquelles l'historique des modifications ne doit pas être observable, définissez la vue matérialisée avec des constructions SQL qui forcent l'actualisation complète (comme DISTINCT). L'actualisation complète remplace toutes les données de chaque instantané, ce qui rend impossible de déterminer quelles lignes spécifiques ont été modifiées.
+ Configurez l'expiration des instantanés Iceberg pour limiter la fenêtre de modifications observables. Avec les compartiments de table Amazon S3, la maintenance gérée gère automatiquement le cycle de vie des instantanés.
+ Utilisez les compartiments de table Amazon S3, qui fournissent un contrôle d'accès intégré au niveau de la table.
## Contrôle
### Actualiser l'historique
Les opérations d'actualisation effectuées par le cluster local sont enregistrées[SVL\_MV\_REFRESH\_STATUS](r_SVL_MV_REFRESH_STATUS.md). Interrogez cette vue pour vérifier le moment de l'actualisation, son état et si l'actualisation était incrémentielle ou complète.
```
SELECT mv_name, starttime, endtime, status
FROM svl_mv_refresh_status
WHERE mv_name = 'daily_revenue'
ORDER BY starttime DESC
LIMIT 10;
```
Notez que cette vue système enregistre uniquement les actualisations effectuées par le cluster local. Si plusieurs clusters actualisent la même vue matérialisée d'Iceberg, les tables système de chaque cluster affichent uniquement son propre historique d'actualisation.
### À la découverte des vues matérialisées d'Iceberg
Utilisez la [SHOW TABLES](r_SHOW_TABLES.md) commande pour rechercher les vues matérialisées d'Iceberg. Les vues matérialisées par des icebergs apparaissent avec et`table_type = 'EXTERNAL TABLE'`. `table_subtype = 'ICEBERG MATERIALIZED VIEW'` SHOW TABLES fonctionne sur tous les chemins de catalogue (schémas externes et tables Amazon S3). `awsdatacatalog`
```
SHOW TABLES FROM SCHEMA awsdatacatalog.mydb LIKE '%';
```
Vous pouvez également les utiliser [SVV\_EXTERNAL\_TABLES](r_SVV_EXTERNAL_TABLES.md) pour trouver des vues matérialisées d'Iceberg dans vos schémas externes, où elles apparaissent avec : `tabletype = 'EXTERNAL TABLE'`
```
SELECT schemaname, tablename, location
FROM svv_external_tables
WHERE tabletype = 'EXTERNAL TABLE';
```
**Note**
SVV\_EXTERNAL\_TABLES énumère les vues matérialisées d'Iceberg uniquement pour les schémas externes. Les vues matérialisées Iceberg accessibles via `awsdatacatalog` les catalogues Amazon S3 Tables ne sont pas énumérées par SVV\_EXTERNAL\_TABLES ; utilisez SHOW TABLES pour les découvrir.
[STV\_MV\_INFO](r_STV_MV_INFO.md)n'inclut pas les vues matérialisées d'Iceberg.
## Limitations
Vous ne pouvez pas définir une vue matérialisée d'Iceberg qui fait référence ou inclut l'un des éléments suivants :
+ Non-Iceberg tables sources (tables natives Amazon Redshift, tables externes Hive, Parquet, Delta Lake ou Hudi)
+ Tableaux sources utilisant le format Iceberg version 3
+ User-defined fonctions (UDFs) ou agrégats définis par l'utilisateur
+ Fonctions mutables (GETDATE, RANDOM, CURRENT\_TIMESTAMP et fonctions similaires)
+ Clauses ORDER BY, LIMIT ou OFFSET
+ Identifiants en majuscules dans les noms de tables, de colonnes ou d'alias
+ Tables sources dans un compte Région AWS ou un autre
+ AWS Lake Formation tables filtrées (contrôle d'accès détaillé)
Les constructions SQL suivantes sont autorisées dans la définition de la vue matérialisée mais imposent une actualisation complète au lieu d'une actualisation incrémentielle :
+ DISTINCT
+ Jointures extérieures (GAUCHE, DROITE, PLEINE)
+ Fonctions de fenêtrage
+ Sous-requêtes
+ Opérations d’ensemble
+ ENSEMBLES DE REGROUPEMENT, ROLLUP, CUBE
+ Fonctions d'agrégation autres que COUNT et SUM
+ NOMBRE (DISTINCT), SOMME (DISTINCT)
Restrictions supplémentaires :
+ La réécriture automatique des requêtes pour utiliser des vues matérialisées n'est pas prise en charge pour les vues matérialisées d'Iceberg.
+ Les vues matérialisées automatisées ne sont pas prises en charge pour les vues matérialisées Iceberg.
+ L'actualisation automatique n'est pas prise en charge pour les vues matérialisées d'Iceberg. Vous devez les actualiser manuellement à l'aide de[REFRESH MATERIALIZED VIEW](materialized-view-refresh-sql-command.md).
+ Les vues matérialisées Iceberg ne sont prises en charge que sur les clusters Redshift Serverless et provisionnés dotés de types d'instances RG. Les types d'instances RA3 et DC2 ne sont pas pris en charge.
+ Fine-grained le contrôle d'accès (FGAC) n'est pas pris en charge sur les vues matérialisées d'Iceberg.
+ L'actualisation en CASCADE n'est pas prise en charge pour les vues matérialisées d'Iceberg.
+ Les vues matérialisées d'Iceberg ne peuvent pas être créées ou actualisées lorsque ce paramètre `enable_case_sensitive_identifier` est défini sur. `true`