Amazon Redshift ne prendra plus en charge la création de nouveaux Python à UDFs partir du patch 198. UDFs Le Python existant continuera de fonctionner jusqu'au 30 juin 2026. Pour plus d’informations, 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/). 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. # Commandes SQL Les tables Apache Iceberg d'Amazon Redshift constituent un moyen puissant de gérer de grands ensembles de données analytiques dans votre lac de données. Ces tables prennent en charge les transactions ACID, l'évolution des schémas et les fonctionnalités de voyage dans le temps tout en maintenant des performances élevées pour les charges de travail analytiques. À l'aide des tables Apache Iceberg, vous pouvez organiser et partitionner efficacement vos données, contrôler les formats de fichiers et la compression, et les intégrer facilement à d'autres AWS services. Vous pouvez créer des tables Iceberg partitionnées et non partitionnées à l'aide des commandes and. `CREATE TABLE ... USING ICEBERG` `CREATE TABLE ... USING ICEBERG AS SELECT` Vous pouvez référencer les tables Iceberg à l'aide d'une notation de schéma externe (`external_schema.table_name`) ou d'une notation en trois parties (`"catalog_name".database_name.table_name`). Les exemples présentés dans cette section illustrent les deux méthodes. Après avoir créé une table, vous pouvez ajouter des données à l'aide de `INSERT` commandes standard. N'oubliez pas que même si Amazon Redshift fonctionne avec de nombreux types de données Iceberg, vous devrez peut-être convertir certains formats de données lors de l'insertion d'informations. Vous pouvez afficher les tables Iceberg à l'aide de `SHOW TABLES` la commande. Si vous souhaitez supprimer une table du AWS Glue Data Catalog, vous pouvez utiliser la `DROP TABLE` commande. Notez que cela supprime uniquement l'enregistrement de la table. Les données réelles resteront stockées jusqu'à ce que vous les supprimiez séparément. Vous pouvez également modifier les données existantes à l'aide des `MERGE` commandes `DELETE``UPDATE`, et. Toutes les autres instructions SQL, telles que`ALTER TABLE`, ne sont pas encore prises en charge sur les tables Iceberg. Il est possible d'écrire dans une table Iceberg qui n'a pas été créée par Amazon Redshift. Il existe toutefois certaines limites : + La table doit être une table Iceberg v2. + Le tableau doit utiliser Parquet comme format de données par défaut. + La compression des métadonnées de la table ne doit pas être définie sur True. + La table ne doit pas être activée Write-Audit-Publish (WAP). Les sections suivantes présentent la syntaxe SQL permettant de créer, d'insérer, de modifier et de gérer des tables Iceberg dans Amazon Redshift. **Contents** + [CREATE TABLE](#iceberg-writes-create-table) + [CREATE TABLE AS SELECT](#iceberg-writes-create-table-as-select) + [SHOW TABLE](#iceberg-writes-show-table) + [INSERT INTO](#iceberg-writes-insert-into) + [DELETE](#iceberg-writes-delete) + [UPDATE](#iceberg-writes-update) + [MERGE](#iceberg-writes-merge) + [DROP TABLE](#iceberg-writes-drop-table) ## CREATE TABLE ``` CREATE TABLE [IF NOT EXISTS] {{}}.{{}} ( column_name data_type [, ...] ) USING ICEBERG [LOCATION 's3://{{your-bucket-name}}/prefix/'] [PARTITIONED BY [[column_name | transform_function]], ...] [TABLE PROPERTIES ('compression_type'='')] ``` Vous pouvez également utiliser une notation en trois parties pour les compartiments de table S3 : ``` CREATE TABLE "{{}}@s3tablescatalog".{{}}.{{}} ( column_name data_type [, ...] ) USING ICEBERG [PARTITIONED BY [[column_name | transform_function]], ...] [TABLE PROPERTIES ('compression_type'='')] ``` Notez qu'`{{}}`il doit s'agir d'un nom de schéma externe existant dans lequel la table externe sera créée. Pour plus d'informations sur la création et la gestion de schémas externes, consultez [CREATE EXTERNAL SCHEMA](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_SCHEMA.html) dans la documentation Amazon Redshift. La `LOCATION` clause définit l'emplacement de la table pour cette table Iceberg nouvellement créée. Pour les tables Amazon S3, cela `LOCATION` ne peut pas être spécifié car l'emplacement des tables est déterminé par le catalogue des tables Amazon S3 (`s3tablescatalog`). Dans tous les autres cas, `LOCATION` c'est obligatoire et il doit s'agir d'un emplacement vide, ce qui signifie qu'aucun objet Amazon S3 existant ne partage le même compartiment et le même préfixe. Notez que la région du compartiment Amazon S3 doit se trouver dans la même région que le cluster Amazon Redshift. Cependant, AWS fournit une méthode pour répliquer les données des tables Iceberg stockées AWS Glue Data Catalog dans un emplacement Région AWS vers un autre Région AWS, ce qui vous permet de répliquer l'écriture dans une autre région. Pour plus d'informations, consultez la section [Répliquer des données entre elles. Régions AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/apache-iceberg-on-aws/best-practices-workloads.html#workloads-replication) `PARTITIONED BY`définit la partition de table Iceberg. Amazon Redshift prend en charge toutes les transformations de partitions Iceberg v2, à l'exception de. `void` Voici la liste des transformations prises en charge : + **identité** + **seau [N]** + **tronquer [W]** + **année** + **mois** + **day** + **heure** Pour les définitions complètes de ces transformations et les types de données compatibles, voir [Partition Transforms](https://iceberg.apache.org/spec/#partition-transforms) dans la documentation d'Apache Iceberg. `PARTITIONED BY`Supporte le partitionnement à plusieurs niveaux. Par exemple, vous pouvez exécuter la commande suivante : ``` CREATE TABLE ... USING ICEBERG LOCATION ... PARTITIONED BY (bucket(16, id), year(ship_date)); ``` Cependant, Amazon Redshift ne prend pas en charge l'utilisation d'une seule colonne dans plusieurs transformations. Par exemple, la syntaxe suivante n'est pas prise en charge : ``` CREATE TABLE ... USING ICEBERG LOCATION ... PARTITIONED BY (bucket(16, ship_date), year(ship_date)); ``` La `TABLE PROPERTIES` clause définit les propriétés de table supplémentaires pour cette table Iceberg. La seule propriété de table que nous prenons en charge est `compression_type` celle qui définit la compression par défaut du fichier de données Parquet. S'il n'est pas spécifié, `snappy` il est utilisé comme codec de compression. Les valeurs possibles pour `compression_type` sont : `zstd``brotli`,`gzip`,`snappy`, et`uncompressed`. **Note** `CREATE TABLE ... LIKE ...`n'est pas pris en charge pour les tables Iceberg. Les tables Iceberg ne prennent pas non plus en charge les contraintes de colonne et les attributs de colonne comme le font les tables RMS. Vous pouvez également créer et remplir une table Iceberg en une seule opération en utilisant : `CREATE TABLE AS SELECT` ## CREATE TABLE AS SELECT ``` CREATE TABLE {{}}.{{}} [( column_name[, ...] )] USING ICEBERG [LOCATION 's3://{{your-bucket-name}}/prefix/'] [PARTITIONED BY [[column_name | transform_function]], ...] [TABLE PROPERTIES ('compression_type'='{{}}')] AS SELECT query ``` Vous pouvez également utiliser la notation en trois parties pour créer des tableaux dans des catalogues montés automatiquement : ``` CREATE TABLE "{{}}".{{}}.{{}} [( column_name[, ...] )] USING ICEBERG [LOCATION 's3://{{your-bucket-name}}/prefix/'] [PARTITIONED BY [[column_name | transform_function]], ...] [TABLE PROPERTIES ('compression_type'='{{}}')] AS SELECT query ``` Ceci est similaire à l'`CREATE TABLE`instruction sauf qu'il `CREATE` est suivi d'une `SELECT` instruction pour remplir le tableau avec les résultats de la `SELECT` requête. La `CREATE TABLE` clause ici ne vous permet plus de spécifier les types de données car les types de données des colonnes seront déterminés par la `SELECT` requête. Si la `SELECT` requête échoue pour une raison quelconque, elle échouera et la table Iceberg ne sera pas créée. Vous pouvez visualiser la structure de vos tables Iceberg en utilisant `SHOW TABLE` : ## SHOW TABLE ``` SHOW TABLE {{}}.{{}} ``` Vous pouvez également utiliser la notation en trois parties avec les catalogues montés automatiquement : ``` SHOW TABLE "{{}}".{{}}.{{}} ``` `SHOW TABLE`affiche l'`CREATE TABLE`instruction de la table Iceberg. La commande affiche les résultats appropriés en fonction du type de table. Voici un exemple de `SHOW TABLE` sortie pour la table Iceberg : ``` CREATE TABLE my_schema.items (id int, price decimal(5, 2)) USING ICEBERG LOCATION 's3://my_s3_bucket/items/' PARTITIONED BY (bucket(16, id)) TABLE PROPERTIES ('compression_type'='snappy') ``` **Note** Pour les tables Amazon S3, étant donné que l'emplacement des tables est géré par le catalogue des tables Amazon S3, la `LOCATION` clause sera omise dans les `SHOW TABLE` résultats. Après avoir créé des tables, vous pouvez ajouter des données en utilisant `INSERT INTO` : ## INSERT INTO ``` INSERT INTO {{}}.{{}} [(column_name [, ...])] VALUES (...) INSERT INTO {{}}.{{}} [(column_name [, ...])] (SELECT query) -- Using three-part notation for S3 table buckets: INSERT INTO "{{}}@s3tablescatalog".{{}}.{{}} [(column_name [, ...])] VALUES (...) INSERT INTO "{{}}@s3tablescatalog".{{}}.{{}} [(column_name [, ...])] (SELECT query) ``` Vous pouvez créer `INSERT INTO` une table Iceberg en utilisant la syntaxe ci-dessus. Si une `VALUES` clause est utilisée, vous fournissez les valeurs des colonnes répertoriées par`column_name`, ou de toutes les colonnes si `column_name` une partie est omise. Lorsque des données sont insérées dans une table partitionnée, les nouvelles lignes sont distribuées conformément à la spécification de partition prédéfinie. Si, pour une raison quelconque, la `SELECT` requête échoue, elle échouera et aucune donnée ne sera insérée dans la table Iceberg. ## DELETE La `DELETE` requête pour la table Iceberg utilise la `DELETE` syntaxe existante dans la table RMS : ``` [ WITH [RECURSIVE] {{common_table_expression}} [, {{common_table_expression}} , ...] ] DELETE [ FROM ] {{iceberg_table}} [ { USING } {{table_name, ...}} ] [ WHERE {{condition}} ] ``` Vous pouvez également utiliser une notation en trois parties pour les compartiments de table S3 : ``` [ WITH [RECURSIVE] {{common_table_expression}} [, {{common_table_expression}} , ...] ] DELETE [ FROM ] "{{}}@s3tablescatalog".{{}}.{{}} [ { USING } {{table_name, ...}} ] [ WHERE {{condition}} ] ``` Ils `{{iceberg_table}}` peuvent être référencés à l'aide du `{{}}.{{}}` formulaire ou utiliser la notation en 3 parties pour le catalogue monté automatiquement. Consultez [Référencement des tables Iceberg dans Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/referencing-iceberg-tables.html). La `USING` clause `{{table_name}}` in the sera utilisée pour joindre la table cible afin de supprimer les lignes satisfaites à la `WHERE` condition. Il `{{table_name}}` peut s'agir d'une table Iceberg ou d'une table Amazon Redshift RMS. Comme Iceberg utilise un schéma de partition caché, l'utilisateur peut utiliser `DELETE` une requête pour supprimer des partitions, obtenant le même effet que `ALTER TABLE ... DROP PARTITION ...` pour les tables Hive. Par exemple, lorsque nous avons partitionné la table Iceberg comme ci-dessous : ``` CREATE TABLE my_external_schema.lineitem (l_item_id int, l_ship_date varchar, ... ) USING ICEBERG LOCATION ... PARTITIONED BY l_ship_date; ``` Ensuite, nous pouvons facilement supprimer une partition en utilisant une requête comme celle-ci : ``` DELETE FROM my_external_schema.lineitem WHERE l_ship_date = '20251231'; ``` Pour de telles requêtes, Amazon Redshift optimisera l'exécution afin de n'effectuer que des opérations sur les métadonnées et de court-circuiter l'exécution. Ainsi, contrairement à une `DELETE` requête normale, la requête de suppression des métadonnées uniquement ne montre pas les étapes d'exécution dans `EXPLAIN` : ``` explain DELETE FROM my_external_schema.lineitem WHERE l_ship_date = '20251231'; QUERY PLAN ------------ "XN Seq Scan Metadata of my_external_schema.lineitem location: "s3://s3-path//table-location" format:ICEBERG (cost=0.00..0.01 rows=0 width=0)" (0 rows) ``` ## UPDATE La syntaxe de `UPDATE` requête pour la table Iceberg est très similaire à la `UPDATE` syntaxe existante pour la table RMS : ``` [ WITH [RECURSIVE] {{common_table_expression}} [, {{common_table_expression}} , ...] ] UPDATE {{iceberg_table}} [ [ AS ] alias ] SET column = { {{expression}} } [,...] [ FROM {{fromlist}} ] [ WHERE {{condition}} ] ``` Vous pouvez également utiliser une notation en trois parties pour les compartiments de table S3 : ``` [ WITH [RECURSIVE] {{common_table_expression}} [, {{common_table_expression}} , ...] ] UPDATE "{{}}@s3tablescatalog".{{}}.{{}} [ [ AS ] alias ] SET column = { {{expression}} } [,...] [ FROM {{fromlist}} ] [ WHERE {{condition}} ] ``` Ils `{{iceberg_table}}` peuvent être référencés à l'aide du `{{}}.{{}}` formulaire ou utiliser la notation en 3 parties pour le catalogue monté automatiquement. Consultez [Référencement des tables Iceberg dans Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/referencing-iceberg-tables.html). Vous pouvez mettre à jour une table en faisant référence aux informations d’autres tables. Répertoriez ces autres tables dans la clause FROM ou utilisez une sous-requête dans le cadre de la condition WHERE. Les tables sources peuvent être des tables Iceberg ou des tables Amazon Redshift RMS. `UPDATE`peut également être exécuté sur une table partitionnée. Lorsque les valeurs `UPDATE` des colonnes appartenant à la spécification de partition actuelle sont modifiées, la nouvelle ligne mise à jour est insérée dans la nouvelle partition en fonction de la valeur récemment mise à jour. Par exemple, lorsque nous avons une table Iceberg partitionnée comme ci-dessous : ``` CREATE TABLE my_external_schema.lineitem (l_item_id int, l_ship_date varchar, ... ) USING ICEBERG LOCATION ... PARTITIONED BY l_ship_date; INSERT INTO my_external_schema.lineitem VALUES (10099, '20251231', ...); ``` Et lorsque nous exécutons la requête de mise à jour ci-dessous : ``` UPDATE my_external_schema.lineitem SET l_ship_date = '20260101' WHERE l_item_id = 10099; ``` nous allons déplacer cette ligne avec `l_item_id` 10099 de la partition `20251231` vers la nouvelle partition`20260101`. Il est également important de noter qu'il est possible qu'il `UPDATE` comporte plusieurs valeurs candidates. Considérez la requête ci-dessous : ``` CREATE TABLE my_ext_schema.t1(x1 int, y1 int) USING ICEBERG LOCATION ...; CREATE TABLE my_ext_schema.t2(x2 int, y2 int) USING ICEBERG LOCATION ...; INSERT INTO my_ext_schema.t1 VALUES (1,10), (2,20), (3,30); INSERT INTO my_ext_schema.t2 VALUES (2,40), (2,50); UPDATE my_ext_schema.t1 SET y1=y2 FROM my_ext_schema.t2 WHERE x1=x2; ``` Dans ce cas, y1 peut être 40 ou 50. Le résultat n'est pas déterministe. Vous pouvez définir le paramètre de configuration `error_on_nondeterministic_update` sur true pour forcer l'erreur de requête dans un tel cas. Cela est cohérent avec le `UPDATE` comportement des tables RMS existantes. Pour en savoir plus, reportez-vous à [error\_on\_nondeterministic\_update](https://docs.aws.amazon.com/redshift/latest/dg/r_error_on_nondeterministic_update.html). ## MERGE La `MERGE` requête fusionne de manière conditionnelle les lignes d'une table source dans une table cible. Elle partage la même syntaxe de `MERGE` requête que la table RMS existante : ``` MERGE INTO {{target_iceberg_table}} USING {{source_table}} [ [ AS ] {{alias}} ] ON {{match_condition}} [ WHEN MATCHED THEN { UPDATE SET {{col_name}} = { {{expr}} } [,...] | DELETE } WHEN NOT MATCHED THEN INSERT [ ( {{col_name}} [,...] ) ] VALUES ( { {{expr}} } [, ...] ) | REMOVE DUPLICATES ] ``` Vous pouvez également utiliser une notation en trois parties pour les compartiments de table S3 : ``` MERGE INTO "{{}}@s3tablescatalog".{{}}.{{}} USING {{source_table}} [ [ AS ] {{alias}} ] ON {{match_condition}} [ WHEN MATCHED THEN { UPDATE SET {{col_name}} = { {{expr}} } [,...] | DELETE } WHEN NOT MATCHED THEN INSERT [ ( {{col_name}} [,...] ) ] VALUES ( { {{expr}} } [, ...] ) | REMOVE DUPLICATES ] ``` Ils `{{target_iceberg_table}}` peuvent être référencés à l'aide du `{{}}.{{}}` formulaire ou utiliser la notation en 3 parties pour le catalogue monté automatiquement. Consultez [Référencement des tables Iceberg dans Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/referencing-iceberg-tables.html). Il `{{source_table}}` peut s'agir d'une table Iceberg ou d'une table Amazon Redshift RMS. Lorsqu'elle `REMOVE DUPLICATES` est utilisée, la `MERGE` commande utilise le mode simplifié. Pour plus de détails sur le mode simplifié, reportez-vous au [document de `MERGE` commande](https://docs.aws.amazon.com/redshift/latest/dg/r_MERGE.html) d'origine. Lors de l'exécution de la `MERGE` requête, Amazon Redshift génère et stocke des fichiers de données intermédiaires dans l'emplacement de la table cible. Ces fichiers seront collectés à la fin de la requête. Pour cette raison, la `MERGE` requête nécessiterait une `DELETE` autorisation sur le compartiment Amazon S3 pour fonctionner correctement. Une erreur d'autorisation insuffisante se produirait en cas d'échec de l'opération de collecte des déchets. Pour les tables Amazon S3, la collecte des déchets est gérée par le service de tables Amazon S3. Par conséquent, aucune `DELETE` autorisation n'est requise pour exécuter `MERGE` la requête. ## DROP TABLE Pour supprimer une table Iceberg du catalogue, utilisez la `DROP TABLE` commande : ``` DROP TABLE {{}}.{{}} ``` Vous pouvez également utiliser la notation en trois parties avec les catalogues montés automatiquement : ``` DROP TABLE "{{}}".{{}}.{{}} ``` La suppression d'une table Iceberg est une opération de métadonnées uniquement. Il supprime l'entrée de AWS Glue Data Catalog table d'un catalogue de tables Amazon S3, s'il s'agit d'une table Amazon S3. Amazon Redshift ne nettoie ni ne supprime aucun fichier de données ou de métadonnées existant à l'emplacement de la table. Vous pouvez utiliser les fonctionnalités AWS Glue et les tables Amazon S3 pour supprimer les fichiers orphelins. Pour AWS Glue, voir [Suppression de fichiers orphelins](https://docs.aws.amazon.com/glue/latest/dg/orphan-file-deletion.html). Pour les tables Amazon S3, consultez la section [Maintenance des tables](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-maintenance.html).