Utilisation de tables Apache Iceberg à l'aide d'Amazon Athena SQL

Amazon Athena fournit un support intégré pour Apache Iceberg et ne nécessite aucune étape ni configuration supplémentaires. Cette section fournit un aperçu détaillé des fonctionnalités prises en charge et des conseils de haut niveau sur l'utilisation d'Athena pour interagir avec les tables Iceberg.

Compatibilité des versions et des fonctionnalités

Note

Les sections suivantes supposent que vous utilisez la version 3 du moteur Athena.

Support pour les spécifications des tables Iceberg

La spécification des tables Apache Iceberg indique comment les tables Iceberg doivent se comporter. Athena prend en charge le format de table version 2, de sorte que toute table Iceberg que vous créez avec la console, la CLI ou le SDK utilise intrinsèquement cette version.

Si vous utilisez une table Iceberg créée avec un autre moteur, tel qu'Apache Spark sur Amazon EMR, AWS Glue ou assurez-vous de définir la version du format de la table à l'aide des propriétés de la table. À titre de référence, consultez la section Création et écriture de tables Iceberg plus haut dans ce guide.

Support des fonctionnalités Iceberg

Vous pouvez utiliser Athena pour lire et écrire dans des tables Iceberg. Lorsque vous modifiez des données à l'aide des DELETE FROM instructionsUPDATE,MERGE INTO, et, Athena prend uniquement en charge le merge-on-read mode. Cette propriété ne peut pas être modifiée. Pour mettre à jour ou supprimer des données avec copy-on-write, vous devez utiliser d'autres moteurs tels que Apache Spark sur Amazon EMR ou. AWS Glue Le tableau suivant résume la prise en charge des fonctionnalités d'Iceberg dans Athena.

		Support DDL		Support DML		AWS Lake Formation pour des raisons de sécurité (facultatif)
	Format de table	Create table	Évolution du schéma	Lecture de données	Écrire des données	Contrôle d'accès aux lignes/colonnes
Amazon Athena	Version 2	✓	✓	✓	XC opy-on-write	✓
					✓ M erge-on-read	✓

Note

Athena ne prend pas en charge les requêtes incrémentielles.

Utilisation des tables Iceberg

Pour un démarrage rapide de l'utilisation d'Iceberg dans Athena, consultez la section Commencer à utiliser les tables Iceberg dans Athena SQL plus haut dans ce guide.

Le tableau suivant répertorie les limites et les recommandations.

Scénario	Limitation	Recommandation
Génération de tables DDL	Les tables Iceberg créées avec d'autres moteurs peuvent avoir des propriétés qui ne sont pas exposées dans Athena. Pour ces tables, il n'est pas possible de générer le DDL.	Utilisez l'instruction équivalente dans le moteur qui a créé la table (par exemple, l'SHOW CREATE TABLEinstruction pour Spark).
Préfixes Amazon S3 aléatoires dans les objets écrits dans une table Iceberg	Par défaut, la propriété est activée pour les tables Iceberg créées avec Athena. write.object-storage.enabled	Pour désactiver ce comportement et contrôler totalement les propriétés des tables Iceberg, créez une table Iceberg avec un autre moteur tel que Spark sur Amazon EMR ou. AWS Glue
Requêtes progressives	Non pris en charge dans Athena pour le moment.	Pour utiliser des requêtes incrémentielles afin d'activer des pipelines d'ingestion de données incrémentiels, utilisez Spark sur Amazon EMR ou. AWS Glue

Migration de tables existantes vers Iceberg

Pour migrer votre Athena ou vos tables actuelles (également appelées AWS Glue tables Hive) vers le format Iceberg, vous pouvez utiliser la migration des données sur place ou complète :

• La migration sur place est le processus qui consiste à générer les fichiers de métadonnées d'Iceberg en plus des fichiers de données existants.

• La migration complète des données crée la couche de métadonnées Iceberg et réécrit également les fichiers de données existants de la table d'origine vers la nouvelle table Iceberg.

Les sections suivantes présentent une vue d'ensemble des API disponibles pour migrer les tables et fournissent des conseils pour choisir une stratégie de migration. Pour plus d'informations sur ces deux stratégies, consultez la section Migration des tables dans la documentation d'Iceberg.

Migration sur place

La migration sur place élimine le besoin de réécrire tous les fichiers de données. Au lieu de cela, les fichiers de métadonnées Iceberg sont générés et liés à vos fichiers de données existants. Iceberg propose trois options pour mettre en œuvre la migration sur place :

• En utilisant la snapshot procédure, comme expliqué dans les sections Snapshot Table et Procédure Spark : snapshot de la documentation d'Iceberg.

• En utilisant la add_files procédure, comme expliqué dans les sections Ajouter des fichiers et Procédure Spark : add_files de la documentation d'Iceberg.

• En utilisant la migrate procédure, comme expliqué dans les sections Migrate Table et Procédure Spark : Migrate de la documentation Iceberg.

À l'heure actuelle, la procédure de migration ne fonctionne pas directement avec le AWS Glue Data Catalog métastore Hive. Si vous devez utiliser la migrate procédure à la place de snapshot ouadd_files, vous pouvez utiliser un cluster Amazon EMR temporaire avec le métastore Hive (HMS). Cette approche nécessite la version 1.2 ou ultérieure d'Iceberg.

Supposons que vous souhaitiez créer la table Hive suivante :

Vous pouvez créer cette table Hive en exécutant ce code dans la console Athena :

CREATE EXTERNAL TABLE 'hive_table'(
  'id' bigint, 
  'data' string)
USING parquet
LOCATION
  's3://datalake-xxxx/aws_workshop/iceberg_db/hive_table'

