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. # Utilisation de tables Apache Iceberg avec Amazon Redshift **Note** Pour obtenir les meilleures performances lors de l’utilisation des tables Apache Iceberg avec Amazon Redshift, vous devez générer des statistiques de colonne pour les tables à l’aide du AWS Glue. Pour plus d’informations, consultez [Génération de statistiques de colonnes pour les tables Iceberg](https://docs.aws.amazon.com/glue/latest/dg/iceberg-generate-column-stats.html) dans le *Guide du développeur AWS Glue *. Cette rubrique décrit comment utiliser des tables au format Apache Iceberg avec Redshift Spectrum ou Redshift sans serveur. Apache Iceberg est un format performant pour les tables analytiques très volumineuses. Vous pouvez utiliser Redshift Spectrum ou Redshift sans serveur pour interroger des tables Apache Iceberg cataloguées dans le  AWS Glue Data Catalog. Apache Iceberg est un format de table open source pour les lacs de données. Pour en savoir plus, consultez [Apache Iceberg](https://iceberg.apache.org/) dans la documentation Apache Iceberg. Amazon Redshift assure une cohérence transactionnelle dans le cadre de l’interrogation des tables Apache Iceberg. Vous pouvez manipuler les données de vos tables à l’aide de services conformes aux propriétés ACID (atomicité, cohérence, isolation, durabilité) comme Amazon Athena et Amazon EMR tout en exécutant des requêtes avec Amazon Redshift. Amazon Redshift peut utiliser les statistiques de tables stockées dans les métadonnées Apache Iceberg pour optimiser les plans de requêtes et limiter les analyses de fichiers pendant le traitement des requêtes. Avec Amazon Redshift SQL, vous pouvez joindre des tables Redshift à des tables de lac de données. Pour commencer à utiliser des tables Iceberg avec Amazon Redshift : 1. Créez une table Apache Iceberg sur une AWS Glue Data Catalog base de données à l'aide d'un service compatible tel qu'Amazon Athena ou Amazon EMR. Pour créer une table Iceberg à l’aide d’Athena, consultez [Utilisation de tables Apache Iceberg](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg.html) dans le *Guide de l’utilisateur Amazon Athena*. 1. Créez un cluster Amazon Redshift ou un groupe de travail Redshift sans serveur avec un rôle IAM associé qui permet d’accéder à votre lac de données. Pour savoir comment créer des clusters ou des groupes de travail, consultez [Commencer avec les entrepôts de données alloués Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/new-user.html) et [Commencer avec les entrepôts de données Redshift sans serveur](https://docs.aws.amazon.com/redshift/latest/gsg/new-user-serverless.html) dans le *Guide de démarrage Amazon Redshift*. 1. Connectez-vous à votre cluster ou groupe de travail à l’aide de l’éditeur de requêtes v2 ou d’un client SQL tiers. Pour savoir comment vous connecter à l’aide de l’éditeur de requêtes v2, consultez [Connexion à un entrepôt de données Amazon Redshift à l’aide des outils client SQL](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-to-cluster.html) dans le *Guide de gestion Amazon Redshift*. 1. Créez un schéma externe dans votre base de données Amazon Redshift pour une base de données de catalogue de données spécifique qui comprend vos tables Iceberg. Pour obtenir des informations sur la création d’un schéma externe, consultez [Schémas externes dans Amazon Redshift Spectrum](c-spectrum-external-schemas.md). 1. Exécutez des requêtes SQL pour accéder aux tables Iceberg dans le schéma externe que vous avez créé. ## Éléments à prendre en considération lors de l’utilisation de tables Apache Iceberg avec Amazon Redshift Tenez compte des points suivants lorsque vous utilisez Amazon Redshift avec des tables Iceberg : + **Prise en charge des versions d’Iceberg** – Amazon Redshift prend en charge l’exécution de requêtes sur les versions suivantes de tables Iceberg : + La version 1 définit la façon dont les grandes tables analytiques sont gérées en utilisant des fichiers de données immuables. + La version 2 ajoute la possibilité de prendre en charge les mises à jour et les suppressions de niveau ligne tout en laissant les fichiers de données existants inchangés et en gérant les modifications de données de tables à l’aide de fichiers de suppression. Pour connaître la différence entre les tables de version 1 et de version 2, consultez [Format version changes](https://iceberg.apache.org/spec/#appendix-e-format-version-changes) dans la documentation Apache Iceberg. + **Ajout de partitions** – Vous n’avez pas besoin d’ajouter de partitions manuellement pour vos tables Apache Iceberg. Les nouvelles partitions au niveau des tables Apache Iceberg sont automatiquement détectées par Amazon Redshift et aucune opération manuelle n’est nécessaire pour mettre à jour les partitions dans la définition de table. Les modifications éventuellement apportées dans la spécification des partitions sont aussi appliquées automatiquement à vos requêtes sans aucune intervention de l’utilisateur. + **Ingestion des données Iceberg dans Amazon Redshift** – Vous pouvez utiliser les commandes INSERT INTO ou CREATE TABLE AS pour importer les données de votre table Iceberg dans une table Amazon Redshift locale. Pour l’heure, vous ne pouvez pas utiliser la commande COPY pour ingérer le contenu d’une table Apache Iceberg dans une table Amazon Redshift locale. + **Vues matérialisées** : vous pouvez créer des vues matérialisées pour les tables Apache Iceberg comme pour n’importe quelle autre table externe dans Amazon Redshift. Les éléments à prendre en considération pour les autres formats de table de lac de données valent également pour les tables Apache Iceberg. La réécriture automatique des requêtes et les vues matérialisées automatiques sur les tables de lac de données ne sont actuellement pas prises en charge. + AWS Lake Formation contrôle **d'accès détaillé : Amazon Redshift AWS Lake Formation prend en charge le contrôle** d'accès détaillé sur les tables Apache Iceberg. + **Paramètres de gestion des données définis par l’utilisateur** – Amazon Redshift prend en charge les paramètres de gestion des données définis par l’utilisateur pour les tables Apache Iceberg. L’utilisation de paramètres de gestion des données définis par l’utilisateur sur des fichiers existants permet de personnaliser les données interrogées dans les tables externes afin d’éviter des erreurs d’analyse. Ces paramètres offrent la possibilité de gérer les incohérences entre le schéma de table et les données réelles des fichiers. Vous pouvez également utiliser les paramètres de gestion des données définis par l’utilisateur pour les tables Apache Iceberg. + **Requêtes Time Travel** – Les requêtes Time Travel ne sont actuellement pas prises en charge avec les tables Apache Iceberg. + **Tarification** : lorsque vous accédez à des tables Iceberg depuis un cluster, vous êtes facturé au tarif Redshift Spectrum. Lorsque vous accédez à des tables Iceberg depuis un groupe de travail, vous êtes facturé au tarif Redshift sans serveur. Pour en savoir plus sur la tarification Redshift Spectrum et Redshift sans serveur, consultez [Tarification Amazon Redshift](https://aws.amazon.com/redshift/pricing/). + **Mise en cache des métadonnées** : la mise en cache des métadonnées suppose que les fichiers de métadonnées sont immuables conformément à la [spécification Iceberg.](https://iceberg.apache.org/spec/#file-system-operations) L’immuabilité des fichiers de métadonnées est une exigence à l’intégrité des données dans Amazon Redshift. + **Identité fédérée — L'identité** fédérée n'est pas prise en charge lors de l'écriture dans les tables Apache Iceberg. Cela inclut l'utilisation du mot clé SESSION pour le paramètre IAM\$1ROLE lors de la création de schémas externes. Pour plus d'informations sur les paramètres IAM\$1ROLE, consultez [CREATE](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_SCHEMA.html) EXTERNAL SCHEMA. # Types de données pris en charge avec les tables Apache Iceberg Cette rubrique décrit les types de données pris en charge que Redshift Spectrum peut lire à partir de tables au format Apache Iceberg. Amazon Redshift peut interroger les tables Iceberg qui contiennent les types de données suivants : ``` binary boolean date decimal double float int list long map string struct timestamp without time zone ``` Lorsque vous créez et définissez une table Iceberg, utilisez les noms des types de données Amazon Redshift dans l'instruction SQL. Redshift les associe automatiquement aux types d'icebergs correspondants. Pour en savoir plus sur les types de données Iceberg, consultez [Schemas for Iceberg](https://iceberg.apache.org/docs/latest/schemas/) dans la documentation Apache Iceberg. Lors de la lecture des tables Iceberg, les types de données Iceberg sont mappés dans les types de données Redshift, comme indiqué dans le tableau ci-dessous : **** | Type Iceberg | Type Amazon Redshift | Remarques | | --- | --- | --- | | boolean | boolean | - | | - | tinyint | Non pris en charge pour les tables Iceberg. | | - | smallint | Non pris en charge pour les tables Iceberg. | | int | int | - | | long | bigint | - | | double | double precision | - | | float | real | - | | decimal(P, S) | decimal(P, S) | P est la précision, S est l’échelle. | | - | char | Non pris en charge pour les tables Iceberg. | | string | varchar(16384) | Les chaînes dont la taille est supérieure à 16384 sont tronquées à 16384. | | binary | varbyte(64000) | - | | date | date | - | | time | - | - | | timestamp | timestamp | - | | timestamptz | timestampz | - | | list | SUPER | - | | map | SUPER | - | | struct<...> | SUPER | - | | fixed(L) | - | Le type fixed(L) n’est actuellement pas pris en charge dans Redshift Spectrum. | | uuid | - | Le type uuid n’est actuellement pas pris en charge dans Redshift Spectrum. | | variant | - | Amazon Redshift ne prend pas en charge Iceberg V3. | | geometry | - | Amazon Redshift ne prend pas en charge Iceberg V3. | | geography | - | Amazon Redshift ne prend pas en charge Iceberg V3. | | timestamp\$1ns | - | Amazon Redshift ne prend pas en charge Iceberg V3. | | timestamptz\$1ns | - | Amazon Redshift ne prend pas en charge Iceberg V3. | | Unknown | - | Amazon Redshift ne prend pas en charge Iceberg V3. | Les types de données suivants sont pris en charge lors de la création de tables Iceberg à partir de Redshift. Les types de données Redshift sont mappés dans les types de données Iceberg, comme indiqué dans le tableau suivant. **** | Type Amazon Redshift | Alias Amazon Redshift | Type Iceberg | Remarques | | --- | --- | --- | --- | | integer | int, int4 | int | - | | bigint | int8 | long | - | | decimal | numeric | decimal(p,S) | - | | real | float4 | float | - | | double precision | float8, float | double | - | | varchar | charactter varying,nvarchar, text | string | Le type de varchar(n) données n'est pas pris en charge lors de la création d'une table Iceberg. | | date | - | date | - | | timestamp | - | timestamp | - | | timestamptz | - | timestamptz | - | | boolean | - | boolean | - | Lorsque vous écrivez dans des tables Iceberg, outre les types de données mentionnés dans le tableau précédent, certains types de données sources sont promus vers leurs types Iceberg compatibles, comme indiqué dans le tableau suivant. | Type Amazon Redshift | Type Iceberg | | --- | --- | | `tinyint` | `int` | | `smallint` | `int` | | `varchar(n)` | `string` | Toute tentative d'utilisation de types de données non pris en charge entraînera des erreurs de syntaxe. Lorsque vous créez une table Iceberg avec `CREATE TABLE AS SELECT` clause, vous pouvez ajouter un casting explicite pour contourner la différence de type. Supposons, par exemple, que vous disposiez d'une table Redshift RMS avec le schéma suivant : ``` CREATE TABLE rms_t (c1 int, c2 char(20)); ``` Si vous souhaitez créer une table Iceberg en utilisant `rms_t` comme source, vous avez besoin d'un casting explicite pour la `c2` colonne, car le `varchar(n)` type n'est pas pris en charge : ``` CREATE TABLE ext_schema.iceberg_t AS SELECT c1, c2::varchar FROM rms_t; ``` Pour en savoir plus sur les types de données Amazon Redshift, consultez [Types de données](c_Supported_data_types.md). # Référencement des tables Iceberg dans Amazon Redshift Amazon Redshift propose plusieurs méthodes pour référencer les tables Apache Iceberg stockées dans votre lac de données. Vous pouvez utiliser des schémas externes pour créer des références aux bases de données du catalogue de données contenant des tables Iceberg, ou utiliser une notation en trois parties pour accéder directement aux catalogues montés automatiquement. ## Utilisation de schémas externes pour référencer les tables Iceberg Les schémas externes permettent de référencer les tables de votre catalogue de données depuis Amazon Redshift. Lorsque vous créez un schéma externe, vous établissez une connexion entre votre base de données Amazon Redshift et une base de données Data Catalog spécifique qui contient vos tables Iceberg. Pour créer un schéma externe pour les tables Iceberg : ``` CREATE EXTERNAL SCHEMA schema_name FROM DATA CATALOG DATABASE 'glue_database_name' IAM_ROLE 'arn:aws:iam::account-id:role/role-name'; ``` Après avoir créé le schéma externe, vous pouvez interroger les tables Iceberg à l'aide d'une notation en deux parties : ``` SELECT * FROM schema_name.iceberg_table_name; ``` Vous pouvez également associer des tables Iceberg à des tables Amazon Redshift locales : ``` SELECT r.customer_id, i.order_date, r.customer_name FROM local_customers r JOIN schema_name.iceberg_orders i ON r.customer_id = i.customer_id; ``` ## Utilisation de la notation en trois parties avec des catalogues montés automatiquement La notation en trois parties vous permet de référencer directement des tables dans des catalogues montés automatiquement sans créer de schémas externes. Cette méthode est particulièrement utile lorsque vous travaillez avec des compartiments de table Amazon S3 fédérés avec. AWS Lake Formation Pour plus d'informations sur la configuration du montage automatique du catalogue de données, consultez [Simplifier l'accès aux objets externes dans Amazon Redshift à l'aide du montage automatique du](https://aws.amazon.com/blogs/big-data/simplify-external-object-access-in-amazon-redshift-using-automatic-mounting-of-the-aws-glue-data-catalog/). AWS Glue Data Catalog La syntaxe de la notation en trois parties est la suivante : ``` "catalog_name".database_name.table_name ``` Par exemple, pour interroger une table Iceberg dans un catalogue de tables Amazon S3 monté automatiquement : ``` SELECT * FROM "my_table_bucket@s3tablescatalog".my_database.my_iceberg_table; ``` Pour plus d'informations sur l'intégration des compartiments de tables Amazon S3 à Amazon Redshift, [consultez la section Intégration des tables S3 à Amazon Redshift](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-integrating-redshift.html) dans le guide de l'utilisateur Amazon *S3*. Vous pouvez également utiliser l'`USE`instruction pour définir un catalogue et une base de données par défaut : ``` USE "my_table_bucket@s3tablescatalog".my_database; SELECT * FROM my_iceberg_table; ``` Pour définir un chemin de recherche pour la résolution du schéma, procédez comme suit : ``` USE "my_table_bucket@s3tablescatalog"; SET search_path TO my_database; SELECT * FROM my_iceberg_table; ``` ## Bonnes pratiques pour référencer les tables Iceberg Tenez compte des meilleures pratiques suivantes lorsque vous référencez des tables Iceberg dans Amazon Redshift : + **Utiliser des noms de schéma descriptifs** : lors de la création de schémas externes, utilisez des noms qui indiquent clairement la source et le but des données, tels que `sales_data_lake` ou`customer_analytics`. + **Tirez parti des statistiques des tables** : assurez-vous que les statistiques des colonnes sont générées pour vos tables Iceberg AWS Glue afin d'optimiser les performances des requêtes. Amazon Redshift utilise ces statistiques pour la planification et l'optimisation des requêtes. + **Tenez compte de l'actualité des données** : les tables Iceberg peuvent être mises à jour par d'autres services pendant que vous les interrogez. Amazon Redshift assure la cohérence transactionnelle, vous garantissant ainsi un instantané cohérent des données lors de l'exécution de votre requête. + **Utilisez les autorisations IAM appropriées** : assurez-vous que votre cluster ou groupe de travail Amazon Redshift dispose des autorisations IAM nécessaires pour accéder aux emplacements Amazon S3 où sont stockées vos tables Iceberg, ainsi qu'aux métadonnées du catalogue de données. + **Surveillez les performances des requêtes** : utilisez les fonctionnalités de surveillance des requêtes d'Amazon Redshift pour suivre les performances des requêtes par rapport aux tables Iceberg et les optimiser selon les besoins. ## Modèles de référencement courants Les exemples suivants illustrent les modèles courants de référencement des tables Iceberg : **Agrégation des données dans plusieurs tables Iceberg :** ``` SELECT region, SUM(sales_amount) as total_sales, COUNT(*) as transaction_count FROM data_lake.sales_transactions WHERE transaction_date >= '2024-01-01' GROUP BY region ORDER BY total_sales DESC; ``` **Joindre des tables Iceberg à des tables Amazon Redshift locales :** ``` SELECT c.customer_name, c.customer_tier, SUM(o.order_amount) as total_orders FROM customers c JOIN data_lake.order_history o ON c.customer_id = o.customer_id WHERE o.order_date >= CURRENT_DATE - INTERVAL '30 days' GROUP BY c.customer_name, c.customer_tier; ``` **Utilisation de la notation en trois parties avec des requêtes complexes :** ``` WITH recent_orders AS ( SELECT customer_id, order_date, order_amount FROM "analytics_bucket@s3tablescatalog".ecommerce.orders WHERE order_date >= CURRENT_DATE - INTERVAL '7 days' ) SELECT customer_id, COUNT(*) as order_count, AVG(order_amount) as avg_order_value FROM recent_orders GROUP BY customer_id HAVING COUNT(*) > 1; ``` # Écrire dans des tables Apache Iceberg Avec Amazon Redshift, vous pouvez créer et écrire dans des tables Apache Iceberg stockées dans des compartiments de tables Amazon S3 et Amazon S3. L'écriture de données Iceberg directement depuis Amazon Redshift rationalise la gestion de vos données en éliminant les outils supplémentaires. Les tables Iceberg doivent être enregistrées auprès de AWS Glue Data Catalog. Vous pouvez utiliser l'architecture Lakehouse avec les tables Apache Iceberg tout en tirant parti des puissantes analyses SQL d'Amazon Redshift pour les entrepôts et les lacs. Vous bénéficiez également d'un accès immédiat aux fonctionnalités avancées d'Amazon Redshift, telles que les vues matérialisées sur vos tables Iceberg, ce qui améliore considérablement vos capacités d'analyse sans ajouter de complexité. Les écritures Iceberg sont prises en charge à la fois sur les clusters provisionnés par Amazon Redshift et sur les instances Amazon Redshift Serverless. **Topics** + [Commandes SQL](iceberg-writes-sql-syntax.md) + [Sémantique des transactions](iceberg-writes-transaction-semantics.md) + [Bonnes pratiques](iceberg-writes-best-practices.md) # 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. Toutes les autres instructions SQL, telles que`DELETE`,, et `UPDATE` `MERGE``ALTER TABLE`, ne sont pas encore prises en charge dans les tables Iceberg. Les sections suivantes présentent la syntaxe SQL permettant de créer, d'insérer 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) + [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, consultez [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. Il est possible que vous accédiez à `INSERT INTO` 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). Pour supprimer une table Iceberg du catalogue, utilisez la `DROP TABLE` commande : ## DROP TABLE ``` 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). # Sémantique des transactions Les requêtes d'écriture Redshift Iceberg prennent en charge l'isolation ACID et les instantanés. Les transactions d'écriture garantissent l'atomicité et ne produisent pas de mises à jour partielles en cas d'échec inattendu d'une requête. Plusieurs transactions Iceberg peuvent s'exécuter simultanément, et si deux transactions tentent de modifier simultanément la même table ou partition, la validation de la transaction échoue. Cela garantit l'intégrité des données. Dans ce cas, vous devez résoudre les conflits manuellement et réexécuter les requêtes ayant échoué. Amazon Redshift ne réessaie pas automatiquement de résoudre les conflits. Une seule requête d'écriture Iceberg est toujours traitée comme une seule transaction de validation automatique. Lorsqu'une requête d'écriture Iceberg, telle qu'une requête CREATE ou INSERT, est incluse dans un bloc de transaction explicite, aucune autre requête ne peut être exécutée dans le même bloc de transaction. La transaction échouera. Voici quelques exemples. Le premier exemple montre qu'une seule requête d'instruction est toujours validée automatiquement une fois la requête terminée. Dans ce scénario, vous créez une nouvelle table de commandes client : ``` CREATE TABLE sales_schema.orders ( order_id int, customer_id int, order_date date, total_amount decimal(10,2) ) USING ICEBERG LOCATION 's3://my-data-lake/sales/orders/'; ``` Cet exemple est un bloc de transaction explicite permettant d'insérer une commande client à l'aide d'une notation en trois parties pour un compartiment de table S3. La transaction n'est pas validée automatiquement après la requête INSERT, mais valide et insère les données de commande à l'aide de la commande COMMIT : ``` BEGIN; INSERT INTO "analytics_bucket@s3tablescatalog".sales_db.orders VALUES (12345, 9876, '2024-10-30', 299.99); COMMIT; ``` Cet exemple est un scénario explicite d'annulation d'un bloc de transactions dans lequel vous testez l'insertion d'une commande mais décidez de l'annuler. La transaction n'est pas validée automatiquement après la requête INSERT, mais est annulée à l'aide de la commande ROLLBACK sans insérer l'ordre de test. ``` BEGIN; INSERT INTO sales_schema.orders VALUES (12346, 5432, '2024-10-30', 150.75); ROLLBACK; ``` Ce dernier exemple montre comment, lorsque vous essayez d'exécuter une autre instruction dans le même bloc de transaction que la requête INSERT, la transaction échoue sans insérer les données de commande. Dans ce scénario, vous essayez d'insérer une commande et d'interroger immédiatement la table : ``` BEGIN; INSERT INTO sales_schema.orders VALUES (12347, 7890, '2024-10-30', 425.50); SELECT * FROM sales_schema.orders WHERE order_id = 12347; ``` La seule exception à cette règle est l'`DROP TABLE`instruction, qui se comporte toujours comme une instruction de validation automatique et ne peut pas être exécutée dans un bloc de transaction explicite. Cela permet de conserver le même comportement que `DROP TABLE` sur une table externe. Pour plus d'informations, consultez [DROP TABLE](https://docs.aws.amazon.com/redshift/latest/dg/r_DROP_TABLE.html). **Note** L'écriture dans Iceberg SQLs ne peut pas être exécutée à partir d'une procédure stockée. # Bonnes pratiques Tenez compte des meilleures pratiques suivantes lorsque vous écrivez dans une table Apache Iceberg : + Pour les petites écritures fréquentes ou les charges de travail de streaming, pensez à utiliser les fonctionnalités de compactage fournies par AWS Glue Data Catalog les tables Amazon S3 afin d'optimiser la taille des fichiers pour les lectures. + La `DROP TABLE` commande annule l'enregistrement de la table du AWS Glue Data Catalog catalogue de tables Amazon S3, mais vos fichiers sont conservés. 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).