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 des transactions Athena ACID Le terme « transactions ACID » fait référence à un ensemble de propriétés ([atomicité](https://en.wikipedia.org/wiki/Atomicity_(database_systems)), [cohérence](https://en.wikipedia.org/wiki/Consistency_(database_systems)), [isolation](https://en.wikipedia.org/wiki/Isolation_(database_systems)) et [durabilité](https://en.wikipedia.org/wiki/Durability_(database_systems))) qui garantissent l'intégrité des données dans les transactions de bases de données. Les transactions ACID permettent à plusieurs utilisateurs d'ajouter et de supprimer simultanément et en toute fiabilité des objets Simple Storage Service (Amazon S3) de manière atomique, tout en isolant les requêtes existantes en maintenant la cohérence de lecture pour les requêtes contre le lac de données. Les transactions Athena ACID ajoutent au langage de manipulation des données (DML) Athena SQL la prise en charge d'une table unique pour les opérations d'insertion, de suppression, de mise à jour et Time Travel. Vous et plusieurs utilisateurs simultanés pouvez utiliser les transactions Athena ACID pour apporter des modifications fiables, au niveau des lignes, aux données Amazon S3. Les transactions Athena gèrent automatiquement la sémantique et la coordination du verrouillage et ne nécessitent pas de solution de verrouillage d'enregistrement personnalisée. Les transactions Athena ACID et la syntaxe SQL familière simplifient les mises à jour de vos données commerciales et réglementaires. Par exemple, pour répondre à une demande d'effacement de données, vous pouvez effectuer une opération SQL `DELETE`. Pour effectuer des corrections d'enregistrement manuelles, vous pouvez utiliser une seule instruction `UPDATE`. Pour récupérer des données qui ont été récemment supprimées, vous pouvez émettre des requêtes Time Travel en utilisant une instruction `SELECT`. Parce qu'elles sont basées sur des formats de tables partagées, les transactions Athena ACID sont compatibles avec d'autres services et moteurs tels que [Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-what-is-emr.html) et [Apache Spark](https://spark.apache.org/) qui prennent également en charge les formats de tables partagés. Les transactions Athena sont disponibles via la console Athena, les opérations API et les pilotes ODBC et JDBC. **Topics** + [Interrogation des tables Linux Foundation Delta Lake](delta-lake-tables.md) + [Interrogation de jeux de données Apache Hudi](querying-hudi.md) + [Interrogation des tables Apache Iceberg](querying-iceberg.md) # Interrogation des tables Linux Foundation Delta Lake Linux Foundation [Delta Lake](https://delta.io/) est un format de table pour l'analytique du big data. Vous pouvez utiliser Amazon Athena pour lire directement les tables Delta  Lake stockées dans Amazon S3 sans avoir à générer de fichiers manifestes ou à exécuter l'instruction `MSCK REPAIR`. Le format Delta Lake stocke les valeurs minimales et maximales par colonne de chaque fichier de données. L'implémentation Athena utilise ces informations pour permettre le saut de fichier sur les prédicats afin d'éliminer les fichiers non désirés de la considération. ## Considérations et restrictions Les considérations et restrictions suivantes s’appliquent à la prise en charge de Delta Lake dans Athena : + **Tableaux avec AWS Glue catalogue uniquement** : le support natif de Delta Lake n'est pris en charge que par le biais des tables enregistrées auprès de AWS Glue. Si une table Delta Lake est enregistrée dans un autre métastore, vous pouvez la conserver et la traiter comme votre métastore primaire. Les métadonnées de Delta Lake étant stockées dans le système de fichiers (par exemple, dans Amazon S3) plutôt que dans le métastore, Athena n'a besoin que de la propriété location in AWS Glue pour lire vos tables Delta Lake. + **Moteur V3 uniquement** : les requêtes Delta Lake ne sont prises en charge que par la version 3 du moteur Athena. Vous devez vous assurer que le groupe de travail que vous créez est configuré pour utiliser la version 3 du moteur Athena. + **Pas de prise en charge du voyage dans le temps** : il n'y a pas de prise en charge des requêtes qui utilisent les capacités de voyage dans le temps de Delta Lake. + **Lecture seule** : l'écriture d'instructions DML comme `UPDATE`, `INSERT` ou `DELETE` n'est pas prise en charge. + **Prise en charge de Lake Formation** : l'intégration de Lake Formation est disponible pour les tables Delta Lake dont le schéma est synchronisé avec AWS Glue. Pour plus d'informations, consultez les [AWS Lake Formation sections Utilisation avec Amazon Athena](https://docs.aws.amazon.com/lake-formation/latest/dg/athena-lf.html) et [Configuration des autorisations pour une table Delta Lake](https://docs.aws.amazon.com/lake-formation/latest/dg/set-up-delta-table.html) dans le guide du *AWS Lake Formation développeur*. + **Prise en charge limitée de DDL** : les instructions DDL suivantes sont prises en charge : `CREATE EXTERNAL TABLE`, `SHOW COLUMNS`, `SHOW TBLPROPERTIES`, `SHOW PARTITIONS`, `SHOW CREATE TABLE` et `DESCRIBE`. Pour plus d'informations sur l'utilisation de l'instruction `CREATE EXTERNAL TABLE`, voir la rubrique [Prise en main des tables Delta Lake](delta-lake-tables-getting-started.md). + **Omission des objets Amazon Glacier non prise en charge** : si des objets de la table Linux Foundation Delta Lake appartiennent à une classe de stockage Amazon Glacier, la définition de la propriété de table `read_restored_glacier_objects` sur `false` n’a aucun effet. Par exemple, supposons que vous exécutiez la commande suivante : ``` ALTER TABLE table_name SET TBLPROPERTIES ('read_restored_glacier_objects' = 'false') ``` Pour les tables Iceberg et Delta Lake, la commande produit l'erreur Unsupported table property key: read\$1restored\$1glacier\$1objects. Pour les tables Hudi, la commande `ALTER TABLE` ne génère pas d’erreur, mais les objets Amazon Glacier ne sont toujours pas ignorés. L'exécution de requêtes `SELECT` après la commande `ALTER TABLE` continue de renvoyer tous les objets. + **Tables chiffrées** : Athena ne prend pas en charge la lecture native des tables Delta Lake chiffrées avec CSE-KMS. Cela concerne les instructions SELECT et DDL. ### Gestion des versions de Delta Lake et Athena Athena n’utilise pas la [gestion des versions](https://docs.delta.io/latest/releases.html) mentionnée dans la documentation Delta Lake. Basez-vous sur les deux caractéristiques suivantes pour déterminer si vos tables Delta Lake sont compatibles avec Athena : + **Version de lecture** : chaque table Delta Lake dispose d’une version de lecture. Elle est actuellement comprise entre 1 et 3. Les requêtes portant sur une table dont la version de lecture n’est pas prise en charge par Athena échoueront. + **Caractéristiques de la table** — Chaque table Delta Lake peut également déclarer un ensemble de reader/writer fonctionnalités. La prise en charge de Delta Lake par Athena étant en lecture seule, la compatibilité des fonctionnalités d’écriture de table ne s’applique pas. Cependant, les requêtes portant sur des tables dont les fonctionnalités de lecture de table ne sont pas prises en charge échoueront. Le tableau suivant présente les versions et les fonctionnalités de lecture de table Delta Lake prises en charge par Athena. **** | Type de requête | Versions de lecture prises en charge | Fonctionnalités de lecture prises en charge | | --- | --- | --- | | DQL (instructions SELECT) | <= 3 | [Mappage de colonnes](https://docs.delta.io/latest/delta-column-mapping.html), [timestampNtz](https://github.com/delta-io/delta/blob/master/PROTOCOL.md#timestamp-without-timezone-timestampntz), [vecteurs de suppression](https://docs.delta.io/latest/delta-deletion-vectors.html) | | DDL | <= 1 | Non applicable. Les fonctionnalités de lecture peuvent être déclarées uniquement sur les tables présentant une version de lecture 2 ou supérieure. | + Pour une liste des fonctionnalités de la table Delta Lake, voir [Noms de fonctionnalités valides dans les fonctionnalités de la table](https://github.com/delta-io/delta/blob/master/PROTOCOL.md#valid-feature-names-in-table-features) sur GitHub .com + Pour une liste des fonctionnalités de Delta Lake par version de protocole, voir [Fonctionnalités par version de protocole](https://docs.delta.io/latest/versioning.html#features-by-protocol-version) sur GitHub .com. Pour créer dans Athena une table Delta Lake ayant une version de lecture supérieure à 1, consultez [Synchronisation des métadonnées Delta Lake](delta-lake-tables-syncing-metadata.md). **Topics** + [Considérations et restrictions](#delta-lake-tables-considerations-and-limitations) + [Types de données de colonne pris en charge](delta-lake-tables-supported-data-types-columns.md) + [Prise en main des tables Delta Lake](delta-lake-tables-getting-started.md) + [Interrogation des tables Delta Lake avec SQL](delta-lake-tables-querying.md) + [Synchronisation des métadonnées Delta Lake](delta-lake-tables-syncing-metadata.md) + [Ressources supplémentaires](delta-lake-tables-additional-resources.md) # Types de données de colonne pris en charge Cette section décrit les types de données pris en charge pour les colonnes non partitionnées et partitionnées. ## Prise en charge des types de données de colonnes non-partition Pour les colonnes non-partition, tous les types de données pris en charge par Athena, à l'exception de `CHAR`, sont pris en charge (`CHAR` n'est pas pris en charge par le protocole Delta Lake lui-même). Les types de données pris en charge sont les suivants : ``` boolean tinyint smallint integer bigint double float decimal varchar string binary date timestamp array map struct ``` ## Prise en charge des types de données de colonnes partition Pour les colonnes de type partition, Athena prend en charge les tables avec les types de données suivants : ``` boolean integer smallint tinyint bigint decimal float double date timestamp varchar ``` Pour de plus amples informations sur les types de données dans Athena, voir [Types de données dans Amazon Athena](data-types.md). # Prise en main des tables Delta Lake Pour pouvoir être interrogée, votre table Delta Lake doit exister dans. AWS Glue Si votre table se trouve dans Amazon S3 mais pas dans AWS Glue, exécutez une `CREATE EXTERNAL TABLE` instruction en utilisant la syntaxe suivante. Si votre table existe déjà dans AWS Glue (par exemple, parce que vous utilisez Apache Spark ou un autre moteur AWS Glue), vous pouvez ignorer cette étape. Notez l'omission des définitions de colonnes, de SerDe la bibliothèque et des autres propriétés de table. Contrairement aux tables Hive traditionnelles, les métadonnées des tables Delta Lake sont déduites du journal des transactions de Delta Lake et synchronisées directement avec. AWS Glue ``` CREATE EXTERNAL TABLE [db_name.]table_name LOCATION 's3://amzn-s3-demo-bucket/your-folder/' TBLPROPERTIES ('table_type' = 'DELTA') ``` **Note** Cette instruction n’est pas compatible avec les compartiments S3 pour lesquels le paiement par le demandeur est activé. Pour créer une table Delta Lake avec un compartiment S3 pour lequel le paiement par le demandeur est activé, suivez la procédure décrite dans [Synchronisation des métadonnées Delta Lake](delta-lake-tables-syncing-metadata.md) avec une instruction DDL. Pour les tables Delta Lake, les instructions `CREATE TABLE` qui comprennent plus que les propriétés `LOCATION` et `table_type` ne sont pas autorisées. # Interrogation des tables Delta Lake avec SQL Pour interroger une table Delta Lake, utilisez la syntaxe SQL `SELECT` standard : ``` [ WITH with_query [, ...] ]SELECT [ ALL | DISTINCT ] select_expression [, ...] [ FROM from_item [, ...] ] [ WHERE condition ] [ GROUP BY [ ALL | DISTINCT ] grouping_element [, ...] ] [ HAVING condition ] [ { UNION | INTERSECT | EXCEPT } [ ALL | DISTINCT ] select ] [ ORDER BY expression [ ASC | DESC ] [ NULLS FIRST | NULLS LAST] [, ...] ] [ OFFSET count [ ROW | ROWS ] ] [ LIMIT [ count | ALL ] ] ``` Pour plus d'informations sur la syntaxe `SELECT`, voir [SELECT](select.md) dans la documentation d'Athena. Le format Delta Lake stocke les valeurs minimales et maximales par colonne de chaque fichier de données. Athena utilise ces informations pour permettre le saut de fichiers sur les prédicats afin d'éliminer les fichiers inutiles de la considération. # Synchronisation des métadonnées Delta Lake Athena synchronise les métadonnées des tables, y compris le schéma, les colonnes de partition et les propriétés des tables, AWS Glue si vous utilisez Athena pour créer votre table Delta Lake. Au fil du temps, ces métadonnées peuvent perdre leur synchronisation avec les métadonnées de la table sous-jacente dans le journal des transactions. Pour garder votre table à jour, vous pouvez choisir l'une des options suivantes : + Utilisez le AWS Glue crawler pour les tables Delta Lake. Pour plus d'informations, consultez les sections [Présentation de la prise en charge native des tables Delta Lake avec AWS Glue les robots](https://aws.amazon.com/blogs/big-data/introducing-native-delta-lake-table-support-with-aws-glue-crawlers/) d'exploration dans le *blog AWS Big Data* et [Planification d'un AWS Glue robot d'exploration](https://docs.aws.amazon.com/glue/latest/dg/schedule-crawler.html) dans le guide du AWS Glue développeur. + Annulez et recréez la table dans Athena. + Utilisez le SDK, la CLI ou AWS Glue la console pour mettre à jour manuellement le schéma dans AWS Glue. Notez que les fonctionnalités suivantes nécessitent que votre AWS Glue schéma ait toujours le même schéma que le journal des transactions : + Lake Formation + Vues + Filtres de lignes et de colonnes Si votre flux de travail ne nécessite aucune de ces fonctionnalités et que vous préférez ne pas conserver cette compatibilité, vous pouvez utiliser le `CREATE TABLE` DDL dans Athena, puis ajouter le chemin Amazon S3 en SerDe tant que paramètre. AWS Glue ## Créez une table Delta Lake à l'aide de l'Athena et des consoles AWS Glue Vous pouvez utiliser la procédure suivante pour créer une table Delta Lake avec l'Athena et AWS Glue les consoles. **Pour créer une table Delta Lake à l'aide de l'Athena et des consoles AWS Glue** 1. Ouvrez la console à l'adresse [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Dans l'éditeur de requêtes Athena, utilisez l'instruction DDL suivante pour créer votre table Delta Lake. Notez que lorsque vous utilisez cette méthode, la valeur de `TBLPROPERTIES` doit être `'spark.sql.sources.provider' = 'delta'` et non `'table_type' = 'delta'`. Notez que ce même schéma (avec une seule colonne nommée `col` de type `array`) est inséré lorsque vous utilisez Apache Spark (Athena pour Apache Spark) ou la plupart des autres moteurs pour créer votre table. ``` CREATE EXTERNAL TABLE [db_name.]table_name(col array) LOCATION 's3://amzn-s3-demo-bucket/your-folder/' TBLPROPERTIES ('spark.sql.sources.provider' = 'delta') ``` 1. Ouvrez la AWS Glue console à l'adresse [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/). 1. Dans le panneau de navigation, choisissez **Catalogue de données**, **Tables**. 1. Dans la liste des tables, choisissez le lien correspondant à votre table. 1. Sur la page de la table, choisissez **Actions**, **Modifier la table**. 1. Dans la section **Paramètres Serde**, ajoutez la clé **path** avec la valeur **s3://amzn-s3-demo-bucket/*your-folder*/**. 1. Choisissez **Enregistrer**. ## Créez une table Delta Lake à l'aide du AWS CLI Pour créer une table Delta Lake à l'aide de AWS CLI, entrez une commande comme celle-ci. ``` aws glue create-table --database-name dbname \ --table-input '{"Name" : "tablename", "StorageDescriptor":{ "Columns" : [ { "Name": "col", "Type": "array" } ], "Location" : "s3://amzn-s3-demo-bucket//", "SerdeInfo" : { "Parameters" : { "serialization.format" : "1", "path" : "s3://amzn-s3-demo-bucket//" } } }, "PartitionKeys": [], "TableType": "EXTERNAL_TABLE", "Parameters": { "EXTERNAL": "TRUE", "spark.sql.sources.provider": "delta" } }' ``` # Ressources supplémentaires *Pour une discussion sur l'utilisation des tables Delta Lake avec Athena AWS Glue et leur interrogation avec Athena, [voir Gérer les opérations de données UPSERT à l'aide de l'open source Delta Lake AWS Glue et sur le blog](https://aws.amazon.com/blogs/big-data/handle-upsert-data-operations-using-open-source-delta-lake-and-aws-glue/) Big Data.AWS * # Interrogation de jeux de données Apache Hudi [https://hudi.incubator.apache.org/](https://hudi.incubator.apache.org/) est un cadre de gestion de données open source qui simplifie le traitement progressif des données. Les actions d'insertion, de mise à jour, d'insertion ascendante et de suppression au niveau des registres sont traitées de manière beaucoup plus granulaire, ce qui réduit les frais généraux. `Upsert` désigne la possibilité d'insérer des registres dans un jeu de données existant s'ils n'existent pas encore ou de les mettre à jour s'ils existent déjà. Hudi traite les événements d'insertion et de mise à jour des données sans créer de nombreux petits fichiers qui peuvent entraîner des problèmes de performance pour les analyses. Apache Hudi suit automatiquement les modifications et fusionne les fichiers afin qu'ils conservent une taille optimale. Cela évite de devoir créer des solutions personnalisées qui contrôlent et réécrivent de nombreux petits fichiers en un nombre réduit de gros fichiers. Les jeux de données Hudi sont adaptés pour les cas d'utilisation suivants : + Conformité aux réglementations relatives à la protection de la vie privée, comme le [Règlement général sur la protection des données](https://en.wikipedia.org/wiki/General_Data_Protection_Regulation) (RGPD) et [La loi californienne sur la protection de la vie privée des consommateurs](https://en.wikipedia.org/wiki/California_Consumer_Privacy_Act) (CCPA), qui font respecter le droit des personnes à supprimer leurs informations personnelles ou à modifier la manière dont leurs données sont utilisées. + Utilisation des données de streaming provenant de capteurs et d'autres appareils IoT (Internet des objets) nécessitant des événements d'insertion et de mise à jour spécifiques. + Mise en œuvre d'un [système de capture de données modifiées (CDC, Change Data Capture)](https://en.wikipedia.org/wiki/Change_data_capture). Un jeu de données Hudi peut être l'un des types suivants : + **Copie sur écriture (CoW)** – Les données sont stockées dans un format en colonnes (Parquet) et chaque mise à jour crée une nouvelle version des fichiers lors d'une écriture. + **Fusion sur lecture (MoR)** – Les données sont stockées en utilisant une combinaison de formats en colonnes (Parquet) et en lignes (Avro). Les mises à jour sont enregistrées dans les fichiers `delta` en lignes et sont compactées si nécessaire pour créer de nouvelles versions des fichiers en colonnes. Avec les ensembles de données CoW, chaque fois qu’une mise à jour est apportée à un enregistrement, le fichier qui contient l’enregistrement est réécrit avec les valeurs mises à jour. Avec un jeu de données MoR, chaque fois qu’une mise à jour a lieu, Hudi écrit uniquement la ligne du registre modifié. Le type de stockage MoR est mieux adapté aux charges de travail donnant lieu à de nombreuses écritures ou modifications avec moins de lectures. Le type de stockage CoW est mieux adapté aux charges de travail lourdes en lecture sur des données qui changent moins fréquemment. Hudi propose trois types de requêtes pour accéder aux données : + **Requêtes d'instantané** – Requêtes qui affichent le dernier instantané de la table à partir d'une action de validation ou de compactage donnée. Pour les tables MoR, les requêtes d'instantané exposent l'état le plus récent de la table en fusionnant les fichiers de base et delta de la dernière tranche de fichiers au moment de la requête. + **Requête progressives** – Les requêtes ne portent que sur les nouvelles données écrites dans la table, depuis une validation/un compactage donné. Cela fournit efficacement des flux de modifications pour activer les pipelines de données (Data Pipelines) progressives. + **Requêtes à lecture optimisée** – Pour les tables MoR, les requêtes portent sur les dernières données compactées. Pour les tables CoW, les requêtes portent sur les dernières données validées. La table suivante montre les types de requêtes Hudi possibles pour chaque type de table. | Type de table | Types de requêtes Hudi possibles | | --- | --- | | Copie sur écriture | instantané, progressif | | fusion sur lecture | instantané, progressif, lecture optimisée | Pour plus d'informations sur les compromis entre les types de tables et de requêtes, consultez [Types de tables et de requêtes](https://hudi.apache.org/docs/table_types/) dans la documentation d'Apache Hudi. ## Changement de terminologie Hudi : les vues sont désormais des requêtes À partir de la version 0.5.1 d’Apache Hudi, les vues sont appelées requêtes. La table suivante résume les anciens et les nouveaux termes. | Ancien terme | Nouveau terme | | --- | --- | | CoW : vue à lecture optimisée MoR : vue en temps réel | Requêtes d'instantané | | Vue progressive | Requête progressive | | Vue à lecture optimisée MoR | Requête à lecture optimisée | **Topics** + [Changement de terminologie Hudi : les vues sont désormais des requêtes](#querying-hudi-hudi-dataset-table-types-terminology) + [Considérations et restrictions](querying-hudi-in-athena-considerations-and-limitations.md) + [Exemples de création de table par copie sur écriture (CoW)](querying-hudi-copy-on-write-create-table-examples.md) + [Exemples de création de table par fusion sur lecture (MoR)](querying-hudi-merge-on-read-create-table-examples.md) + [Utilisation de métadonnées Hudi pour améliorer les performances](querying-hudi-metadata-table.md) + [Ressources supplémentaires](querying-hudi-additional-resources.md) # Considérations et restrictions Tenez compte des points suivants lors de la lecture de tables Apache Hudi à l’aide d’Athena : + **Opérations de lecture et d'écriture** : Athena peut lire des ensembles de données Hudi compactés, mais pas écrire de données Hudi. + Versions **Hudi — Athena prend en charge les versions** Hudi 0.14.0 (par défaut) et 0.15.0. Athena ne peut garantir la compatibilité de lecture avec les tables créées avec des versions ultérieures de Hudi. Pour plus d’informations sur les fonctions et la gestion des versions de Hudi, voir la [documentation Hudi](https://hudi.apache.org/) sur le site Web Apache. Notez que la version 0.15.0 du connecteur Hudi sur Athena ne prend pas en charge les tables bootstrap. Pour utiliser la version 0.15.0 du connecteur Hudi, définissez la propriété de table suivante : ``` ALTER TABLE table_name SET TBLPROPERTIES ('athena_enable_native_hudi_connector_implementation' = 'true') ``` + **Requêtes entre comptes** : la version 0.15.0 du connecteur Hudi ne prend pas en charge les requêtes entre comptes. + **Types de requêtes** : Athena prend actuellement en charge les requêtes instantanées et les requêtes optimisées pour la lecture, mais pas les requêtes incrémentielles. Sur les tables MoR, toutes les données exposées aux requêtes à lecture optimisée sont compactées . Cela procure de bonnes performances, mais n'inclut pas les dernières validations delta. Les requêtes d'instantané contiennent les données les plus récentes mais entraînent une surcharge de calcul, ce qui rend ces requêtes moins performantes. Pour plus d'informations sur les compromis entre les types de tables et de requêtes, consultez [Types de tables et de requêtes](https://hudi.apache.org/docs/table_types/) dans la documentation d'Apache Hudi. + **Requêtes incrémentielles** : Athena ne prend pas en charge les requêtes incrémentielles. + **CTAS** : Athena ne prend pas en charge [CTAS](ctas.md) ou [INSERT INTO](insert-into.md) sur les données Hudi. Si vous souhaitez qu'Athena prenne en charge l'écriture des jeux de données Hudi, envoyez vos commentaires à athena-feedback@amazon.com. Pour plus d'informations sur l'écriture des données Hudi, consultez les ressources suivantes : + [Utilisation d'un jeu de données Hudi](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hudi-work-with-dataset.html) dans le [Guide de version Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/). + [Écriture de données](https://hudi.apache.org/docs/0.8.0/writing_data.html) dans la documentation d'Apache Hudi. + **MSCK REPAIR TABLE** : la commande MSCK REPAIR TABLE n’est pas prise en charge sur les tables Hudi dans Athena. Si vous devez charger une table Hudi qui n'a pas été créée dans AWS Glue, utilisez[ALTER TABLE ADD PARTITION](alter-table-add-partition.md). + **Omission des objets Amazon Glacier non prise en charge** : si des objets de la table Apache Hudi appartiennent à une classe de stockage Amazon Glacier, la définition de la propriété de table `read_restored_glacier_objects` sur `false` n’a aucun effet. Par exemple, supposons que vous exécutiez la commande suivante : ``` ALTER TABLE table_name SET TBLPROPERTIES ('read_restored_glacier_objects' = 'false') ``` Pour les tables Iceberg et Delta Lake, la commande produit l'erreur Unsupported table property key: read\$1restored\$1glacier\$1objects. Pour les tables Hudi, la commande `ALTER TABLE` ne génère pas d’erreur, mais les objets Amazon Glacier ne sont toujours pas ignorés. L'exécution de requêtes `SELECT` après la commande `ALTER TABLE` continue de renvoyer tous les objets. + **Requêtes d’horodatage** : actuellement, les requêtes qui tentent de lire les colonnes d’horodatage dans des tables en temps réel Hudi échouent ou génèrent des résultats vides. Cette restriction s’applique uniquement aux requêtes qui lisent une colonne d’horodatage. Les requêtes qui contiennent uniquement des colonnes de données autres que des données d’horodatage issues de la même table aboutissent. Les requêtes qui échouent renvoient un message semblable à celui présenté dans l’exemple suivant : GENERIC\$1INTERNAL\$1ERROR : classe org.apache.hadoop.io. ArrayWritablene peut pas être converti en classe org.apache.hadoop.hive.serde2.io. TimestampWritableV2 (org.apache.hadoop.io. ArrayWritable et org.apache.hadoop.hive.serde2.io. TimestampWritableLes V2 se trouvent dans un module anonyme du chargeur io.trino.server. PluginClassLoader @75c67992) + **Permissions de formation de lacs sur le connecteur Hudi 0.15.0** — Cette limitation s'applique uniquement lorsque vous choisissez d'utiliser le connecteur Hudi natif (version 0.15.0) en définissant la propriété de la table sur. `athena_enable_native_hudi_connector_implementation` `true` Par défaut, Athena utilise le connecteur Hudi version 0.14.0, qui ne nécessite pas cette autorisation supplémentaire. Pour interroger une table protégée de Lake Formation, vous devez accorder à Lake Formation des autorisations à la fois sur l'emplacement des données de la table et sur le répertoire `.hoodie` des métadonnées. Par exemple, si votre table Hudi se trouve à`s3://bucket/hudi-table/`, vous devez vous enregistrer et accorder des autorisations à la fois `s3://bucket/hudi-table/` et `s3://bucket/hudi-table/.hoodie/` dans Lake Formation. Le `.hoodie` répertoire contient des fichiers de métadonnées (tels que`hoodie.properties`) qu'Athena doit lire lors de la planification des requêtes. Sans autorisation d'accès à l'`.hoodie`annuaire, les requêtes échoueront et entraîneront des erreurs de refus d'autorisation. # Exemples de création de table par copie sur écriture (CoW) Si vous avez déjà créé des tables Hudi dans AWS Glue, vous pouvez les interroger directement dans Athena. Lorsque vous créez des tables Hudi partitionnées dans Athena, vous devez exécuter `ALTER TABLE ADD PARTITION` pour charger les données Hudi afin de pouvoir les interroger. ## Table CoW non partitionnée L'exemple suivant crée une table CoW non partitionnée dans Athena. ``` CREATE EXTERNAL TABLE `non_partition_cow`( `_hoodie_commit_time` string, `_hoodie_commit_seqno` string, `_hoodie_record_key` string, `_hoodie_partition_path` string, `_hoodie_file_name` string, `event_id` string, `event_time` string, `event_name` string, `event_guests` int, `event_type` string) ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' STORED AS INPUTFORMAT 'org.apache.hudi.hadoop.HoodieParquetInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat' LOCATION 's3://amzn-s3-demo-bucket/folder/non_partition_cow/' ``` ## Table CoW partitionnée L'exemple suivant crée une table CoW partitionnée dans Athena. ``` CREATE EXTERNAL TABLE `partition_cow`( `_hoodie_commit_time` string, `_hoodie_commit_seqno` string, `_hoodie_record_key` string, `_hoodie_partition_path` string, `_hoodie_file_name` string, `event_id` string, `event_time` string, `event_name` string, `event_guests` int) PARTITIONED BY ( `event_type` string) ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' STORED AS INPUTFORMAT 'org.apache.hudi.hadoop.HoodieParquetInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat' LOCATION 's3://amzn-s3-demo-bucket/folder/partition_cow/' ``` L'exemple `ALTER TABLE ADD PARTITION` suivant ajoute deux partitions à la table `partition_cow` en exemple. ``` ALTER TABLE partition_cow ADD PARTITION (event_type = 'one') LOCATION 's3://amzn-s3-demo-bucket/folder/partition_cow/one/' PARTITION (event_type = 'two') LOCATION 's3://amzn-s3-demo-bucket/folder/partition_cow/two/' ``` # Exemples de création de table par fusion sur lecture (MoR) Hudi crée deux tables dans le métastore pour MoR : une table pour les requêtes d'instantané et une table pour les requêtes à lecture optimisée. Les deux tables peuvent être interrogées. Dans les versions de Hudi antérieures à 0.5.1, la table pour les requêtes à lecture optimisée avait le nom que vous aviez spécifié lorsque vous avez créé la table. À partir de la version 0.5.1 de Hudi, le nom de la table est suffixé par défaut par le suffixe `_ro`. Le nom de la table pour les requêtes d'instantané est le nom que vous avez spécifié, suivi de `_rt`. ## Table non partitionnée à fusion sur lecture (MoR) L'exemple suivant crée une table MoR non partitionnée dans Athena pour les requêtes à lecture optimisée. Notez que les requêtes à lecture optimisée utilisent le format d'entrée `HoodieParquetInputFormat`. ``` CREATE EXTERNAL TABLE `nonpartition_mor`( `_hoodie_commit_time` string, `_hoodie_commit_seqno` string, `_hoodie_record_key` string, `_hoodie_partition_path` string, `_hoodie_file_name` string, `event_id` string, `event_time` string, `event_name` string, `event_guests` int, `event_type` string) ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' STORED AS INPUTFORMAT 'org.apache.hudi.hadoop.HoodieParquetInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat' LOCATION 's3://amzn-s3-demo-bucket/folder/nonpartition_mor/' ``` L'exemple suivant crée une table MoR non partitionnée dans Athena pour les requêtes d'instantané. Pour les requêtes d'instantané, utilisez le format d'entrée `HoodieParquetRealtimeInputFormat`. ``` CREATE EXTERNAL TABLE `nonpartition_mor_rt`( `_hoodie_commit_time` string, `_hoodie_commit_seqno` string, `_hoodie_record_key` string, `_hoodie_partition_path` string, `_hoodie_file_name` string, `event_id` string, `event_time` string, `event_name` string, `event_guests` int, `event_type` string) ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' STORED AS INPUTFORMAT 'org.apache.hudi.hadoop.realtime.HoodieParquetRealtimeInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat' LOCATION 's3://amzn-s3-demo-bucket/folder/nonpartition_mor/' ``` ## Table partitionnée à fusion sur lecture (MoR) L'exemple suivant crée une table MoR partitionnée dans Athena pour les requêtes à lecture optimisée. ``` CREATE EXTERNAL TABLE `partition_mor`( `_hoodie_commit_time` string, `_hoodie_commit_seqno` string, `_hoodie_record_key` string, `_hoodie_partition_path` string, `_hoodie_file_name` string, `event_id` string, `event_time` string, `event_name` string, `event_guests` int) PARTITIONED BY ( `event_type` string) ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' STORED AS INPUTFORMAT 'org.apache.hudi.hadoop.HoodieParquetInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat' LOCATION 's3://amzn-s3-demo-bucket/folder/partition_mor/' ``` L'exemple `ALTER TABLE ADD PARTITION` suivant ajoute deux partitions à la table `partition_mor` en exemple. ``` ALTER TABLE partition_mor ADD PARTITION (event_type = 'one') LOCATION 's3://amzn-s3-demo-bucket/folder/partition_mor/one/' PARTITION (event_type = 'two') LOCATION 's3://amzn-s3-demo-bucket/folder/partition_mor/two/' ``` L'exemple suivant crée une table MoR partitionnée dans Athena pour les requêtes d'instantané. ``` CREATE EXTERNAL TABLE `partition_mor_rt`( `_hoodie_commit_time` string, `_hoodie_commit_seqno` string, `_hoodie_record_key` string, `_hoodie_partition_path` string, `_hoodie_file_name` string, `event_id` string, `event_time` string, `event_name` string, `event_guests` int) PARTITIONED BY ( `event_type` string) ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' STORED AS INPUTFORMAT 'org.apache.hudi.hadoop.realtime.HoodieParquetRealtimeInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat' LOCATION 's3://amzn-s3-demo-bucket/folder/partition_mor/' ``` De même, l'exemple `ALTER TABLE ADD PARTITION` suivant ajoute deux partitions à la table `partition_mor_rt` en exemple. ``` ALTER TABLE partition_mor_rt ADD PARTITION (event_type = 'one') LOCATION 's3://amzn-s3-demo-bucket/folder/partition_mor/one/' PARTITION (event_type = 'two') LOCATION 's3://amzn-s3-demo-bucket/folder/partition_mor/two/' ``` # Utilisation de métadonnées Hudi pour améliorer les performances Apache Hudi possède une [table de métadonnées](https://hudi.apache.org/docs/next/metadata/) qui contient des fonctionnalités d'indexation pour améliorer les performances, telles que le listage des fichiers, le saut de données à l'aide de statistiques de colonnes et un index basé sur un filtre Bloom. Parmi ces fonctionnalités, Athena ne prend actuellement en charge que l'index de listage des fichiers. L'index de listage des fichiers élimine les appels au système de fichiers tels que les « list files » en récupérant les informations d'un index qui gère un mappage d'une partition à des fichiers. Cela élimine le besoin de répertorier de manière récursive chaque partition sous le chemin de la table pour obtenir une vue du système de fichiers. Lorsque vous travaillez avec de grands jeux de données, cette indexation réduit considérablement la latence qui se produirait sinon lors de l'obtention de la liste des fichiers durant les écritures et les requêtes. Cela permet également d'éviter les goulots d'étranglement tels que la limitation des limites de demandes lors des appels `LIST` Amazon S3. **Note** Athena ne prend actuellement pas en charge le saut de données ni l'indexation par filtre Bloom. ## Activation de la table de métadonnées Hudi Le listage des fichiers basé sur les tables de métadonnées est désactivée par défaut. Pour activer la table de métadonnées Hudi et la fonctionnalité de listage des fichiers associée, définissez la propriété de table `hudi.metadata-listing-enabled` sur `TRUE`. **Exemple** L'exemple `ALTER TABLE SET TBLPROPERTIES` suivant active la table de métadonnées dans la table `partition_cow` d'exemple. ``` ALTER TABLE partition_cow SET TBLPROPERTIES('hudi.metadata-listing-enabled'='TRUE') ``` ## Utilisation de métadonnées générées par amorçage À partir de la version 0.6.0 d'Apache Hudi, la fonction d'opération d'amorçage offre de meilleures performances avec les jeux de données Parquet existants. Au lieu de réécrire le jeu de données, une opération d'amorçage ne peut générer que des métadonnées, laissant le jeu de données en place. Vous pouvez utiliser Athena pour interroger des tables à partir d'une opération d'amorçage, comme d'autres tables basées sur des données dans Simple Storage Service (Amazon S3). Dans votre instruction `CREATE TABLE`, spécifiez le chemin d'accès de la table Hudi dans votre clause `LOCATION`. Pour plus d'informations sur la création de tables Hudi à l'aide de l'opération bootstrap [dans Amazon EMR, consultez l'article Nouvelles fonctionnalités d'Apache Hudi disponibles sur Amazon EMR](https://aws.amazon.com/blogs/big-data/new-features-from-apache-hudi-available-in-amazon-emr/) sur le Big Data Blog. AWS # Ressources supplémentaires Pour plus d’informations sur l’utilisation d’Apache Hudi avec Athena, consultez les ressources suivantes. ## Vidéo La vidéo suivante montre comment utiliser Amazon Athena pour interroger un jeu de données Apache Hudi à lecture optimisée dans votre lac de données basé sur Simple Storage Service (Amazon S3). [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/TVcreqxBaGA/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/TVcreqxBaGA) ## Billets de blogs Les articles suivants du blog AWS Big Data décrivent comment vous pouvez utiliser Apache Hudi avec Athena. + [Utilisez AWS Data Exchange pour partager facilement les ensembles de données Apache Hudi](https://aws.amazon.com/blogs/big-data/use-aws-data-exchange-to-seamlessly-share-apache-hudi-datasets/) + [Créez un lac de données near-real-time transactionnel basé sur Apache Hudi à l'aide d'Amazon AWS DMS Kinesis, du AWS Glue streaming ETL et de la visualisation des données à l'aide de Quick](https://aws.amazon.com/blogs/big-data/create-an-apache-hudi-based-near-real-time-transactional-data-lake-using-aws-dms-amazon-kinesis-aws-glue-streaming-etl-and-data-visualization-using-amazon-quicksight/) + Pour plus d'informations sur l'utilisation de connecteurs AWS Glue personnalisés et de tâches AWS Glue 2.0 pour créer une table Apache Hudi que vous pouvez interroger avec Athena, [voir Écrire dans des tables AWS Glue Apache Hudi à l'](https://aws.amazon.com/blogs/big-data/writing-to-apache-hudi-tables-using-aws-glue-connector/)aide d'un connecteur personnalisé. + Pour un article sur l'utilisation d'Apache Hudi et d'Amazon Athena pour créer une infrastructure de traitement des données pour un lac de données, [consultez Simplifier le traitement des données opérationnelles dans les lacs de données à AWS Glue l'aide](https://aws.amazon.com/blogs/big-data/simplify-operational-data-processing-in-data-lakes-using-aws-glue-and-apache-hudi/) d'Apache Hudi. AWS Glue # Interrogation des tables Apache Iceberg Athena vous permet d’exécuter des requêtes de lecture, Time Travel, d’écriture et DDL sur des tables Apache Iceberg. [Apache Iceberg](https://iceberg.apache.org/) est un format de table ouvert pour les jeux de données analytiques très volumineux. Iceberg gère de vastes collections de fichiers sous forme de tables et prend en charge les opérations modernes de lac de données analytiques telles que les requêtes d'insertion, de mise à jour, de suppression et Time Travel au niveau des enregistrements. La spécification Iceberg permet une évolution transparente des tables, comme l'évolution des schémas et des partitions, et est conçue pour une utilisation optimisée sur Amazon S3. Iceberg contribue également à garantir l'exactitude des données dans des scénarios d'écriture simultanés. Pour plus d’informations sur Apache Iceberg, consultez [https://iceberg.apache.org/](https://iceberg.apache.org/). ## Considérations et restrictions Les considérations et restrictions suivantes s’appliquent à la prise en charge des tables Iceberg dans Athena : + **Version d’Iceberg prise en charge** : Athena prend en charge la version 1.4.2 d’Apache Iceberg. + **Tables enregistrées dans Lake Formation** : Athena ne prend actuellement pas en charge les opérations DDL sur les tables Iceberg enregistrées dans Lake Formation. + **Requêtes sur le schéma d’informations** : lors de l’interrogation du schéma d’informations des tables Iceberg, Athena utilise les métadonnées S3 comme source de vérité pour les métadonnées des colonnes. Cela signifie que les informations des colonnes sont dérivées des fichiers S3 sous-jacents plutôt que des métadonnées du catalogue. Ce comportement diffère de celui des autres formats de table, dans lesquels les métadonnées du catalogue peuvent être la source principale des informations des colonnes. + **Tables avec AWS Glue catalogue uniquement : seules** les tables Iceberg créées à partir du AWS Glue catalogue sur la base des spécifications définies par l'[implémentation du catalogue Glue open source](https://iceberg.apache.org/docs/latest/aws/#glue-catalog) sont prises en charge par Athena. + **Support de verrouillage des tables AWS Glue uniquement : contrairement à l'implémentation du catalogue open source Glue, qui prend en charge le verrouillage personnalisé par** plug-in, Athena prend uniquement en charge le verrouillage AWS Glue optimiste. L'utilisation d'Athena pour modifier une table Iceberg avec n'importe quelle autre implémentation de verrouillage entraînera une perte de données potentielle et interrompra les transactions. + **Formats de fichier pris en charge** : la version 3 du moteur Athena prend en charge les formats de fichier Iceberg suivants : + Parquet + ORC + Avro + **Métadonnées Iceberg restreintes** : Lake Formation n’évalue pas les tables de métadonnées Iceberg. Ces tables sont donc restreintes si des filtres de ligne ou de cellule Lake Formation sont appliqués dans la table de base ou si vous ne disposez pas de l’autorisation permettant d’afficher toutes les colonnes de la table de base. Dans ce cas, l’interrogation des tables de métadonnées Iceberg `$partitions`, `$files`, `$manifests` et `$snapshots` échoue et génère une erreur `AccessDeniedException`. Par ailleurs, la colonne de métadonnées `$path` est soumise aux mêmes restrictions Lake Formation et génère une erreur lorsqu’elle est sélectionnée dans la requête. Toutes les autres tables de métadonnées peuvent être interrogées quels que soient les filtres Lake Formation. Pour plus d’informations, consultez [Metadata tables](https://trino.io/docs/current/connector/iceberg.html#metadata-tables). + **Tables Iceberg v2** : Athena ne crée et n'opère que sur des tables Iceberg v2. Pour connaître la différence entre les tables v1 et v2, consultez la section [Modifications de version de format](https://iceberg.apache.org/spec/#appendix-e-format-version-changes) dans la documentation Apache Iceberg. + **Affichage des types horaires sans fuseau horaire** – L'heure et l'horodatage sans types de fuseau horaire sont affichés en UTC. Si le fuseau horaire n'est pas spécifié dans une expression de filtre sur une colonne de temps, UTC est utilisé. + **Précision des données liées à l'horodatage** – Bien qu'Iceberg prenne en charge la précision à la microseconde pour le type de données d'horodatage, Athena ne prend en charge que la précision à la milliseconde pour les horodatages, tant en lecture qu'en écriture. Pour les données contenues dans les colonnes liées au temps réécrites lors des opérations de compactage manuel, Athena conserve uniquement la précision a la milliseconde. + **Opérations non prises en charge** : les opérations Athena suivantes ne sont pas prises en charge pour les tables Iceberg. + [ALTER TABLE SET LOCATION](alter-table-set-location.md) + **Vues** – Utiliser `CREATE VIEW` pour créer des vues Athena comme décrit dans [Utilisation de vues](views.md). Si vous souhaitez utiliser la [spécification de vue Iceberg](https://github.com/apache/iceberg/blob/master/format/view-spec.md) pour créer des vues, contactez [athena-feedback@amazon.com](mailto:athena-feedback@amazon.com). + Les **commandes de gestion TTF ne sont pas prises en charge dans AWS Lake Formation** — Bien que vous puissiez utiliser Lake Formation pour gérer les autorisations d'accès en lecture pour des TransactionTable formats (TTFs) tels qu'Apache Iceberg, Apache Hudi et Linux Foundation Delta Lake, vous ne pouvez pas utiliser Lake Formation pour gérer les autorisations pour des opérations telles que `VACUUM` `UPDATE` ou `OPTIMIZE` avec ces formats de table. `MERGE` *Pour plus d'informations sur l'intégration de Lake Formation à Athena, consultez la section [Utilisation AWS Lake Formation avec Amazon Athena](https://docs.aws.amazon.com/lake-formation/latest/dg/athena-lf.html) dans AWS Lake Formation le manuel du développeur.* + **Partitionnement par champs imbriqués** – Le partitionnement par champs imbriqués n'est pas pris en charge. Cette tentative produit le message NOT\$1SUPPORTED : Le partitionnement par champ imbriqué n'est pas pris en charge :. *column\$1name* *nested\$1field\$1name*. + **Omission des objets Amazon Glacier non prise en charge** : si des objets de la table Apache Iceberg appartiennent à une classe de stockage Amazon Glacier, la définition de la propriété de table `read_restored_glacier_objects` sur `false` n’a aucun effet. Par exemple, supposons que vous exécutiez la commande suivante : ``` ALTER TABLE table_name SET TBLPROPERTIES ('read_restored_glacier_objects' = 'false') ``` Pour les tables Iceberg et Delta Lake, la commande produit l'erreur Unsupported table property key: read\$1restored\$1glacier\$1objects. Pour les tables Hudi, la commande `ALTER TABLE` ne génère pas d’erreur, mais les objets Amazon Glacier ne sont toujours pas ignorés. L'exécution de requêtes `SELECT` après la commande `ALTER TABLE` continue de renvoyer tous les objets. Si vous souhaitez qu'Athena prenne en charge une fonction particulière, envoyez vos commentaires à l'adresse [athena-feedback@amazon.com](mailto:athena-feedback@amazon.com). **Topics** + [Considérations et restrictions](#querying-iceberg-considerations-and-limitations) + [Création de tables Iceberg](querying-iceberg-creating-tables.md) + [Interrogation des données de table Iceberg](querying-iceberg-table-data.md) + [Exécution de requêtes Time Travel et Version Travel](querying-iceberg-time-travel-and-version-travel-queries.md) + [Mise à jour des données de tables Iceberg](querying-iceberg-updating-iceberg-table-data.md) + [Gestion des tables Iceberg](querying-iceberg-managing-tables.md) + [Modification du schéma de table Iceberg](querying-iceberg-evolving-table-schema.md) + [Exécution d’autres opérations DDL sur des tables Iceberg](querying-iceberg-additional-operations.md) + [Optimisation des tables Iceberg](querying-iceberg-data-optimization.md) + [Vues matérialisées du catalogue de AWS Glue données de requête](querying-iceberg-gdc-mv.md) + [Types de données pris en charge pour les tables Iceberg sur Athena](querying-iceberg-supported-data-types.md) + [Ressources supplémentaires](querying-iceberg-additional-resources.md) # Création de tables Iceberg Pour créer une table Iceberg à utiliser dans Athena, vous pouvez utiliser `CREATE TABLE` une instruction telle que décrite sur cette page, ou vous pouvez utiliser AWS Glue un robot d'exploration. ## Utilisation de l’instruction CREATE TABLE Athena crée des tables Iceberg v2. Pour connaître la différence entre les tables v1 et v2, consultez la section [Modifications de version de format](https://iceberg.apache.org/spec/#appendix-e-format-version-changes) dans la documentation Apache Iceberg. Athena `CREATE TABLE` crée une table Iceberg sans données. Vous pouvez interroger une table à partir de systèmes externes tels qu'Apache Spark directement si la table utilise le [catalogue open source Glue d'Iceberg](https://iceberg.apache.org/docs/latest/aws/#glue-catalog). Il n'est pas nécessaire de créer une table externe. **Avertissement** L'exécution de `CREATE EXTERNAL TABLE` entraîne le message d'erreur External keyword not supported for table type ICEBERG (Mot clé externe non pris en charge pour le type de table ICEBERG). Pour créer une table Iceberg à partir d'Athena, définissez la propriété de table `'table_type'` à `'ICEBERG'` dans la clause `TBLPROPERTIES`, comme dans le récapitulatif de la syntaxe suivant. ``` CREATE TABLE [db_name.]table_name (col_name data_type [COMMENT col_comment] [, ...] ) [PARTITIONED BY (col_name | transform, ... )] LOCATION 's3://amzn-s3-demo-bucket/your-folder/' TBLPROPERTIES ( 'table_type' ='ICEBERG' [, property_name=property_value] ) ``` Pour plus d'informations sur les types de données que vous pouvez interroger dans les tables Iceberg, consultez [Types de données pris en charge pour les tables Iceberg sur Athena](querying-iceberg-supported-data-types.md). ### Utilisation de partitions Pour créer des tables Iceberg avec des partitions, utilisez la syntaxe `PARTITIONED BY`. Les colonnes utilisées pour le partitionnement doivent d'abord être spécifiées dans les déclarations de colonnes. Dans la clause `PARTITIONED BY`, le type de colonne ne doit pas être inclus. Vous pouvez également définir des [transformations de partition](https://iceberg.apache.org/spec/#partition-transforms) dans la syntaxe `CREATE TABLE`. Pour spécifier plusieurs colonnes à partitionner, séparez les colonnes par la virgule (`,`), comme dans l'exemple suivant. ``` CREATE TABLE iceberg_table (id bigint, data string, category string) PARTITIONED BY (category, bucket(16, id)) LOCATION 's3://amzn-s3-demo-bucket/your-folder/' TBLPROPERTIES ( 'table_type' = 'ICEBERG' ) ``` Le tableau suivant présente les fonctions de transformation de partition disponibles. **** | Fonction | Description | Types pris en charge | | --- | --- | --- | | year(ts) | Partition par année | date, timestamp | | month(ts) | Partition par mois | date, timestamp | | day(ts) | Partition par jour | date, timestamp | | hour(ts) | Partition par heure | timestamp | | bucket(N, col) | Partition par compartiments de modification à valeur hachéeN. C'est le même concept que le compartiment de hachage pour les tables Hive. | int, long, decimal, date, timestamp, string, binary | | truncate(L, col) | Partition par valeur tronquée en L | int, long, decimal, string | Athena prend en charge le partitionnement caché d'Iceberg. Pour plus d’informations, consultez [Partitionnement caché d'Iceberg](https://iceberg.apache.org/docs/latest/partitioning/#icebergs-hidden-partitioning) dans la documentation Apache Iceberg. ### Spécification de propriétés de table Cette section décrit les propriétés de la table que vous pouvez spécifier sous forme de paires clé-valeur dans la clause `TBLPROPERTIES` de l'instruction `CREATE TABLE`. Athena n'autorise qu'une liste prédéfinie de paires clé-valeur dans les propriétés de la table pour créer ou modifier des tables Iceberg. Les tableaux suivants présentent les propriétés de la table que vous pouvez spécifier. Pour plus d'informations sur les options de compactage, consultez la section [Optimisation des tables Iceberg](querying-iceberg-data-optimization.md) dans cette documentation. Si vous souhaitez qu'Athena prenne en charge une propriété de configuration de table open source spécifique, envoyez vos commentaires à [athena-feedback@amazon.com](mailto:athena-feedback@amazon.com). ***format*** **** | | | | --- |--- | | Description | Format de données du fichier | | Valeurs de propriété autorisées | Le format de fichier et les combinaisons de compression pris en charge varient selon la version du moteur Athena. Pour de plus amples informations, veuillez consulter [Utilisation de la compression des tables Iceberg](compression-support-iceberg.md). | | Valeur par défaut | parquet | ***write\$1compression*** **** | | | | --- |--- | | Description | Codec de compression de fichier | | Valeurs de propriété autorisées | Le format de fichier et les combinaisons de compression pris en charge varient selon la version du moteur Athena. Pour de plus amples informations, veuillez consulter [Utilisation de la compression des tables Iceberg](compression-support-iceberg.md). | | Valeur par défaut | La compression d'écriture par défaut varie selon la version du moteur Athena. Pour de plus amples informations, veuillez consulter [Utilisation de la compression des tables Iceberg](compression-support-iceberg.md). | ***optimize\$1rewrite\$1data\$1file\$1threshold*** **** | | | | --- |--- | | Description | Configuration spécifique à l'optimisation des données. S'il y a moins de fichiers de données nécessitant une optimisation que le seuil donné, les fichiers ne sont pas réécrits. Cela permet d'accumuler davantage de fichiers de données pour produire des fichiers plus proches de la taille cible et ignorer les calculs inutiles pour économiser les coûts. | | Valeurs de propriété autorisées | Nombre positif. Il doit être inférieur à 50. | | Valeur par défaut | 5 | ***optimize\$1rewrite\$1delete\$1file\$1seuil*** **** | | | | --- |--- | | Description | Configuration spécifique à l'optimisation des données. S'il y a moins de fichiers de suppression associés à un fichier de données que le seuil, le fichier de données n'est pas réécrit. Cela permet d'accumuler davantage de fichiers supprimés pour chaque fichier de données afin de réaliser des économies. | | Valeurs de propriété autorisées | Nombre positif. Il doit être inférieur à 50. | | Valeur par défaut | 2 | ***vacuum\$1min\$1snapshots\$1to\$1keep*** **** | | | | --- |--- | | Description | Nombre minimum d'instantanés à retenir sur la branche principale d'une table. Cette valeur est prioritaire sur la propriété `vacuum_max_snapshot_age_seconds`. Si le nombre minimal d'instantanés restants est supérieur à l'âge spécifié par `vacuum_max_snapshot_age_seconds`, les instantanés sont conservés et la valeur de `vacuum_max_snapshot_age_seconds` est ignorée. | | Valeurs de propriété autorisées | Nombre positif. | | Valeur par défaut | 1 | ***vacuum\$1max\$1snapshot\$1age\$1seconds*** **** | | | | --- |--- | | Description | Âge maximum des instantanés à retenir sur la branche principale. Cette valeur est ignorée si le minimum d'instantanés restant spécifié par vacuum\$1min\$1snapshots\$1to\$1keep est supérieur à l'âge spécifié. Cette propriété de comportement de table correspond à la propriété history.expire.max-snapshot-age-ms de la configuration Apache Iceberg. | | Valeurs de propriété autorisées | Nombre positif. | | Valeur par défaut | 432 000 secondes (5 jours) | ***vacuum\$1max\$1metadata\$1files\$1to\$1keep*** **** | | | | --- |--- | | Description | Nombre maximal d’anciens fichiers de métadonnées à conserver sur la branche principale de la table. | | Valeurs de propriété autorisées | Nombre positif. | | Valeur par défaut | 100 | ***write\$1data\$1path\$1enabled*** **** | | | | --- |--- | | Description | Lorsqu'elle est définie surtrue, la table Iceberg est créée avec la write.data.path propriété au lieu de la propriété obsolètewrite.object-storage.path. Utilisez cette option pour garantir la compatibilité avec Iceberg 1.9.0 et versions ultérieures, qui ne prennent plus en charge la propriété obsolète. | | Valeurs de propriété autorisées | true, false | | Valeur par défaut | false | ### Exemple d'instruction CREATE TABLE (CRÉER UNE TABLE) L'exemple suivant crée une table Iceberg à trois colonnes. ``` CREATE TABLE iceberg_table ( id int, data string, category string) PARTITIONED BY (category, bucket(16,id)) LOCATION 's3://amzn-s3-demo-bucket/iceberg-folder' TBLPROPERTIES ( 'table_type'='ICEBERG', 'format'='parquet', 'write_compression'='snappy', 'optimize_rewrite_delete_file_threshold'='10' ) ``` ## Utilisation de CREATE TABLE AS SELECT (CTAS) Pour plus d'informations sur la création d'une table Iceberg à l'aide de l'instruction `CREATE TABLE AS`, veuillez consulter [CREATE TABLE AS](create-table-as.md), en portant une attention particulière à la section [Propriétés de la table CTAS](create-table-as.md#ctas-table-properties). ## Utiliser un AWS Glue crawler Vous pouvez utiliser un AWS Glue robot pour enregistrer automatiquement vos tables Iceberg dans le. AWS Glue Data Catalog Si vous souhaitez effectuer une migration depuis un autre catalogue Iceberg, vous pouvez créer et planifier un AWS Glue robot et fournir les chemins Amazon S3 où se trouvent les tables Iceberg. Vous pouvez spécifier la profondeur maximale des chemins Amazon S3 que le Crawler AWS Glue peut parcourir. Une fois que vous avez planifié un AWS Glue robot d'exploration, celui-ci extrait les informations du schéma et les met à jour en fonction des modifications apportées AWS Glue Data Catalog au schéma à chaque fois qu'il s'exécute. Le AWS Glue robot d'exploration prend en charge la fusion de schémas entre les instantanés et met à jour l'emplacement du dernier fichier de métadonnées dans le. AWS Glue Data Catalog Pour plus d'informations, consultez la section [Catalogue de données et robots d'exploration dans AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/catalog-and-crawler.html). # Interrogation des données de table Iceberg Pour interroger un jeu de données Iceberg, utilisez une instruction standard `SELECT` comme suit. Les requêtes suivent les [spécifications du format Apache Iceberg v2](https://iceberg.apache.org/spec/#format-versioning) et effectuent merge-on-read des suppressions de position et d'égalité. ``` SELECT * FROM [db_name.]table_name [WHERE predicate] ``` Pour optimiser les temps de requête, certains prédicats sont poussés vers l'endroit où résident les données. Pour plus d’informations sur les requêtes Time Travel et Version Travel, consultez [Exécution de requêtes Time Travel et Version Travel](querying-iceberg-time-travel-and-version-travel-queries.md). ## Création et interrogation de vues à l’aide de tables Iceberg Pour créer et interroger des vues Athena sur des tables Iceberg, utilisez des vues `CREATE VIEW` comme décrit dans [Utilisation de vues](views.md). Exemple : ``` CREATE VIEW view1 AS SELECT * FROM iceberg_table ``` ``` SELECT * FROM view1 ``` Si vous souhaitez utiliser la [spécification de vue Iceberg](https://github.com/apache/iceberg/blob/master/format/view-spec.md) pour créer des vues, contactez [athena-feedback@amazon.com](mailto:athena-feedback@amazon.com). ## Interrogation des métadonnées de tables Iceberg Dans une `SELECT` requête, vous pouvez ensuite utiliser les propriétés suivantes *table\$1name* pour interroger les métadonnées de la table Iceberg : + **\$1files** – Affiche les fichiers de données actuels d'une table. + **\$1manifest** – Affiche les manifestes des fichiers actuels d'une table. + **\$1history** – Affiche l'historique d'une table. + **\$1partitions** – Affiche les partitions actuelles d'une table. + **\$1snapshots** – Affiche les instantanés d'une table. + **\$1refs** – Affiche les références d'une table. ### Exemples L'instruction suivante répertorie les fichiers d'une table Iceberg. ``` SELECT * FROM "dbname"."tablename$files" ``` L'instruction suivante répertorie les manifestes d'une table Iceberg. ``` SELECT * FROM "dbname"."tablename$manifests" ``` L'instruction suivante affiche l'historique d'une table Iceberg. ``` SELECT * FROM "dbname"."tablename$history" ``` L'exemple suivant affiche les partitions d'une table Iceberg. ``` SELECT * FROM "dbname"."tablename$partitions" ``` L'exemple suivant affiche les instantanés d'une table Iceberg. ``` SELECT * FROM "dbname"."tablename$snapshots" ``` L'exemple suivant affiche les références d'une table Iceberg. ``` SELECT * FROM "dbname"."tablename$refs" ``` ## Utilisation du contrôle précis des accès de Lake Formation La version 3 du moteur Athena prend en charge le contrôle d'accès précis de Lake Formation avec les tables Iceberg, y compris le contrôle d'accès de sécurité au niveau des colonnes et des lignes. Ce contrôle d'accès fonctionne avec les requêtes de voyage dans le temps et avec les tables qui ont effectué une évolution de leur schéma. Pour de plus amples informations, veuillez consulter [Contrôle d'accès précis de Lake Formation et groupes de travail Athena](lf-athena-limitations.md#lf-athena-limitations-fine-grained-access-control). Si vous avez créé votre table Iceberg en dehors d'Athena, utilisez le kit [SDK Apache Iceberg](https://iceberg.apache.org/releases/) en version 0.13.0 ou supérieure pour que les informations des colonnes de votre table Iceberg soient renseignées dans le AWS Glue Data Catalog. Si votre table Iceberg ne contient pas d'informations de colonne AWS Glue, vous pouvez utiliser l'instruction [ALTER TABLE SET TBLPROPERTIES](querying-iceberg-alter-table-set-properties.md) Athena ou le dernier SDK Iceberg pour corriger la table et mettre à jour les informations de colonne dans. AWS Glue # Exécution de requêtes Time Travel et Version Travel Chaque table Apache Iceberg conserve un manifeste versionné des objets Simple Storage Service (Amazon S3) qu'elle contient. Les versions précédentes du manifeste peuvent être utilisées pour les requêtes Time Travel et Version Travel. Les requêtes Time Travel dans Athena interrogent Simple Storage Service (Amazon S3) des données historiques à partir d'un instantané cohérent à partir d'une date et d'une heure spécifiées. Les requêtes Version Travel dans Athena interrogent Simple Storage Service (Amazon S3) pour des données historiques à partir d'un ID d'instantané spécifié. ## Requêtes Time Travel Pour exécuter une requête Time Travel, utilisez `FOR TIMESTAMP AS OF timestamp` après le nom de la table dans l'instruction `SELECT`, comme dans l'exemple suivant. ``` SELECT * FROM iceberg_table FOR TIMESTAMP AS OF timestamp ``` L'heure système à spécifier pour les déplacements est soit un horodatage, soit un horodatage avec un fuseau horaire. Si elle n'est pas spécifiée, Athena considère que la valeur est un horodatage en heure UTC. Les exemples de requêtes de voyage dans le temps suivants sélectionnent CloudTrail des données pour la date et l'heure spécifiées. ``` SELECT * FROM iceberg_table FOR TIMESTAMP AS OF TIMESTAMP '2020-01-01 10:00:00 UTC' ``` ``` SELECT * FROM iceberg_table FOR TIMESTAMP AS OF (current_timestamp - interval '1' day) ``` ## Requêtes Version Travel Pour exécuter une requête Version Travel (c'est-à-dire afficher un instantané cohérent à partir d'une version spécifiée), utilisez `FOR VERSION AS OF version` après le nom de la table dans l'instruction `SELECT`, comme dans l'exemple suivant. ``` SELECT * FROM [db_name.]table_name FOR VERSION AS OF version ``` Le *version* paramètre est l'ID de `bigint` capture associé à une version de table Iceberg. L'exemple de requête Version Travel suivant sélectionne les données pour la version spécifiée. ``` SELECT * FROM iceberg_table FOR VERSION AS OF 949530903748831860 ``` **Note** Les clauses `FOR SYSTEM_TIME AS OF` et `FOR SYSTEM_VERSION AS OF` de la version 2 du moteur Athena ont été remplacées par les clauses `FOR TIMESTAMP AS OF` et `FOR VERSION AS OF` de la version 3 du moteur Athena. ### Récupération de l’ID d’instantané Vous pouvez utiliser la [SnapshotUtil](https://iceberg.apache.org/javadoc/1.6.0/org/apache/iceberg/util/SnapshotUtil.html)classe Java fournie par Iceberg pour récupérer l'ID du snapshot Iceberg, comme dans l'exemple suivant. ``` import org.apache.iceberg.Table; import org.apache.iceberg.aws.glue.GlueCatalog; import org.apache.iceberg.catalog.TableIdentifier; import org.apache.iceberg.util.SnapshotUtil; import java.text.SimpleDateFormat; import java.util.Date; Catalog catalog = new GlueCatalog(); Map properties = new HashMap(); properties.put("warehouse", "s3://amzn-s3-demo-bucket/my-folder"); catalog.initialize("my_catalog", properties); Date date = new SimpleDateFormat("yyyy/MM/dd HH:mm:ss").parse("2022/01/01 00:00:00"); long millis = date.getTime(); TableIdentifier name = TableIdentifier.of("db", "table"); Table table = catalog.loadTable(name); long oldestSnapshotIdAfter2022 = SnapshotUtil.oldestAncestorAfter(table, millis); ``` ## Combinaison de Time Travel et Version Travel Vous pouvez utiliser la syntaxe Time Travel et Version Travel dans la même requête pour spécifier différentes conditions de synchronisation et de gestion des versions, comme dans l'exemple suivant. ``` SELECT table1.*, table2.* FROM [db_name.]table_name FOR TIMESTAMP AS OF (current_timestamp - interval '1' day) AS table1 FULL JOIN [db_name.]table_name FOR VERSION AS OF 5487432386996890161 AS table2 ON table1.ts = table2.ts WHERE (table1.id IS NULL OR table2.id IS NULL) ``` # Mise à jour des données de tables Iceberg Vous pouvez gérer les données des tables Iceberg directement dans Athena à l’aide de requêtes `INSERT`, `UPDATE` et `DELETE`. Chaque transaction de gestion des données produit un nouvel instantané, qui peut être interrogé à l'aide de requêtes Time Travel. Les instructions `UPDATE` et `DELETE` suivent la spécification de [suppression de position](https://iceberg.apache.org/spec/#position-delete-files) au niveau des lignes du format Iceberg v2 et appliquent l'isolation des instantanés. **Note** Athena SQL ne prend actuellement pas en charge cette approche. copy-on-write Les `DELETE FROM` opérations `UPDATE``MERGE INTO`, et utilisent toujours l' merge-on-readapproche des suppressions positionnelles, quelles que soient les propriétés de table spécifiées. Si vous avez configuré des propriétés de table telles que `write.update.mode``write.merge.mode`, et/ou `write.delete.mode` à utiliser copy-on-write, vos requêtes n'échoueront pas car Athena les ignorera et continuera à les utiliser. merge-on-read Utilisez les commandes suivantes pour effectuer des opérations de gestion des données sur les tables Iceberg. **Topics** + [INSERT INTO](querying-iceberg-insert-into.md) + [DELETE](querying-iceberg-delete.md) + [UPDATE](querying-iceberg-update.md) + [MERGE INTO](querying-iceberg-merge-into.md) # INSERT INTO Insère des données dans une table Iceberg. Athena Iceberg `INSERT INTO` est facturé de la même manière que les requêtes `INSERT INTO` actuelles pour les tables Hive externes, en fonction de la quantité de données analysées. Pour insérer des données dans une table Iceberg, utilisez la syntaxe suivante, où *query* peut être l'un `VALUES (val1, val2, ...)` ou `SELECT (col1, col2, …) FROM [db_name.]table_name WHERE predicate` l'autre. Pour des détails sur la syntaxe SQL et la sémantique, voir [INSERT INTO](insert-into.md). ``` INSERT INTO [db_name.]table_name [(col1, col2, …)] query ``` Les exemples suivants insèrent des valeurs dans la table `iceberg_table`. ``` INSERT INTO iceberg_table VALUES (1,'a','c1') ``` ``` INSERT INTO iceberg_table (col1, col2, ...) VALUES (val1, val2, ...) ``` ``` INSERT INTO iceberg_table SELECT * FROM another_table ``` # DELETE Athena Iceberg `DELETE` écrit les fichiers de suppression de position Iceberg dans une table. C'est ce que l'on appelle une merge-on-readsuppression. Contrairement à une copy-on-writesuppression, celle-ci est plus efficace car elle ne réécrit pas les données du fichier. merge-on-read Lorsque Athena lit les données Iceberg, elle fusionne les fichiers de suppression de position Iceberg avec des fichiers de données pour produire la dernière vue d'un tableau. Pour supprimer ces fichiers de suppression de position, vous pouvez exécuter [l'action de compactage REWRITE DATA](querying-iceberg-data-optimization.md#querying-iceberg-data-optimization-rewrite-data-action) (RÉÉCRITURE DES DONNÉES). Les opérations `DELETE` sont facturées en fonction de la quantité de données analysées. Pour la syntaxe, consultez [DELETE](delete-statement.md). L'exemple suivant supprime les lignes de `iceberg_table` qui ont `c3` comme valeur pour `category`. ``` DELETE FROM iceberg_table WHERE category='c3' ``` # UPDATE Athena Iceberg `UPDATE` écrit les fichiers de suppression de position Iceberg et les nouvelles lignes mises à jour en tant que fichiers de données dans la même transaction.`UPDATE` peut être imaginé comme une combinaison de `INSERT INTO` et `DELETE`. Les opérations `UPDATE` sont facturées en fonction de la quantité de données analysées. Pour la syntaxe, consultez [UPDATE](update-statement.md). L'exemple suivant met à jour les valeurs spécifiées dans la table `iceberg_table`. ``` UPDATE iceberg_table SET category='c2' WHERE category='c1' ``` # MERGE INTO Mise à jour, suppression ou insertion conditionnelle de lignes dans une table Iceberg. Une seule instruction peut combiner des actions de mise à jour, de suppression et d'insertion. Pour la syntaxe, consultez [MERGE INTO](merge-into-statement.md). **Note** `MERGE INTO` est transactionnel et n'est pris en charge que pour les tables Apache Iceberg dans la version 3 du moteur Athena. L'exemple suivant supprime tous les clients de la table `t` qui se trouvent dans la table source `s`. ``` MERGE INTO accounts t USING monthly_accounts_update s ON t.customer = s.customer WHEN MATCHED THEN DELETE ``` L'exemple suivant met à jour la table cible `t` avec les informations des clients provenant de la table source `s`. Pour les lignes de clients dans la table `t` qui ont des lignes de clients correspondantes dans la table `s`, l'exemple incrémente les achats dans la table t. Si la table `t` ne correspond pas à une ligne de client dans la table `s`, l'exemple insère la ligne de client de la table `s` dans la table `t`. ``` MERGE INTO accounts t USING monthly_accounts_update s ON (t.customer = s.customer) WHEN MATCHED THEN UPDATE SET purchases = s.purchases + t.purchases WHEN NOT MATCHED THEN INSERT (customer, purchases, address) VALUES(s.customer, s.purchases, s.address) ``` L'exemple suivant met à jour de manière conditionnelle la table cible `t` avec les informations de la table source `s`. L'exemple supprime toute ligne cible correspondante dont l'adresse source est Centreville. Pour toutes les autres lignes correspondantes, l'exemple ajoute les achats source et définit l'adresse cible comme adresse source. S'il n'y a aucune correspondance dans la table cible, l'exemple insère la ligne de la table source. ``` MERGE INTO accounts t USING monthly_accounts_update s ON (t.customer = s.customer) WHEN MATCHED AND s.address = 'Centreville' THEN DELETE WHEN MATCHED THEN UPDATE SET purchases = s.purchases + t.purchases, address = s.address WHEN NOT MATCHED THEN INSERT (customer, purchases, address) VALUES(s.customer, s.purchases, s.address) ``` # Gestion des tables Iceberg Athena prend en charge les opérations DDL de table suivantes pour les tables Iceberg. **Topics** + [ALTER TABLE RENAME](querying-iceberg-alter-table-rename.md) + [ALTER TABLE SET TBLPROPERTIES](querying-iceberg-alter-table-set-properties.md) + [ALTER TABLE UNSET TBLPROPERTIES](querying-iceberg-alter-table-unset-properties.md) + [DESCRIBE](querying-iceberg-describe-table.md) + [DROP TABLE](querying-iceberg-drop-table.md) + [SHOW CREATE TABLE](querying-iceberg-show-create-table.md) + [SHOW TBLPROPERTIES](querying-iceberg-show-table-properties.md) # ALTER TABLE RENAME Renomme une table. Étant donné que les métadonnées de table d'une table Iceberg sont stockées dans Simple Storage Service (Amazon S3), vous pouvez mettre à jour la base de données et le nom de la table d'une table gérée Iceberg sans affecter les informations de table sous-jacentes. ## Résumé ``` ALTER TABLE [db_name.]table_name RENAME TO [new_db_name.]new_table_name ``` ## Exemple ``` ALTER TABLE my_db.my_table RENAME TO my_db2.my_table2 ``` # ALTER TABLE SET TBLPROPERTIES Ajoute des propriétés à une table Iceberg et définit les valeurs qui leur sont attribuées. Conformément aux [spécifications Iceberg](https://iceberg.apache.org/#spec/#table-metadata-fields), les propriétés de la table sont stockées dans le fichier de métadonnées de la table Iceberg plutôt que dans AWS Glue. Athena n'accepte pas les propriétés de table personnalisées. Reportez-vous à la section [Spécification de propriétés de table](querying-iceberg-creating-tables.md#querying-iceberg-table-properties) en ce qui concerne les paires clé-valeur autorisées. Vous pouvez également utiliser `ALTER TABLE SET TBLPROPERTIES` et `ALTER TABLE UNSET TBLPROPERTIES` pour définir ou supprimer les propriétés des tables `write.data.path` et `write.object-storage.path` Iceberg. Si vous souhaitez qu'Athena prenne en charge une propriété de configuration de table open source spécifique, envoyez vos commentaires à [athena-feedback@amazon.com](mailto:athena-feedback@amazon.com). ## Résumé ``` ALTER TABLE [db_name.]table_name SET TBLPROPERTIES ('property_name' = 'property_value' [ , ... ]) ``` ## Exemple ``` ALTER TABLE iceberg_table SET TBLPROPERTIES ( 'format'='parquet', 'write_compression'='snappy', 'optimize_rewrite_delete_file_threshold'='10' ) ``` L'exemple suivant définit la `write.data.path` propriété sur une table Iceberg existante. ``` ALTER TABLE iceberg_table SET TBLPROPERTIES ( 'write.data.path'='s3://amzn-s3-demo-bucket/your-folder/data' ) ``` # ALTER TABLE UNSET TBLPROPERTIES Supprime les propriétés existantes d'une table Iceberg. ## Résumé ``` ALTER TABLE [db_name.]table_name UNSET TBLPROPERTIES ('property_name' [ , ... ]) ``` ## Exemple ``` ALTER TABLE iceberg_table UNSET TBLPROPERTIES ('write_compression') ``` L'exemple suivant supprime la `write.data.path` propriété d'une table Iceberg. ``` ALTER TABLE iceberg_table UNSET TBLPROPERTIES ('write.data.path') ``` # DESCRIBE Décrit les informations du tableau. ## Résumé ``` DESCRIBE [FORMATTED] [db_name.]table_name ``` Lorsque l'option `FORMATTED` est spécifiée, la sortie affiche des informations supplémentaires telles que l'emplacement de la table et les propriétés. ## Exemple ``` DESCRIBE iceberg_table ``` # DROP TABLE Supprime une table Iceberg. **Avertissement** Étant donné que les tables Iceberg sont considérées comme des tables gérées dans Athena, la suppression d'une table Iceberg supprime également toutes les données de la table. ## Résumé ``` DROP TABLE [IF EXISTS] [db_name.]table_name ``` ## Exemple ``` DROP TABLE iceberg_table ``` # SHOW CREATE TABLE Affiche une instruction DDL `CREATE TABLE` qui peut être utilisée pour recréer la table Iceberg dans Athena. Si Athena ne peut pas reproduire la structure de la table (par exemple, parce que les propriétés de table personnalisées sont spécifiées dans la table), une erreur UNSUPPORTED (NON PRIS EN CHARGE) est générée. ## Résumé ``` SHOW CREATE TABLE [db_name.]table_name ``` ## Exemple ``` SHOW CREATE TABLE iceberg_table ``` # SHOW TBLPROPERTIES Affiche une ou plusieurs propriétés de table d'une table Iceberg. Seules les propriétés de table prises en charge par Athena s'affichent. ## Résumé ``` SHOW TBLPROPERTIES [db_name.]table_name [('property_name')] ``` ## Exemple ``` SHOW TBLPROPERTIES iceberg_table ``` # Modification du schéma de table Iceberg Les mises à jour du schéma Iceberg sont des modifications de métadonnées uniquement. Aucun fichier de données n'est modifié lorsque vous effectuez une mise à jour du schéma. Le format Iceberg prend en charge les modifications suivantes de l'évolution du schéma : + **Add** (Ajouter) – Ajoute une nouvelle colonne à une table ou à un `struct` imbriqué. + **Drop** (Supprimer) – Supprime une colonne existante d'une table ou d'un `struct` imbriqué. + **Rename** (Renommer) – Renomme une colonne ou un champ existant dans un `struct` imbriqué. + **Reorder** (Réorganiser) – Modifie l'ordre des colonnes. + **Type promotion** (Promotion de type) – Élargit le type d'une colonne, d'un champ `struct`, d'une clé `map`, d'une valeur `map`, ou d'un élément `list`. Actuellement, les cas suivants sont pris en charge pour les tables Iceberg : + entier à grand nombre entier + float à double + augmentation de la précision d'un type décimal Vous pouvez utiliser les instructions DDL de cette section pour modifier le schéma de table Iceberg. **Topics** + [ALTER TABLE ADD COLUMNS](querying-iceberg-alter-table-add-columns.md) + [ALTER TABLE DROP COLUMN](querying-iceberg-alter-table-drop-column.md) + [ALTER TABLE CHANGE COLUMN](querying-iceberg-alter-table-change-column.md) + [SHOW COLUMNS](querying-iceberg-show-columns.md) # ALTER TABLE ADD COLUMNS Ajoute une ou plusieurs colonnes à une table Iceberg existante. ## Résumé ``` ALTER TABLE [db_name.]table_name ADD COLUMNS (col_name data_type [,...]) ``` ## Exemples L'exemple suivant ajoute une colonne `comment` de type `string` sur une table Iceberg. ``` ALTER TABLE iceberg_table ADD COLUMNS (comment string) ``` L'exemple suivant ajoute une colonne `point` de type `struct` sur une table Iceberg. ``` ALTER TABLE iceberg_table ADD COLUMNS (point struct) ``` L'exemple suivant ajoute une colonne `points` qui est un tableau de structures à une table Iceberg. ``` ALTER TABLE iceberg_table ADD COLUMNS (points array>) ``` # ALTER TABLE DROP COLUMN Supprime une colonne d'une table Iceberg existante. ## Résumé ``` ALTER TABLE [db_name.]table_name DROP COLUMN col_name ``` ## Exemple ``` ALTER TABLE iceberg_table DROP COLUMN userid ``` # ALTER TABLE CHANGE COLUMN Modifie le nom, le type, l’ordre ou le commentaire d’une colonne d’une table Iceberg. **Note** `ALTER TABLE REPLACE COLUMNS` n’est pas pris en charge. Étant donné que `REPLACE COLUMNS` supprime toutes les colonnes, puis en ajoute de nouvelles, elle n'est pas prise en charge pour Iceberg. `CHANGE COLUMN` est la syntaxe préférée pour l'évolution du schéma. ## Résumé ``` ALTER TABLE [db_name.]table_name CHANGE [COLUMN] col_old_name col_new_name column_type [COMMENT col_comment] [FIRST|AFTER column_name] ``` ## Exemple ``` ALTER TABLE iceberg_table CHANGE comment blog_comment string AFTER id ``` # SHOW COLUMNS Affiche les colonnes d'un tableau. ## Résumé ``` SHOW COLUMNS (FROM|IN) [db_name.]table_name ``` ## Exemple ``` SHOW COLUMNS FROM iceberg_table ``` # Exécution d’autres opérations DDL sur des tables Iceberg Outre les opérations de modification de schéma décrites dans [Modification du schéma de table Iceberg](querying-iceberg-evolving-table-schema.md), vous pouvez également effectuer les opérations DDL suivantes sur les tables Apache Iceberg dans Athena. ## Opérations de base de données Lorsque vous utilisez [DROP DATABASE](drop-database.md) avec l'option `CASCADE`, toutes les données de table Iceberg sont également supprimées. Les opérations DDL suivantes n'ont aucun effet sur les tables Iceberg. + [CREATE DATABASE](create-database.md) + [ALTER DATABASE SET DBPROPERTIES](alter-database-set-dbproperties.md) + [SHOW DATABASES](show-databases.md) + [SHOW TABLES](show-tables.md) + [SHOW VIEWS](show-views.md) ## Opérations liées à la partition Parce que les tables Iceberg utilisent un [partitionnement masqué](https://iceberg.apache.org/docs/latest/partitioning/#icebergs-hidden-partitioning), vous n'avez pas à travailler directement avec des partitions physiques. Par conséquent, les tables Iceberg d'Athena ne prennent pas en charge les opérations DDL suivantes liées à la partition : + [SHOW PARTITIONS](show-partitions.md) + [ALTER TABLE ADD PARTITION](alter-table-add-partition.md) + [ALTER TABLE DROP PARTITION](alter-table-drop-partition.md) + [ALTER TABLE RENAME PARTITION](alter-table-rename-partition.md) Si vous souhaitez voir [l'évolution des partitions](https://iceberg.apache.org/docs/latest/evolution/#partition-evolution) Iceberg dans Athena, envoyez vos commentaires à [athena-feedback@amazon.com](mailto:athena-feedback@amazon.com). ## Déchargement de tables Iceberg Les tables Iceberg peuvent être déchargées dans des fichiers d'un dossier sur Simple Storage Service (Amazon S3). Pour plus d'informations, consultez [UNLOAD](unload.md). ## MSCK REPAIR Étant donné que les tables Iceberg conservent les informations relatives à la mise en page des tables, l'exécution de [MSCK REPAIR TABLE](msck-repair-table.md) comme on le fait avec les tables Hive n'est pas nécessaire et n'est pas prise en charge. # Optimisation des tables Iceberg Athena fournit plusieurs fonctionnalités d'optimisation pour améliorer les performances des requêtes sur les tables Apache Iceberg. À mesure que les données s'accumulent, les requêtes peuvent devenir moins efficaces en raison de l'augmentation de la charge de traitement des fichiers et du coût de calcul lié à l'application des suppressions au niveau des lignes stockées dans les fichiers de suppression Iceberg. Pour relever ces défis, Athena prend en charge les opérateurs manuels de compactage et d'aspiration afin d'optimiser la structure des tables. Athena utilise également les statistiques d'Iceberg pour permettre l'optimisation des requêtes basée sur les coûts et l'indexation des colonnes Parquet pour un élagage précis des données lors de l'exécution des requêtes. Ces fonctionnalités fonctionnent ensemble pour réduire le temps d'exécution des requêtes, minimiser l'analyse des données et réduire les coûts. Cette rubrique explique comment utiliser ces fonctionnalités d'optimisation pour maintenir des requêtes de haute performance sur vos tables Iceberg. ## OPTIMIZE L'action de compactage `OPTIMIZE table REWRITE DATA` réécrit les fichiers de données dans une disposition plus optimisée en fonction de leur taille et du nombre de fichiers de suppression associés. Pour plus de détails sur la syntaxe et les propriétés des tables, voir [OPTIMIZE](optimize-statement.md). ### Exemple L'exemple suivant fusionne les fichiers de suppression dans des fichiers de données et produit des fichiers proches de la taille de fichier ciblée où la valeur de `category` est `c1`. ``` OPTIMIZE iceberg_table REWRITE DATA USING BIN_PACK WHERE category = 'c1' ``` ## VACUUM `VACUUM` exécute l'[expiration d'instantané](https://iceberg.apache.org/docs/latest/spark-procedures/#expire_snapshots) et la [suppression des fichiers orphelins](https://iceberg.apache.org/docs/latest/spark-procedures/#remove_orphan_files). Ces actions réduisent la taille des métadonnées et suppriment les fichiers qui ne figurent pas dans l'état actuel de la table et qui sont également plus anciens que la période de rétention spécifiée pour la table. Pour plus de détails sur la syntaxe, voir [VACUUM](vacuum-statement.md). ### Exemple L'exemple suivant utilise une propriété de table pour configurer la table `iceberg_table` afin de retenir les données des trois derniers jours, puis utilise `VACUUM` pour faire expirer les anciens instantanés et supprimer les fichiers orphelins de la table. ``` ALTER TABLE iceberg_table SET TBLPROPERTIES ( 'vacuum_max_snapshot_age_seconds'='259200' ) VACUUM iceberg_table ``` ## Utiliser les statistiques des tables Iceberg L'optimiseur basé sur les coûts d'Athena utilise les statistiques d'Iceberg pour produire des plans de requêtes optimaux. Lorsque des statistiques ont été générées pour vos tables Iceberg, Athena utilise automatiquement ces informations pour prendre des décisions intelligentes concernant l'ordre des jointures, les filtres et le comportement d'agrégation, ce qui améliore souvent les performances des requêtes et réduit les coûts. Les statistiques Iceberg sont activées par défaut lorsque vous utilisez les tables S3. Pour les autres tables Iceberg, Athena utilise la `use_iceberg_statistics` propriété table pour déterminer s'il convient de tirer parti des statistiques pour une optimisation basée sur les coûts. Pour commencer, consultez la section [Optimisation des performances des requêtes à l'aide des statistiques de colonne](https://docs.aws.amazon.com//glue/latest/dg/column-statistics.html) dans le *Guide de AWS Glue l'utilisateur* ou utilisez la [console Athena](https://docs.aws.amazon.com/athena/latest/ug/cost-based-optimizer.html) pour générer des statistiques à la demande sur vos tables Iceberg. ## Utiliser l'indexation des colonnes Parquet L'indexation des colonnes Parquet permet à Athena d'effectuer un élagage des données plus précis lors de l'exécution des requêtes en exploitant les statistiques au niveau des min/max pages en plus des statistiques au niveau des groupes de lignes. Cela permet à Athena d'ignorer les pages inutiles au sein des groupes de lignes, ce qui réduit considérablement la quantité de données numérisées et améliore les performances des requêtes. Il fonctionne parfaitement pour les requêtes utilisant des prédicats de filtre sélectifs sur des colonnes triées, ce qui améliore à la fois le temps d'exécution et l'efficacité de l'analyse des données tout en réduisant la quantité de données qu'Athena doit lire sur Amazon S3. Athena utilise les index de colonnes Parquet par défaut avec S3 Tables si des index de colonnes sont présents dans les fichiers Parquet sous-jacents. Pour les autres tables Iceberg, Athena utilise `use_iceberg_parquet_column_index` cette propriété pour déterminer s'il convient d'utiliser les index des colonnes du fichier Parquet. Définissez cette propriété de table à l'aide de la AWS Glue console ou de `UpdateTable` l'API. # Vues matérialisées du catalogue de AWS Glue données de requête Athena vous permet d'interroger les vues matérialisées du catalogue de AWS Glue données. Les vues matérialisées de Glue Data Catalog stockent les résultats précalculés des requêtes SQL sous forme de tables Apache Iceberg. Lorsque vous créez des vues matérialisées du catalogue de données Glue à l'aide d'Apache Spark dans Amazon EMR, AWS Glue ou lorsque les définitions de vues et les métadonnées sont stockées dans AWS Glue le catalogue de données. Les résultats précalculés sont stockés sous forme de tables Apache Iceberg dans Amazon S3. Vous pouvez interroger ces vues matérialisées depuis Athena à l'aide d'instructions `SELECT` SQL standard, comme vous le feriez pour les tables Iceberg classiques. ## Conditions préalables Avant de demander des vues matérialisées dans Athena, assurez-vous de ce qui suit : + La vue matérialisée existe dans le catalogue de AWS Glue données et a été créée à l'aide d'Apache Spark (Amazon EMR version 7.12.0 ou ultérieure, ou version 5.1 AWS Glue ou ultérieure) + Pour interroger des vues matérialisées dans Athena, vous devez disposer des autorisations suivantes : AWS Lake Formation + `SELECT`autorisation sur la vue matérialisée + `DESCRIBE`autorisation sur la vue matérialisée + Accès à l'emplacement Amazon S3 sous-jacent où les données de vue matérialisées sont stockées + Les données sous-jacentes de la vue matérialisée sont stockées dans des compartiments de table Amazon S3 ou des compartiments à usage général Amazon S3 + Vous avez accès à la base de AWS Glue données du catalogue de données contenant la vue matérialisée + Pour les vues matérialisées stockées dans des compartiments Amazon S3 Tables, assurez-vous que votre rôle IAM dispose des autorisations nécessaires pour accéder au catalogue de tables S3. ## Considérations et restrictions + Athena ne prend pas en charge les opérations suivantes sur les vues matérialisées :`ALTER`,`CREATE MATERIALIZED VIEW`,`REFRESH MATERIALIZED VIEW`,`DROP`,,`INSERT`, `UPDATE``MERGE`,`DELETE`. `OPTIMIZE` `VACUUM` Pour créer des vues matérialisées, utilisez Apache Spark dans Amazon AWS Glue EMR ou. Les opérations d'actualisation doivent être effectuées via l'API AWS Glue Data Catalog ou Apache Spark. Modifiez les vues matérialisées à l'aide d'Apache Spark. ## Interrogation de vues matérialisées Athena traite les vues matérialisées comme des tables Iceberg standard pour les opérations de lecture, ce qui vous permet d'accéder aux données précalculées sans nécessiter de modifications spéciales de syntaxe ou de configuration. Pour interroger une vue matérialisée dans Athena, utilisez `SELECT` les instructions standard : ``` SELECT * FROM my_database.sales_summary_mv; ``` Vous pouvez appliquer des filtres, des agrégations et des jointures comme vous le feriez avec des tables classiques : ``` SELECT region, SUM(total_sales) as sales_total FROM my_database.sales_summary_mv WHERE year = 2025 GROUP BY region ORDER BY sales_total DESC; ``` ## Opérations prises en charge Athena prend en charge les opérations suivantes sur les vues matérialisées : + `SELECT`requêtes - Lire des données à partir de vues matérialisées à l'aide d'instructions SQL `SELECT` standard + `DESCRIBE`- Afficher le schéma et les métadonnées des vues matérialisées + `SHOW TABLES`- Répertorier les vues matérialisées ainsi que les autres tables d'une base de données + `JOIN`opérations - Joindre des vues matérialisées à d'autres tables ou vues + Filtrage et agrégation - Appliquer `WHERE` des `GROUP BY` clauses et agréger des fonctions # Types de données pris en charge pour les tables Iceberg sur Athena Athena peut interroger des tables Iceberg contenant les types de données suivants : ``` binary boolean date decimal double float int list long map string struct timestamp without time zone ``` Pour plus d’informations sur les types de tables Iceberg, consultez la [page de schémas pour Iceberg](https://iceberg.apache.org/docs/latest/schemas/) dans la documentation Apache. Le tableau suivant illustre la relation entre les types de données Athena et les types de données de table Iceberg. **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/athena/latest/ug/querying-iceberg-supported-data-types.html) Pour de plus amples informations sur les types de données sur Athena, consultez [Types de données dans Amazon Athena](data-types.md). # Ressources supplémentaires L'article suivant se trouve dans la documentation des directives AWS prescriptives. + [Working with Apache Iceberg tables by using Amazon Athena SQL](https://docs.aws.amazon.com/prescriptive-guidance/latest/apache-iceberg-on-aws/iceberg-athena.html) Pour des articles détaillés sur l'utilisation d'Athena avec les tables Apache Iceberg, consultez les billets suivants sur le *blog AWS Big Data*. + [Implement a serverless CDC process with Apache Iceberg using Amazon DynamoDB and Amazon Athena](https://aws.amazon.com/blogs/big-data/implement-a-serverless-cdc-process-with-apache-iceberg-using-amazon-dynamodb-and-amazon-athena/) + [Accélérer l'ingénierie des fonctionnalités de la science des données sur les lacs de données transactionnels en utilisant Amazon Athena avec Apache Iceberg](https://aws.amazon.com/blogs/big-data/accelerate-data-science-feature-engineering-on-transactional-data-lakes-using-amazon-athena-with-apache-iceberg/) + [Créez un lac de données Apache Iceberg à l'aide d'Amazon Athena, Amazon EMR et AWS Glue](https://aws.amazon.com/blogs/big-data/build-an-apache-iceberg-data-lake-using-amazon-athena-amazon-emr-and-aws-glue/) + [Exécuter des mises à jour/insertions dans un lac de données en utilisant Amazon Athena et Apache Iceberg](https://aws.amazon.com/blogs/big-data/perform-upserts-in-a-data-lake-using-amazon-athena-and-apache-iceberg/) + [Créez un lac de données transactionnel à l'aide d'Apache Iceberg et partagez AWS Glue des données entre comptes à l'aide d'Amazon Athena AWS Lake Formation](https://aws.amazon.com/blogs/big-data/build-a-transactional-data-lake-using-apache-iceberg-aws-glue-and-cross-account-data-shares-using-aws-lake-formation-and-amazon-athena/) + [Utiliser Apache Iceberg dans un lac de données pour prendre en charge le traitement incrémentiel des données](https://aws.amazon.com/blogs/big-data/use-apache-iceberg-in-a-data-lake-to-support-incremental-data-processing/) + [Créer en temps réel un lac de données Apache Iceberg aligné sur le RGPD](https://aws.amazon.com/blogs/big-data/build-a-real-time-gdpr-aligned-apache-iceberg-data-lake/) + [Automatisez la réplication des sources relationnelles dans un lac de données transactionnel avec Apache Iceberg et AWS Glue](https://aws.amazon.com/blogs/big-data/automate-replication-of-relational-sources-into-a-transactional-data-lake-with-apache-iceberg-and-aws-glue/) + [Interagissez avec les tables Apache Iceberg à l'aide d'Amazon Athena et avec des autorisations détaillées entre comptes à l'aide de AWS Lake Formation](https://aws.amazon.com/blogs/big-data/interact-with-apache-iceberg-tables-using-amazon-athena-and-cross-account-fine-grained-permissions-using-aws-lake-formation/) + [Créer un lac de données transactionnel sans serveur avec Apache Iceberg, Amazon EMR sans serveur et Amazon Athena](https://aws.amazon.com/blogs/big-data/build-a-serverless-transactional-data-lake-with-apache-iceberg-amazon-emr-serverless-and-amazon-athena/)