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. # 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/)