INSERT INTO iceberg_db.hive_table VALUES (1, 'a')

Si votre table Hive est partitionnée, incluez l'instruction de partition et ajoutez les partitions conformément aux exigences de Hive.

ALTER TABLE default.placeholder_table_for_migration ADD 
    PARTITION (date = '2023-10-10')

Étapes :

1. Créez un cluster Amazon EMR sans activer l' AWS Glue Data Catalog intégration, c'est-à-dire ne cochez pas les cases pour les métadonnées des tables Hive ou Spark. En effet, vous utiliserez le métastore Hive (HMS) natif disponible dans le cluster pour cette solution de contournement.

   

2. Configurez la session Spark pour utiliser l'implémentation du catalogue Iceberg Hive.

   "spark.sql.extensions":"org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions",
   "spark.sql.catalog.spark_catalog": "org.apache.iceberg.spark.SparkSessionCatalog",
           "spark.sql.catalog.spark_catalog.type": "hive",

3. Vérifiez que votre cluster Amazon EMR n'est pas connecté au AWS Glue Data Catalog en exécutant show databases ou. show tables

   

4. Enregistrez la table Hive dans le métastore Hive de votre cluster Amazon EMR, puis utilisez la procédure Iceberg. migrate

   

   Cette procédure crée les fichiers de métadonnées Iceberg au même emplacement que la table Hive.

5. Enregistrez la table Iceberg migrée dans le. AWS Glue Data Catalog

6. Revenez à un cluster Amazon EMR dont l' AWS Glue Data Catalog intégration est activée.

   

7. Utilisez la configuration Iceberg suivante dans la session Spark.

   "spark.sql.extensions":"org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions",
           "spark.sql.catalog.glue_catalog": "org.apache.iceberg.spark.SparkCatalog",
           "spark.sql.catalog.glue_catalog.warehouse": "s3://datalake-xxxx/aws_workshop",
           "spark.sql.catalog.glue_catalog.catalog-impl": "org.apache.iceberg.aws.glue.GlueCatalog",
           "spark.sql.catalog.glue_catalog.io-impl": "org.apache.iceberg.aws.s3.S3FileIO",

Vous pouvez désormais interroger cette table depuis Amazon EMR ou AWS Glue Athena.

Migration complète des données

La migration complète des données recrée les fichiers de données ainsi que les métadonnées. Cette approche prend plus de temps et nécessite des ressources informatiques supplémentaires par rapport à la migration sur place. Toutefois, cette option permet d'améliorer la qualité des tables : vous pouvez valider les données, modifier le schéma et la partition, récupérer les données, etc. Pour implémenter la migration complète des données, utilisez l'une des options suivantes :

• Utilisez l'instruction CREATE TABLE ... AS SELECT (CTAS) dans Spark on Amazon EMR ou AWS Glue Athena.  Vous pouvez définir la spécification de partition et les propriétés de table pour la nouvelle table Iceberg à l'aide des TBLPROPERTIES clauses PARTITIONED BY et. Vous pouvez affiner le schéma et le partitionnement de la nouvelle table en fonction de vos besoins au lieu de simplement les hériter de la table source.

• Lisez la table source et écrivez les données sous la forme d'une nouvelle table Iceberg à l'aide de Spark sur Amazon EMR AWS Glue ou (voir Création d'une table dans la documentation d'Iceberg).

Choix d'une stratégie de migration

Pour choisir la meilleure stratégie de migration, prenez en compte les questions du tableau suivant.

Question	Recommandation
Quel est le format du fichier de données (par exemple, CSV ou Apache Parquet) ?	Envisagez une migration sur place si le format de votre fichier de table est Parquet, ORC ou Avro. Pour les autres formats tels que CSV, JSON, etc., utilisez la migration complète des données.
Voulez-vous mettre à jour ou consolider le schéma de table ?	Si vous souhaitez faire évoluer le schéma de table à l'aide des fonctionnalités natives d'Iceberg, envisagez une migration sur place. Par exemple, vous pouvez renommer les colonnes après la migration. (Le schéma peut être modifié dans la couche de métadonnées Iceberg.) Si vous souhaitez supprimer des colonnes entières des fichiers de données, nous vous recommandons d'utiliser la migration complète des données.
La table bénéficierait-elle d'une modification de la stratégie de partition ?	Si l'approche de partitionnement d'Iceberg répond à vos exigences (par exemple, les nouvelles données sont stockées en utilisant le nouveau schéma de partition alors que les partitions existantes restent telles quelles), envisagez une migration sur place. Si vous souhaitez utiliser des partitions masquées dans votre table, envisagez une migration complète des données. Pour plus d'informations sur les partitions masquées, consultez la section Bonnes pratiques.
Le tableau bénéficierait-il de l'ajout ou de la modification de la stratégie d'ordre de tri ?	L'ajout ou la modification de l'ordre de tri de vos données nécessite de réécrire le jeu de données. Dans ce cas, envisagez d'utiliser la migration complète des données. Pour les grandes tables où le coût de réécriture de toutes les partitions de table est prohibitif, envisagez d'utiliser la migration sur place et d'exécuter le compactage (avec le tri activé) pour les partitions les plus fréquemment consultées.
La table contient-elle de nombreux petits fichiers ?	La fusion de petits fichiers en fichiers plus volumineux nécessite de réécrire le jeu de données. Dans ce cas, envisagez d'utiliser la migration complète des données. Pour les grandes tables où le coût de réécriture de toutes les partitions de table est prohibitif, envisagez d'utiliser la migration sur place et d'exécuter le compactage (avec le tri activé) pour les partitions les plus fréquemment consultées.