New user sign up using AWS Builder ID
New user sign up using AWS Builder ID is currently unavailable on re:Post. To sign up, please use the AWS Management Console instead.
Comment gérer et optimiser les tables Iceberg pour un stockage et une interrogation efficaces des données ?
Je souhaite optimiser mes tables Apache Iceberg afin de pouvoir stocker et interroger efficacement les données.
Résolution
Choisissez le type de table Iceberg adapté à votre cas d'utilisation
La résolution que vous choisissez dépend du type de table Iceberg que vous configurez.
Utiliser une table Copy-On-Write (CoW) pour les lectures
Dans ce type de table Iceberg, toute opération de mise à jour ou de suppression que vous effectuez sur les enregistrements entraîne la réécriture des fichiers de données correspondants en arrière-plan. Une réécriture ralentit les performances, en particulier s'il existe plusieurs mises à jour et suppressions. Utilisez une table CoW si vos cas d'utilisation impliquent plus de lectures que d'écritures.
Pour convertir une table Iceberg existante en table CoW, exécutez la commande SQL Apache Spark suivante :
spark.sql("ALTER TABLE <table-name> SET TBLPROPERTIES ('write.delete.mode'='copy-on-write','write.update.mode'='copy-on-write')")
Pour créer une nouvelle table CoW, utilisez les propriétés de table 'write.delete.mode'='copy-on-write','write.update.mode'='copy-on-write' :
dataFrame.createOrReplaceTempView("tmp_<your_table_name>") query = f""" CREATE TABLE glue_catalog.<your_database_name>.<your_table_name> USING iceberg TBLPROPERTIES ('format-version'='2','write.delete.mode'='copy-on-write','write.update.mode'='copy-on-write') AS SELECT * FROM tmp_<your_table_name> """ spark.sql(query)
Utiliser une table Merge-On-Read (MoR) pour les écritures
Lorsque vous mettez à jour ou supprimez des enregistrements dans une table MoR, l'action entraîne l’ajout de nouveaux fichiers de données. Les fichiers de données de suppression récemment ajoutés sont fusionnés lors d'une lecture. Cependant, les opérations d'écriture nécessitent que vous ajoutiez simplement de nouveaux fichiers à des fichiers existants. Si vous écrivez plus fréquemment de données dans la table que vous n'en lisez, sélectionnez une table MoR.
Pour utiliser une table MoR Iceberg, exécutez la commande Spark SQL suivante :
spark.sql("ALTER TABLE <table-name> SET TBLPROPERTIES ('write.delete.mode'='merge-on-read','write.update.mode'='merge-on-read')")
Remarque : Il est recommandé de créer les tables Iceberg à partir d'un moteur Spark. Vous pouvez également utiliser AWS Glue, EMR Spark ou Amazon Athena pour créer les tables. Cependant, Athena prend en charge de manière limitée les propriétés des tables et utilise uniquement le type de table MoR.
Optimiser les tables Iceberg
Les tables Iceberg peuvent indiquer une baisse des performances des requêtes en raison d'une augmentation du nombre de fichiers de métadonnées, de suppressions de fichiers, etc. Voici quelques méthodes que vous pouvez utiliser pour optimiser l'efficacité des requêtes et le stockage des données.
Faire expirer des instantanés
Les tables Iceberg conservent des instantanés afin que vous puissiez récupérer des données à partir d'un état plus ancien de la table. Ces instantanés sont écrits pour chaque opération d'écriture effectuée sur la table et l'ID d’instantané correspondant est ajouté au nouveau fichier de métadonnées. Au fil du temps, le nombre d’instantanés augmente la taille du fichier de métadonnées. Ces instantanés supplémentaires créent un ralentissement des performances des requêtes.
Pour faire expirer les instantanés, utilisez les options suivantes :
-
Utilisez l'opération expireSnapshots dans Spark pour faire expirer des instantanés antérieurs à un horodatage spécifié en parallèle pour les tables volumineuses :
SparkActions.get() .expireSnapshots(table) .expireOlderThan(tsToExpire) .execute()
-
Vous pouvez également utiliser une procédure appelée expire_snapshots. Pour plus d'informations, consultez expire_snapshots sur le site Web d'Iceberg.
spark.sql("CALL glue_catalog.system.expire_snapshots('databasename.tablename',<timestamp value>)")
Exécutez le code précédent dans le cadre d'une tâche AWS Glue à intervalles réguliers. Lorsque vous automatisez l'expiration des instantanés, vous pouvez limiter le nombre de fichiers de données, limiter la taille du fichier de métadonnées et assurer des performances de requête efficaces.
Supprimer les anciens fichiers de métadonnées
Définissez la propriété de table write.metadata.delete-after-commit.enabled sur True pour supprimer automatiquement les anciens fichiers de métadonnées après chaque validation de table. Vous pouvez également définir write.metadata.previous-versions-max pour gérer le nombre d'anciens fichiers de métadonnées à conserver.
Réécrire les fichiers manifestes
Une table Iceberg utilise des manifestes et des fichiers manifestes pour suivre tous les fichiers de données. Au fil du temps, chaque instantané fait référence à de nombreux fichiers manifestes. Ces opérations ralentissent les requêtes. Pour plus d'informations, consultez les listes de manifestes et les ](https://iceberg.apache.org/spec/#manifests)fichiers manifestes[ sur le site Web d'Iceberg.
Utilisez la procédure de réécriture des manifestes pour gérer efficacement les fichiers manifestes. Pour plus d'informations, consultez rewrite_manifests sur le site Web d'Iceberg.
Exécutez la requête Spark SQL suivante :
spark.sql("CALL glue_catalog.system.rewrite_manifests('databasename.tablename')")
Réécrire les fichiers de données
Iceberg gère et suit tous les fichiers de données de la table dans un fichier de métadonnées. Au fil du temps, de nombreux fichiers de données accumulés augmentent la taille du fichier de métadonnées. Les fichiers inutiles ou ouverts dans le fichier de métadonnées diminuent l'efficacité de lecture. La procédure de réécriture_data_files de Spark permet de compacter les données en parallèle et d'améliorer l'efficacité de lecture. Pour plus d'informations, consultez rewrite_data_files sur le site Web d'Iceberg.
Exécutez la commande Spark SQL suivante :
spark.sql("CALL glue_catalog.system.rewrite_data_files(table=>'databasename.tablename')")
Utilisez les stratégies BINPACK ou SORT pour réécrire les fichiers de données en fonction de votre cas d'utilisation. Pour plus d'informations, consultez BINPACK et SORT sur le site Web d'Iceberg.
BINPACK : Il s’agit de l'approche la moins coûteuse et la plus rapide. Elle combine les petits fichiers en fichiers plus volumineux et réduit le nombre total de fichiers de sortie. L'ordre des enregistrements n'est pas perturbé et aucun remaniement des données n’a lieu. Il s'agit du rôle par défaut.
CALL catalog.system.rewrite_data_files( table => 'test_table', strategy => 'binpack', options => map( 'rewrite-job-order','bytes-asc', 'target-file-size-bytes','<set-afile-size>', 'max-file-group-size-bytes','<max-group-size>' -- 10GB ) )
SORT : La stratégie SORT trie les données tout en compactant les fichiers. Cette stratégie est utile lorsque vous exécutez de nombreuses fonctions d'agrégation qui comparent les enregistrements voisins (par exemple, les fonctions min ou max).
CALL catalog\_name.system.rewrite\_data\_files( table => 'databasename.tablename', strategy => 'sort', sort\_order => 'id', --can be any column options => map('rewrite-all','true') )
Supprimer les fichiers orphelins
Les fichiers orphelins ne sont référencés dans aucun des fichiers de métadonnées. Pour plus d'informations, consultez remove_orphan_files sur le site Web d'Iceberg.
Pour supprimer des fichiers orphelins, exécutez la commande remove_orphan_files comme indiqué ci-dessous :
spark.sql("CALL glue_catalog.system.remove_orphan_files(table=>'databasename.tablename')")
Remarque : Il est recommandé d’exécuter une tâche planifiée pour gérer les activités de maintenance. Utilisez une seule tâche AWS Glue pour exécuter toutes les requêtes Spark SQL ci-dessus.
Informations connexes

Contenus pertinents
- demandé il y a 4 moislg...
- demandé il y a 5 moislg...
- demandé il y a un moislg...
- demandé il y a un anlg...
- AWS OFFICIELA mis à jour il y a 2 mois
- AWS OFFICIELA mis à jour il y a 2 mois
- AWS OFFICIELA mis à jour il y a 7 mois
- AWS OFFICIELA mis à jour il y a 2 ans