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. # Meilleures pratiques pour optimiser les charges de travail d'Apache Iceberg Iceberg est un format de tableau conçu pour simplifier la gestion des lacs de données et améliorer les performances des charges de travail. Différents cas d'utilisation peuvent donner la priorité à différents aspects tels que le coût, les performances de lecture, les performances d'écriture ou la conservation des données. Iceberg propose donc des options de configuration pour gérer ces compromis. Cette section fournit des informations permettant d'optimiser et de peaufiner vos charges de travail Iceberg afin de répondre à vos besoins. **Topics** + [Bonnes pratiques d'ordre général](best-practices-general.md) + [Optimisation des performances de lecture](best-practices-read.md) + [Optimisation des performances d'écriture](best-practices-write.md) + [Optimisation du stockage](best-practices-storage.md) + [Maintien des tables en utilisant le compactage](best-practices-compaction.md) + [Utilisation des charges de travail Iceberg dans Amazon S3](best-practices-workloads.md) # Bonnes pratiques d'ordre général Quel que soit votre cas d'utilisation, lorsque vous utilisez Apache Iceberg activé AWS, nous vous recommandons de suivre ces bonnes pratiques générales. + **Utilisez le format Iceberg version 2.** Athena utilise le format Iceberg version 2 par défaut. [Lorsque vous utilisez Spark sur Amazon EMR ou AWS Glue pour créer des tables Iceberg, spécifiez la version du format comme décrit dans la documentation d'Iceberg.](https://iceberg.apache.org/docs/nightly/configuration/#reserved-table-properties) + **Utilisez-le AWS Glue Data Catalog comme catalogue de données.** Athéna utilise le AWS Glue Data Catalog par défaut. Lorsque vous utilisez Spark sur Amazon EMR ou AWS Glue que vous travaillez avec Iceberg, ajoutez la configuration suivante à votre session Spark pour utiliser le. AWS Glue Data Catalog Pour plus d'informations, consultez la section [Configurations de Spark pour Iceberg AWS Glue plus haut dans](iceberg-glue.md#glue-spark-config) ce guide. ``` "spark.sql.catalog..type": "glue" ``` + **Utilisez le gestionnaire AWS Glue Data Catalog de verrous.** Athena utilise le gestionnaire de AWS Glue Data Catalog verrous par défaut pour les tables Iceberg. Lorsque vous utilisez Spark sur Amazon EMR ou AWS Glue que vous travaillez avec Iceberg, assurez-vous de configurer la configuration de votre session Spark de manière à utiliser le AWS Glue Data Catalog gestionnaire de verrouillage. Pour plus d'informations, consultez [Optimistic Locking](https://iceberg.apache.org/docs/latest/aws/#optimistic-locking) dans la documentation d'Iceberg. + **Utilisez la compression Zstandard (ZSTD).** Le codec de compression par défaut d'Iceberg est gzip, qui peut être modifié à l'aide de la propriété table. `write..compression-codec` Athena utilise déjà ZSTD comme codec de compression par défaut pour les tables Iceberg. En général, nous recommandons d'utiliser le codec de compression ZSTD, car il établit un équilibre entre GZIP et Snappy et offre de bonnes read/write performances sans compromettre le taux de compression. De plus, les niveaux de compression peuvent être ajustés en fonction de vos besoins. Pour plus d'informations, consultez la section [Niveaux de compression ZSTD dans Athena dans la documentation d'Athena](https://docs.aws.amazon.com/athena/latest/ug/compression-support-zstd-levels.html). Snappy offre peut-être les meilleures performances globales de lecture et d'écriture, mais son taux de compression est inférieur à celui de GZIP et ZSTD. Si vous privilégiez les performances, même si cela implique de stocker des volumes de données plus importants dans Amazon S3, Snappy peut être le meilleur choix. # Optimisation des performances de lecture Cette section décrit les propriétés des tables que vous pouvez régler pour optimiser les performances de lecture, indépendamment du moteur. ## Partitioning Comme pour les tables Hive, Iceberg utilise les partitions comme couche d'indexation principale afin d'éviter de lire des fichiers de métadonnées et des fichiers de données inutiles. Les statistiques des colonnes sont également prises en compte en tant que couche secondaire d'indexation afin d'améliorer encore la planification des requêtes, ce qui se traduit par un meilleur temps d'exécution global. ### Partitionner vos données Pour réduire la quantité de données scannées lors de l'interrogation des tables Iceberg, choisissez une stratégie de partition équilibrée qui correspond aux modèles de lecture attendus : + Identifiez les colonnes fréquemment utilisées dans les requêtes. Ce sont des candidats idéaux pour le partitionnement. Par exemple, si vous recherchez généralement des données relatives à un jour donné, un exemple naturel de colonne de partition serait une colonne de date. + Choisissez une colonne de partition à faible cardinalité pour éviter de créer un nombre excessif de partitions. Un trop grand nombre de partitions peut augmenter le nombre de fichiers dans la table, ce qui peut avoir un impact négatif sur les performances des requêtes. En règle générale, « trop de partitions » peut être défini comme un scénario dans lequel la taille des données dans la majorité des partitions est inférieure à 2 à 5 fois la valeur définie par`target-file-size-bytes`. **Note** Si vous effectuez généralement une requête à l'aide de filtres sur une colonne à cardinalité élevée (par exemple, une `id` colonne pouvant contenir des milliers de valeurs), utilisez la fonction de partitionnement masquée d'Iceberg avec les transformations de compartiments, comme expliqué dans la section suivante. ### Utiliser le partitionnement masqué Si vos requêtes filtrent généralement sur un dérivé d'une colonne de table, utilisez des partitions masquées au lieu de créer explicitement de nouvelles colonnes qui fonctionneront comme des partitions. Pour plus d'informations sur cette fonctionnalité, consultez la [documentation d'Iceberg](https://iceberg.apache.org/docs/latest/partitioning/#icebergs-hidden-partitioning). Par exemple, dans un ensemble de données comportant une colonne d'horodatage (par exemple,`2023-01-01 09:00:00`), au lieu de créer une nouvelle colonne avec la date analysée (par exemple,`2023-01-01`), utilisez des transformations de partition pour extraire la partie date de l'horodatage et créer ces partitions à la volée. Les cas d'utilisation les plus courants du partitionnement masqué sont les suivants : + **Partitionnement à la date ou à l'heure**, lorsque les données comportent une colonne d'horodatage. Iceberg propose plusieurs transformations pour extraire la date ou l'heure d'un horodatage. + **Partitionnement sur une fonction de hachage d'une colonne, lorsque la colonne** de partitionnement a une cardinalité élevée et entraînerait un trop grand nombre de partitions. La transformation des compartiments d'Iceberg regroupe plusieurs valeurs de partition en un nombre réduit de partitions cachées (compartiments) en utilisant des fonctions de hachage sur la colonne de partitionnement. Voir les [transformations de partition](https://iceberg.apache.org/spec/#partition-transforms) dans la documentation d'Iceberg pour un aperçu de toutes les transformations de partition disponibles. Les colonnes utilisées pour le partitionnement masqué peuvent faire partie des prédicats de requête grâce à l'utilisation de fonctions SQL classiques telles que `year()` et. `month()` Les prédicats peuvent également être combinés avec des opérateurs tels que `BETWEEN` et`AND`. **Note** Iceberg ne peut pas effectuer d'élagage de partition pour les fonctions qui produisent un type de données différent, par exemple,. `substring(event_time, 1, 10) = '2022-01-01'` ### Utiliser Partition Evolution Utilisez l'[évolution des partitions d'Iceberg](https://iceberg.apache.org/docs/latest/evolution/#partition-evolution) lorsque la stratégie de partition existante n'est pas optimale. Par exemple, si vous choisissez des partitions horaires qui s'avèrent trop petites (quelques mégaoctets chacune), envisagez de passer à des partitions quotidiennes ou mensuelles. Vous pouvez utiliser cette approche lorsque la meilleure stratégie de partition pour une table n'est initialement pas claire et que vous souhaitez affiner votre stratégie de partitionnement au fur et à mesure que vous en apprendrez davantage. Une autre utilisation efficace de l'évolution des partitions est lorsque les volumes de données changent et que la stratégie de partitionnement actuelle devient moins efficace au fil du temps. Pour obtenir des instructions sur la façon de faire évoluer les partitions, consultez les [extensions SQL ALTER TABLE](https://iceberg.apache.org/docs/latest/spark-ddl/#alter-table-sql-extensions) dans la documentation d'Iceberg.  ## Réglage de la taille des fichiers L'optimisation des performances des requêtes implique de minimiser le nombre de petits fichiers dans vos tables. Pour de bonnes performances de requête, nous recommandons généralement de conserver les fichiers Parquet et ORC de plus de 100 Mo. La taille du fichier a également un impact sur la planification des requêtes pour les tables Iceberg. À mesure que le nombre de fichiers d'une table augmente, la taille des fichiers de métadonnées augmente également. Les fichiers de métadonnées volumineux peuvent ralentir la planification des requêtes. Par conséquent, lorsque la taille de la table augmente*,* augmentez la taille du fichier**** pour limiter l'expansion exponentielle des métadonnées. Suivez les bonnes pratiques suivantes pour créer des fichiers correctement dimensionnés dans les tables Iceberg. ### Définir la taille du fichier cible et du groupe de lignes Iceberg propose les principaux paramètres de configuration suivants pour ajuster la mise en page des fichiers de données. Nous vous recommandons d'utiliser ces paramètres pour définir la taille du fichier cible, le groupe de lignes ou la taille de frappe. | **Paramètre** | **Valeur par défaut** | **Commentaire** | | --- |--- |--- | | `write.target-file-size-bytes` | 512 Mo | Ce paramètre indique la taille de fichier maximale qu'Iceberg créera. Cependant, certains fichiers peuvent être écrits avec une taille inférieure à cette limite. | | `write.parquet.row-group-size-bytes` | 128 Mo | Parquet et ORC stockent les données par blocs afin que les moteurs puissent éviter de lire le fichier entier pour certaines opérations. | | `write.orc.stripe-size-bytes` | 64 MO | | `write.distribution-mode` | Aucun, pour les versions 1.1 et antérieures d'IcebergHash, à partir de la version 1.2 d'Iceberg | Iceberg demande à Spark de trier les données entre ses tâches avant de les écrire dans le stockage. | + En fonction de la taille de table prévue, suivez ces directives générales : + **Petites tables** (jusqu'à quelques gigaoctets) : réduisez la taille du fichier cible à 128 Mo. Réduisez également le groupe de lignes ou la taille de bande (par exemple, à 8 ou 16 Mo). + **Tables de taille moyenne à grande** (de quelques gigaoctets à des centaines de gigaoctets) : les valeurs par défaut constituent un bon point de départ pour ces tables. Si vos requêtes sont très sélectives, ajustez le groupe de lignes ou la taille de bande (par exemple, à 16 Mo). + **Tables très volumineuses** (centaines de gigaoctets ou téraoctets) : augmentez la taille du fichier cible à 1 024 Mo ou plus, et envisagez d'augmenter le groupe de lignes ou la taille de bande si vos requêtes contiennent généralement de grands ensembles de données. + Pour garantir que les applications Spark qui écrivent dans les tables Iceberg créent des fichiers de taille appropriée, définissez la `write.distribution-mode` propriété sur `hash` ou`range`. Pour une explication détaillée de la différence entre ces modes, consultez la section [Writing Distribution Modes](https://iceberg.apache.org/docs/latest/spark-writes/#writing-distribution-modes) dans la documentation d'Iceberg. Il s'agit de directives générales. Nous vous recommandons d'effectuer des tests afin d'identifier les valeurs les plus adaptées à vos tables et charges de travail spécifiques. ### Effectuez un compactage régulier Les configurations du tableau précédent définissent une taille de fichier maximale que les tâches d'écriture peuvent créer, mais ne garantissent pas que les fichiers auront cette taille. Pour garantir des tailles de fichier appropriées, effectuez régulièrement le compactage pour combiner de petits fichiers en fichiers plus volumineux. Pour obtenir des conseils détaillés sur le compactage en cours, voir le [compactage d'icebergs](best-practices-compaction.md) plus loin dans ce guide. ## Optimisation des statistiques des colonnes Iceberg utilise les statistiques des colonnes pour élaguer les fichiers, ce qui améliore les performances des requêtes en réduisant la quantité de données analysées par les requêtes. Pour bénéficier des statistiques sur les colonnes, assurez-vous qu'Iceberg collecte des statistiques pour toutes les colonnes fréquemment utilisées dans les filtres de requêtes. Par défaut, Iceberg collecte des statistiques uniquement pour les [100 premières colonnes de chaque table](https://github.com/apache/iceberg/blob/ae15c7e36973501b40443e75816d3eac39eddc90/core/src/main/java/org/apache/iceberg/TableProperties.java#L276), comme défini par la propriété `write.metadata.metrics.max-inferred-column-defaults` de la table. Si votre table comporte plus de 100 colonnes et que vos requêtes font fréquemment référence à des colonnes situées en dehors des 100 premières colonnes (par exemple, vous pouvez avoir des requêtes qui filtrent sur la colonne 132), assurez-vous qu'Iceberg collecte des statistiques sur ces colonnes. Deux options s'offrent à vous pour y parvenir : + Lorsque vous créez la table Iceberg, réorganisez les colonnes de manière à ce que les colonnes dont vous avez besoin pour les requêtes se situent dans la plage de colonnes définie par `write.metadata.metrics.max-inferred-column-defaults` (la valeur par défaut est 100). Remarque : Si vous n'avez pas besoin de statistiques sur 100 colonnes, vous pouvez ajuster la `write.metadata.metrics.max-inferred-column-defaults` configuration à la valeur souhaitée (par exemple, 20) et réorganiser les colonnes de manière à ce que les colonnes dont vous avez besoin pour lire et écrire des requêtes se situent dans les 20 premières colonnes du côté gauche du jeu de données. + Si vous n'utilisez que quelques colonnes dans les filtres de requête, vous pouvez désactiver la propriété globale pour la collecte des mesures et choisir de manière sélective les colonnes individuelles pour lesquelles collecter les statistiques, comme illustré dans cet exemple : ``` .tableProperty("write.metadata.metrics.default", "none") .tableProperty("write.metadata.metrics.column.my_col_a", "full") .tableProperty("write.metadata.metrics.column.my_col_b", "full") ``` Remarque : Les statistiques des colonnes sont plus efficaces lorsque les données sont triées sur ces colonnes. Pour plus d'informations, consultez la section [Définir l'ordre de tri](#read-sort-order) plus loin dans ce guide. ## Choisissez la bonne stratégie de mise à jour Utilisez une copy-on-write stratégie pour optimiser les performances de lecture, lorsque des opérations d'écriture plus lentes sont acceptables pour votre cas d'utilisation. Il s'agit de la stratégie par défaut utilisée par Iceberg. Copy-on-write se traduit par de meilleures performances de lecture, car les fichiers sont directement écrits dans le stockage de manière optimisée pour la lecture. Cependant, par rapport à merge-on-read, chaque opération d'écriture prend plus de temps et consomme plus de ressources de calcul. Cela représente un compromis classique entre latence de lecture et d'écriture. copy-on-writeC'est généralement la solution idéale pour les cas d'utilisation où la plupart des mises à jour sont colocalisées dans les mêmes partitions de table (par exemple, pour les chargements par lots quotidiens). Copy-on-write les configurations (`write.update.mode``write.delete.mode`, et`write.merge.mode`) peuvent être définies au niveau de la table ou indépendamment du côté de l'application. ## Utiliser la compression ZSTD Vous pouvez modifier le codec de compression utilisé par Iceberg à l'aide de la propriété table. `write..compression-codec` Nous vous recommandons d'utiliser le codec de compression ZSTD pour améliorer les performances globales des tables. Par défaut, les versions 1.3 et antérieures d'Iceberg utilisent la compression GZIP, ce qui réduit les read/write performances par rapport à ZSTD. Remarque : Certains moteurs peuvent utiliser des valeurs par défaut différentes. C'est le cas des [tables Iceberg créées avec Athena](https://docs.aws.amazon.com/athena/latest/ug/compression-support-iceberg.html) ou Amazon EMR version 7.x. ## Définissez l'ordre de tri Pour améliorer les performances de lecture des tables Iceberg, nous vous recommandons de trier votre table en fonction d'une ou de plusieurs colonnes fréquemment utilisées dans les filtres de requêtes. Le tri, combiné aux statistiques des colonnes d'Iceberg, peut rendre l'élagage des fichiers nettement plus efficace, ce qui se traduit par des opérations de lecture plus rapides. Le tri réduit également le nombre de demandes Amazon S3 pour les requêtes qui utilisent les colonnes de tri des filtres de requêtes. Vous pouvez définir un ordre de tri hiérarchique au niveau de la table en exécutant une instruction DDL (Data Definition Language) avec Spark. Pour connaître les options disponibles, consultez la [documentation d'Iceberg](https://iceberg.apache.org/docs/latest/spark-ddl/#alter-table--write-ordered-by). Après avoir défini l'ordre de tri, les rédacteurs appliqueront ce tri aux opérations d'écriture de données suivantes dans la table Iceberg. Par exemple, dans les tables partitionnées par date (`yyyy-mm-dd`) où la plupart des requêtes sont filtrées par`uuid`, vous pouvez utiliser l'option DDL `Write Distributed By Partition Locally Ordered` pour vous assurer que Spark écrit des fichiers dont les plages ne se chevauchent pas. Le schéma suivant montre comment l'efficacité des statistiques de colonnes s'améliore lorsque les tables sont triées. Dans l'exemple, la table triée ne doit ouvrir qu'un seul fichier et tire le meilleur parti de la partition et du fichier d'Iceberg. Dans le tableau non trié, tout `uuid` peut potentiellement exister dans n'importe quel fichier de données. La requête doit donc ouvrir tous les fichiers de données. ![\[Définition de l'ordre de tri dans les tables Iceberg\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/apache-iceberg-on-aws/images/setting-sort-order.png) La modification de l'ordre de tri n'affecte pas les fichiers de données existants. Vous pouvez utiliser le compactage Iceberg pour leur appliquer l'ordre de tri. L'utilisation de tables triées par Iceberg peut réduire les coûts liés à votre charge de travail, comme l'illustre le graphique suivant. ![\[Comparaison des coûts pour les tables Iceberg et Parquet\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/apache-iceberg-on-aws/images/cost-graph.png) Ces graphiques résument les résultats de l'exécution du benchmark TPC-H pour les tables Hive (Parquet) par rapport aux tables triées par Iceberg. Toutefois, les résultats peuvent être différents pour d'autres ensembles de données ou charges de travail. ![\[Résultats du test TPC-H pour les tables Parquet par rapport aux tables Iceberg\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/apache-iceberg-on-aws/images/s3-api-calls.png) # Optimisation des performances d'écriture Cette section décrit les propriétés des tables que vous pouvez ajuster pour optimiser les performances d'écriture sur les tables Iceberg, indépendamment du moteur. ## Définissez le mode de distribution des tables Iceberg propose plusieurs modes de distribution d'écriture qui définissent la manière dont les données d'écriture sont distribuées entre les tâches Spark. Pour un aperçu des modes disponibles, consultez la section [Writing Distribution Modes](https://iceberg.apache.org/docs/latest/spark-writes/#writing-distribution-modes) dans la documentation d'Iceberg. Pour les cas d'utilisation qui privilégient la vitesse d'écriture, en particulier pour les charges de travail de streaming, définissez sur`write.distribution-mode`. `none` Cela garantit qu'Iceberg ne demande pas de remaniement Spark supplémentaire et que les données sont écrites dès qu'elles sont disponibles dans les tâches Spark. Ce mode est particulièrement adapté aux applications Spark Structured Streaming. **Note** La définition du mode de distribution des écritures `none` a tendance à produire de nombreux petits fichiers, ce qui dégrade les performances de lecture. Nous recommandons un compactage régulier pour consolider ces petits fichiers en fichiers correctement dimensionnés afin d'améliorer les performances des requêtes. ## Choisissez la bonne stratégie de mise à jour Utilisez une merge-on-read**** stratégie pour optimiser les performances d'écriture, lorsque des opérations de lecture plus lentes sur les données les plus récentes sont acceptables pour votre cas d'utilisation. Lorsque vous l'utilisez merge-on-read, Iceberg écrit les mises à jour et les suppressions dans le stockage sous forme de petits fichiers distincts. Lorsque le tableau est lu, le lecteur doit fusionner ces modifications avec les fichiers de base pour obtenir la dernière vue des données. Cela entraîne une baisse des performances pour les opérations de lecture, mais accélère l'écriture des mises à jour et des suppressions. merge-on-readC'est généralement la solution idéale pour le streaming de charges de travail comportant des mises à jour ou de tâches comportant peu de mises à jour réparties sur de nombreuses partitions de table. Vous pouvez définir merge-on-read les configurations (`write.update.mode`,`write.delete.mode`, et`write.merge.mode`) au niveau de la table ou indépendamment du côté de l'application. L'utilisation merge-on-read nécessite un compactage régulier pour éviter que les performances de lecture ne se dégradent au fil du temps. Le compactage concilie les mises à jour et les suppressions avec les fichiers de données existants afin de créer un nouvel ensemble de fichiers de données, éliminant ainsi la perte de performances encourue du côté lecture. Par défaut, le compactage d'Iceberg ne fusionne pas les fichiers de suppression, sauf si vous remplacez la valeur par défaut de la `delete-file-threshold` propriété par une valeur inférieure (voir la documentation d'[Iceberg](https://iceberg.apache.org/docs/latest/spark-procedures/#rewrite_data_files)). Pour en savoir plus sur le compactage, consultez la section [Compactage des icebergs](best-practices-compaction.md) plus loin dans ce guide. ## Choisissez le bon format de fichier Iceberg prend en charge l'écriture de données aux formats Parquet, ORC et Avro. Le parquet est le format par défaut. Parquet et ORC sont des formats en colonnes qui offrent des performances de lecture supérieures mais sont généralement plus lents à écrire. Cela représente le compromis typique entre les performances de lecture et d'écriture. Si la vitesse d'écriture est importante pour votre cas d'utilisation, par exemple pour les charges de travail en streaming, envisagez d'écrire au format Avro en la `write-format` configurant `Avro` dans les options du rédacteur. Avro étant un format basé sur des lignes, il permet d'accélérer les temps d'écriture au prix de performances de lecture plus lentes. Pour améliorer les performances de lecture, effectuez un compactage régulier pour fusionner et transformer de petits fichiers Avro en fichiers Parquet plus volumineux. Le résultat du processus de compactage est régi par le réglage de la `write.format.default` table. Le format par défaut d'Iceberg est Parquet. Ainsi, si vous écrivez dans Avro puis exécutez le compactage, Iceberg transformera les fichiers Avro en fichiers Parquet. Voici un exemple : ``` spark.sql(f""" CREATE TABLE IF NOT EXISTS glue_catalog.{DB_NAME}.{TABLE_NAME} ( Col_1 float, <<<…other columns…>> ts timestamp) USING iceberg PARTITIONED BY (days(ts)) OPTIONS ( 'format-version'='2', write.format.default'=parquet) """) query = df \ .writeStream \ .format("iceberg") \ .option("write-format", "avro") \ .outputMode("append") \ .trigger(processingTime='60 seconds') \ .option("path", f"glue_catalog.{DB_NAME}.{TABLE_NAME}") \ .option("checkpointLocation", f"s3://{BUCKET_NAME}/checkpoints/iceberg/") .start() ``` # Optimisation du stockage La mise à jour ou la suppression de données dans une table Iceberg augmente le nombre de copies de vos données, comme illustré dans le schéma suivant. Il en va de même pour l'exécution du compactage : il augmente le nombre de copies de données dans Amazon S3. C'est parce qu'Iceberg considère les fichiers sous-jacents à toutes les tables comme immuables. ![\[Résultats de la mise à jour ou de la suppression de données dans une table Iceberg\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/apache-iceberg-on-aws/images/optimizing-storage.png) Suivez les meilleures pratiques décrites dans cette section pour gérer les coûts de stockage. ## Activer la hiérarchisation intelligente S3 Utilisez la classe de stockage [Amazon S3 Intelligent-Tiering](https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering-overview.html) pour déplacer automatiquement les données vers le niveau d'accès le plus rentable lorsque les modèles d'accès changent. Cette option n'entraîne aucune surcharge opérationnelle ni aucun impact sur les performances.   Remarque : n'utilisez pas les niveaux facultatifs (tels que Archive Access et Deep Archive Access) dans S3 Intelligent-Tiering with Iceberg tables. Pour archiver des données, consultez les instructions de la section suivante. Vous pouvez également utiliser les [règles du cycle de vie d'Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) pour définir vos propres règles de déplacement d'objets vers une autre classe de stockage Amazon S3, telle que S3 Standard-IA ou S3 One Zone-IA (voir [Transitions prises en charge et contraintes associées dans la documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html#lifecycle-general-considerations-transition-sc) Amazon S3). ## Archiver ou supprimer des instantanés historiques Pour chaque transaction validée (insertion, mise à jour, fusion dans, compactage) dans une table Iceberg, une nouvelle version ou un instantané de la table est créé. Au fil du temps, le nombre de versions et le nombre de fichiers de métadonnées s'accumulent dans Amazon S3. La conservation des instantanés d'une table est nécessaire pour des fonctionnalités telles que l'isolation des instantanés, la restauration des tables et les requêtes de voyage dans le temps. Toutefois, les coûts de stockage augmentent en fonction du nombre de versions que vous conservez. Le tableau suivant décrit les modèles de conception que vous pouvez mettre en œuvre pour gérer les coûts en fonction de vos exigences en matière de conservation des données. | **Motif de design** | **Solution** | **Cas d’utilisation** | | --- |--- |--- | | **Supprimer les anciens instantanés** | Utilisez l'[instruction VACUUM](https://docs.aws.amazon.com/athena/latest/ug/vacuum-statement.html) dans Athena pour supprimer les anciens instantanés. Cette opération n'entraîne aucun coût de calcul. [Vous pouvez également utiliser Spark sur Amazon EMR ou AWS Glue pour supprimer des instantanés. Pour plus d'informations, consultez expire\$1snapshots dans la documentation d'Iceberg.](https://iceberg.apache.org/docs/latest/spark-procedures/#expire_snapshots) | Cette approche supprime les instantanés qui ne sont plus nécessaires pour réduire les coûts de stockage. Vous pouvez configurer le nombre d'instantanés à conserver ou pendant combien de temps, en fonction de vos exigences en matière de conservation des données.Cette option effectue une suppression définitive des instantanés. Vous ne pouvez pas revenir en arrière ou voyager dans le temps pour retrouver des instantanés expirés. | | **Définissez des règles de conservation pour des instantanés spécifiques** | Utilisez des balises pour marquer des instantanés spécifiques et définir une politique de rétention dans Iceberg. Pour plus d'informations, consultez la section [Balises historiques](https://iceberg.apache.org/docs/latest/branching/#historical-tags) dans la documentation d'Iceberg. Par exemple, vous pouvez conserver un instantané par mois pendant un an en utilisant l'instruction SQL suivante dans Spark on Amazon EMR : 
ALTER TABLE glue_catalog.db.table 
CREATE TAG 'EOM-01' AS OF VERSION 30 RETAIN 365 DAYS
Utilisez Spark sur Amazon EMR ou AWS Glue pour supprimer les instantanés intermédiaires non balisés restants. | Ce modèle est utile pour vous conformer aux exigences commerciales ou légales qui vous obligent à montrer l'état d'un tableau à un moment donné dans le passé. En appliquant des règles de conservation à des instantanés balisés spécifiques, vous pouvez supprimer d'autres instantanés (non balisés) créés. Ainsi, vous pouvez répondre aux exigences de conservation des données sans conserver chaque instantané créé. | | **Archiver les anciens instantanés** | Utilisez les balises Amazon S3 pour marquer des objets avec Spark. (Les balises Amazon S3 sont différentes des balises Iceberg ; pour plus d'informations, consultez la [documentation d'Iceberg](https://iceberg.apache.org/docs/latest/aws/#s3-tags).) Par exemple : 
spark.sql.catalog.my_catalog.s3.delete-enabled=false and \
spark.sql.catalog.my_catalog.s3.delete.tags.my_key=to_archive
Utilisez Spark sur Amazon EMR ou AWS Glue pour [supprimer](https://iceberg.apache.org/docs/latest/spark-procedures/#expire_snapshots) des instantanés. Lorsque vous utilisez les paramètres de l'exemple, cette procédure balise les objets et les détache des métadonnées de la table Iceberg au lieu de les supprimer d'Amazon S3. Utilisez les règles du cycle de vie de S3 pour transférer les objets marqués comme `to_archive` vers l'une des [classes de stockage S3 Glacier](https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html). Pour interroger les données archivées : [Restaurez les objets archivés](https://docs.aws.amazon.com/AmazonS3/latest/userguide/restoring-objects.html) (cette étape n'est pas obligatoire si les objets ont été transférés vers la classe de stockage Amazon Glacier Instant Retrieval). Utilisez la [procédure register\$1table](https://iceberg.apache.org/docs/latest/spark-procedures/#register_table) dans Iceberg pour enregistrer l'instantané en tant que table dans le catalogue. Pour obtenir des instructions détaillées, consultez le billet de AWS blog [Améliorez l'efficacité opérationnelle des tables Apache Iceberg basées sur les lacs de données Amazon S3](https://aws.amazon.com/blogs/big-data/improve-operational-efficiencies-of-apache-iceberg-tables-built-on-amazon-s3-data-lakes/).  | Ce modèle vous permet de conserver toutes les versions des tables et les instantanés à moindre coût.Vous ne pouvez pas voyager dans le temps ou revenir à des instantanés archivés sans avoir d'abord restauré ces versions sous forme de nouvelles tables. Cela est généralement acceptable à des fins d'audit.Vous pouvez combiner cette approche avec le modèle de conception précédent, en définissant des politiques de conservation pour des instantanés spécifiques. | ## Supprimer les fichiers orphelins Dans certaines situations, les applications Iceberg peuvent échouer avant que vous n'ayez validé vos transactions. Cela laisse les fichiers de données dans Amazon S3. Comme il n'y a pas eu de validation, ces fichiers ne seront associés à aucune table. Vous devrez peut-être les nettoyer de manière asynchrone. Pour gérer ces suppressions, vous pouvez utiliser l'[instruction VACUUM](https://docs.aws.amazon.com/athena/latest/ug/vacuum-statement.html) dans Amazon Athena. Cette instruction supprime les instantanés et supprime également les fichiers orphelins. C'est très rentable, car Athena ne facture pas le coût de calcul de cette opération. De plus, il n'est pas nécessaire de planifier d'opérations supplémentaires lorsque vous utilisez l'`VACUUM`instruction. Vous pouvez également utiliser Spark sur Amazon EMR ou AWS Glue exécuter la `remove_orphan_files` procédure. Cette opération a un coût de calcul et doit être planifiée indépendamment. Pour plus d'informations, consultez la [documentation d'Iceberg](https://iceberg.apache.org/docs/latest/spark-procedures/#remove_orphan_files). # Maintien des tables en utilisant le compactage Iceberg inclut des fonctionnalités qui vous permettent d'effectuer des [opérations de maintenance de tables](https://iceberg.apache.org/docs/latest/maintenance/) après y avoir écrit des données. Certaines opérations de maintenance se concentrent sur la rationalisation des fichiers de métadonnées, tandis que d'autres améliorent la manière dont les données sont regroupées dans les fichiers afin que les moteurs de requêtes puissent localiser efficacement les informations nécessaires pour répondre aux demandes des utilisateurs. Cette section se concentre sur les optimisations liées au compactage. ## Compactage des icebergs Dans Iceberg, vous pouvez utiliser le compactage pour effectuer quatre tâches : + Combinaison de petits fichiers en fichiers plus volumineux dont la taille est généralement supérieure à 100 Mo. Cette technique est connue sous le nom de « *bin packing* ». + Fusion de fichiers de suppression avec des fichiers de données. Les fichiers de suppression sont générés par des mises à jour ou des suppressions utilisant cette merge-on-read approche. + (Re) tri des données conformément aux modèles de requête. Les données peuvent être écrites sans ordre de tri ou avec un ordre de tri adapté aux écritures et aux mises à jour. + Regrouper les données en utilisant des courbes de remplissage d'espace pour optimiser les modèles de requêtes distincts, en particulier le tri par ordre Z. Vous pouvez exécuter des opérations de compactage et de maintenance de tables pour Iceberg via Amazon Athena ou en utilisant Spark dans Amazon EMR ou. AWS AWS Glue Lorsque vous exécutez le compactage à l'aide de la procédure [rewrite\$1data\$1files](https://iceberg.apache.org/docs/latest/spark-procedures/#rewrite_data_files), vous pouvez régler plusieurs boutons pour contrôler le comportement de compactage. Le schéma suivant montre le comportement par défaut du bin packing. Comprendre le compactage des emballages en bacs est essentiel pour comprendre les implémentations du tri hiérarchique et du tri par ordre Z, car il s'agit d'extensions de l'interface d'emballage en bacs et fonctionnent de manière similaire. La principale différence réside dans l'étape supplémentaire requise pour trier ou regrouper les données. ![\[Comportement du casier par défaut dans les tables Iceberg\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/apache-iceberg-on-aws/images/compaction.png) Dans cet exemple, la table Iceberg est composée de quatre partitions. Chaque partition a une taille et un nombre de fichiers différents. Si vous démarrez une application Spark pour exécuter le compactage, l'application crée au total quatre groupes de fichiers à traiter. Un groupe de fichiers est une abstraction d'Iceberg qui représente un ensemble de fichiers qui seront traités par une seule tâche Spark. C'est-à-dire que l'application Spark qui exécute le compactage créera quatre tâches Spark pour traiter les données. ## Réglage du comportement de compactage Les propriétés clés suivantes contrôlent la manière dont les fichiers de données sont sélectionnés pour le compactage : + [MAX\$1FILE\$1GROUP\$1SIZE\$1BYTES](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/RewriteDataFiles.html#MAX_FILE_GROUP_SIZE_BYTES) définit la limite de données pour un seul groupe de fichiers (tâche Spark) à 100 Go par défaut. Cette propriété est particulièrement importante pour les tables sans partitions ou les tables dont les partitions s'étendent sur des centaines de gigaoctets. En définissant cette limite, vous pouvez décomposer les opérations afin de planifier le travail et de progresser tout en évitant l'épuisement des ressources du cluster. Remarque : Chaque groupe de fichiers est trié séparément. Par conséquent, si vous souhaitez effectuer un tri au niveau de la partition, vous devez ajuster cette limite en fonction de la taille de la partition. + [MIN\$1FILE\$1SIZE\$1BYTES ou MIN\$1FILE\$1SIZE\$1DEFAULT\$1RATIO](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MIN_FILE_SIZE_BYTES) [utilise par défaut 75 % de la taille de fichier cible définie au niveau de la table](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MIN_FILE_SIZE_DEFAULT_RATIO). Par exemple, si la taille cible d'une table est de 512 Mo, tout fichier inférieur à 384 Mo est inclus dans l'ensemble de fichiers à compacter. + [MAX\$1FILE\$1SIZE\$1BYTES ou MAX\$1FILE\$1SIZE\$1DEFAULT\$1RATIO](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MAX_FILE_SIZE_BYTES) [utilise par défaut 180 % de la taille du fichier](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MAX_FILE_SIZE_DEFAULT_RATIO) cible. Comme les deux propriétés qui définissent les tailles de fichier minimales, ces propriétés sont utilisées pour identifier les fichiers candidats pour le travail de compactage. + [MIN\$1INPUT\$1FILES](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MIN_INPUT_FILES) indique le nombre minimum de fichiers à compacter si la taille d'une partition de table est inférieure à la taille du fichier cible. La valeur de cette propriété est utilisée pour déterminer s'il est intéressant de compacter les fichiers en fonction du nombre de fichiers (5 par défaut). + [DELETE\$1FILE\$1THRESHOLD](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#DELETE_FILE_THRESHOLD) indique le nombre minimum d'opérations de suppression pour un fichier avant qu'il ne soit inclus dans le compactage. Sauf indication contraire, le compactage ne combine pas les fichiers de suppression avec les fichiers de données. Pour activer cette fonctionnalité, vous devez définir une valeur de seuil à l'aide de cette propriété. Ce seuil est spécifique à chaque fichier de données. Par conséquent, si vous le définissez sur 3, un fichier de données ne sera réécrit que s'il existe au moins trois fichiers de suppression qui y font référence. Ces propriétés fournissent un aperçu de la formation des groupes de fichiers dans le schéma précédent. Par exemple, la partition étiquetée `month=01` inclut deux groupes de fichiers car elle dépasse la limite de taille maximale de 100 Go. En revanche, la `month=02` partition contient un seul groupe de fichiers car sa taille est inférieure à 100 Go. La `month=03` partition ne répond pas à l'exigence minimale de cinq fichiers d'entrée par défaut. Par conséquent, il ne sera pas compacté. Enfin, bien que la `month=04` partition ne contienne pas suffisamment de données pour former un seul fichier de la taille souhaitée, les fichiers seront compactés car la partition contient plus de cinq petits fichiers. Vous pouvez définir ces paramètres pour que Spark s'exécute sur Amazon EMR ou. AWS Glue Pour Amazon Athena, vous pouvez gérer des propriétés similaires en utilisant les propriétés du [tableau](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg-creating-tables.html#querying-iceberg-table-properties) (qui commencent par le préfixe`optimize_`). ## Exécution du compactage avec Spark sur Amazon EMR ou AWS Glue Cette section explique comment dimensionner correctement un cluster Spark pour exécuter l'utilitaire de compactage d'Iceberg. L'exemple suivant utilise Amazon EMR Serverless, mais vous pouvez utiliser la même méthodologie dans Amazon EMR sur EC2 ou EKS, ou dans. AWS Glue Vous pouvez tirer parti de la corrélation entre les groupes de fichiers et les tâches Spark pour planifier les ressources du cluster. Pour traiter les groupes de fichiers de manière séquentielle, compte tenu de la taille maximale de 100 Go par groupe de fichiers, vous pouvez définir les [propriétés Spark](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/jobs-spark.html#spark-defaults) suivantes : + `spark.dynamicAllocation.enabled` = `FALSE` + `spark.executor.memory` = `20 GB` + `spark.executor.instances` = `5` Pour accélérer le compactage, vous pouvez effectuer une mise à l'échelle horizontale en augmentant le nombre de groupes de fichiers compactés en parallèle. Vous pouvez également redimensionner Amazon EMR en utilisant un dimensionnement manuel ou dynamique. + **Mise à l'échelle manuelle** (par exemple, par un facteur 4) + `MAX_CONCURRENT_FILE_GROUP_REWRITES`= `4` (notre facteur) + `spark.executor.instances`= `5` (valeur utilisée dans l'exemple) x `4` (notre facteur) = `20` + `spark.dynamicAllocation.enabled` = `FALSE` + **Mise à l'échelle dynamique** + `spark.dynamicAllocation.enabled`= `TRUE ` (par défaut, aucune action requise) + [MAX\$1CONCURRENT\$1FILE\$1GROUP\$1REWRITES](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/RewriteDataFiles.html#MAX_CONCURRENT_FILE_GROUP_REWRITES) = `N ` (aligne cette valeur sur 100 par défaut ; en fonction des `spark.dynamicAllocation.maxExecutors` configurations de l'exécuteur indiquées dans l'exemple, vous pouvez définir la valeur sur 20) `N` Il s'agit de directives destinées à aider à dimensionner le cluster. Cependant, vous devez également surveiller les performances de vos tâches Spark afin de trouver les meilleurs paramètres pour vos charges de travail. ## Exécution du compactage avec Amazon Athena [Athena propose une implémentation de l'utilitaire de compactage d'Iceberg en tant que fonctionnalité gérée via l'instruction OPTIMIZE.](https://docs.aws.amazon.com/athena/latest/ug/optimize-statement.html) Vous pouvez utiliser cette instruction pour exécuter le compactage sans avoir à évaluer l'infrastructure. Cette instruction regroupe les petits fichiers en fichiers plus volumineux en utilisant l'algorithme de bin packing et fusionne les fichiers de suppression avec les fichiers de données existants. Pour regrouper les données en utilisant le tri hiérarchique ou le tri par ordre Z, utilisez Spark sur Amazon AWS Glue EMR ou. Vous pouvez modifier le comportement par défaut de l'`OPTIMIZE`instruction lors de la création de la table en transmettant les propriétés de la table dans l'`CREATE TABLE`instruction, ou après la création de la table en utilisant l'`ALTER TABLE`instruction. Pour les valeurs par défaut, consultez la documentation d'[Athena](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg-creating-tables.html#querying-iceberg-table-properties). ## Recommandations pour le compactage en cours | **Cas d'utilisation** | **Recommandation** | | --- |--- | | **Exécution du compactage des emballages en bacs selon un calendrier** | Utilisez l'`OPTIMIZE`instruction d'Athena si vous ne savez pas combien de petits fichiers contient votre table. Le modèle de tarification d'Athena est basé sur les données numérisées. Ainsi, s'il n'y a aucun fichier à compacter, aucun coût n'est associé à ces opérations. Pour éviter de rencontrer des délais d'attente sur les tables Athena, `OPTIMIZE` exécutez le jeu sur per-table-partition une base. Utilisez Amazon EMR ou AWS Glue le dimensionnement dynamique lorsque vous vous attendez à ce que de gros volumes de petits fichiers soient compactés. | | **Exécution du compactage des bacs en fonction des événements** | Utilisez Amazon EMR ou AWS Glue le dimensionnement dynamique lorsque vous vous attendez à ce que de gros volumes de petits fichiers soient compactés. | | **Exécuter le compactage pour trier les données** | Utilisez Amazon EMR ou AWS Glue, parce que le tri est une opération coûteuse qui peut nécessiter le transfert de données sur le disque. | | **Exécution du compactage pour regrouper les données à l'aide du tri par ordre Z** | Utilisez Amazon EMR ou AWS Glue, car le tri par ordre Z est une opération très coûteuse qui peut nécessiter le transfert de données sur disque. | | **Exécution du compactage sur des partitions susceptibles d'être mises à jour par d'autres applications en raison de l'arrivée tardive de données** | Utilisez Amazon EMR ou. AWS Glue Activez la propriété Iceberg [PARTIAL\$1PROGRESS\$1ENABLED](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/RewriteDataFiles.html#PARTIAL_PROGRESS_ENABLED). Lorsque vous utilisez cette option, Iceberg divise la sortie de compactage en plusieurs validations. En cas de collision (c'est-à-dire si le fichier de données est mis à jour alors que le compactage est en cours d'exécution), ce paramètre réduit le coût d'une nouvelle tentative en le limitant à la validation qui inclut le fichier concerné. Dans le cas contraire, vous devrez peut-être recompacter tous les fichiers. | | **Exécution du compactage sur des partitions froides (partitions de données qui ne reçoivent plus d'écritures actives)** | Utilisez Amazon EMR ou. AWS Glue Dans la `rewrite_data_files` procédure, spécifiez un `where` prédicat qui exclut les partitions écrites activement. Cette stratégie évite les conflits de données entre les rédacteurs et les tâches de compactage, et ne laisse que les conflits de métadonnées qu'Iceberg peut résoudre automatiquement. | # Utilisation des charges de travail Iceberg dans Amazon S3 Cette section décrit les propriétés d'Iceberg que vous pouvez utiliser pour optimiser l'interaction d'Iceberg avec Amazon S3. ## Empêcher le partitionnement à chaud (erreurs HTTP 503) Certaines applications de lac de données exécutées sur Amazon S3 gèrent des millions ou des milliards d'objets et traitent des pétaoctets de données. Cela peut entraîner des préfixes recevant un volume de trafic élevé, généralement détectés par le biais d'erreurs HTTP 503 (service non disponible). Pour éviter ce problème, utilisez les propriétés Iceberg suivantes : + Réglé `write.distribution-mode` de `range` manière à `hash` ce qu'Iceberg écrive des fichiers volumineux, ce qui réduit le nombre de demandes Amazon S3. Il s'agit de la configuration préférée qui devrait convenir à la majorité des cas. + Si vous continuez à rencontrer 503 erreurs en raison d'un énorme volume de données dans vos charges de travail, vous pouvez configurer `write.object-storage.enabled` cette option `true` dans Iceberg. Cela indique à Iceberg de hacher les noms des objets et de répartir la charge sur plusieurs préfixes Amazon S3 aléatoires. Pour plus d'informations sur ces propriétés, consultez la section [Write properties](https://iceberg.apache.org/docs/latest/configuration/#write-properties) dans la documentation d'Iceberg. ## Utiliser les opérations de maintenance d'Iceberg pour libérer les données inutilisées Pour gérer les tables Iceberg, vous pouvez utiliser l'API principale d'Iceberg, les clients Iceberg (tels que Spark) ou les services gérés tels qu'Amazon Athena. Pour supprimer des fichiers anciens ou inutilisés d'Amazon S3, nous vous recommandons de n'utiliser Iceberg native que APIs pour [supprimer les instantanés, supprimer](https://iceberg.apache.org/docs/latest/maintenance/#expire-snapshots) [les anciens fichiers de métadonnées et supprimer les fichiers](https://iceberg.apache.org/docs/latest/maintenance/#remove-old-metadata-files) [orphelins](https://iceberg.apache.org/docs/latest/maintenance/#delete-orphan-files). L'utilisation d'Amazon S3 APIs via Boto3, le SDK Amazon S3 ou le AWS Command Line Interface (AWS CLI), ou l'utilisation de toute autre méthode autre que celle d'Iceberg pour remplacer ou supprimer des fichiers Amazon S3 pour une table Iceberg entraîne la corruption de la table et l'échec des requêtes. ## Répliquez les données sur Régions AWS Lorsque vous stockez des tables Iceberg dans Amazon S3, vous pouvez utiliser les fonctionnalités intégrées d'Amazon S3, telles que la [réplication entre régions (CRR) et les points d'accès multirégionaux (MRAP)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)[, pour répliquer des données entre plusieurs régions](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html). Régions AWS Le MRAP fournit un point de terminaison global permettant aux applications d'accéder aux compartiments S3 situés dans plusieurs compartiments. Régions AWS Iceberg ne prend pas en charge les chemins relatifs, mais vous pouvez utiliser le MRAP pour effectuer des opérations Amazon S3 en mappant des buckets aux points d'accès. Le MRAP s'intègre également parfaitement au processus de réplication entre régions d'Amazon S3, qui entraîne un décalage pouvant atteindre 15 minutes. Vous devez répliquer les fichiers de données et de métadonnées. **Important** Actuellement, l'intégration d'Iceberg au MRAP ne fonctionne qu'avec Apache Spark. Si vous devez passer au secondaire Région AWS, vous devez prévoir de rediriger les requêtes des utilisateurs vers un environnement Spark SQL (tel qu'Amazon EMR) dans la région de basculement. Les fonctionnalités CRR et MRAP vous aident à créer une solution de réplication entre régions pour les tables Iceberg, comme illustré dans le schéma suivant. ![\[Réplication entre régions pour les tables Iceberg\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/apache-iceberg-on-aws/images/cross-region-replication.png) Pour configurer cette architecture de réplication entre régions : 1. Créez des tables en utilisant l'emplacement MRAP. Cela garantit que les fichiers de métadonnées Iceberg pointent vers l'emplacement MRAP plutôt que vers l'emplacement physique du bucket. 1. Répliquez les fichiers Iceberg à l'aide d'Amazon S3 MRAP. ****Le MRAP prend en charge la réplication des données avec un accord de niveau de service (SLA) de 15 minutes. Iceberg empêche les opérations de lecture d'introduire des incohérences lors de la réplication. 1. Rendez les tables disponibles AWS Glue Data Catalog dans la région secondaire. Vous avez le choix entre deux options : + Configurez un pipeline pour répliquer les métadonnées des tables Iceberg à l'aide AWS Glue Data Catalog de la réplication. Cet utilitaire est disponible dans le référentiel de [réplication GitHub Glue Catalog et Lake Formation Permissions](https://github.com/aws-samples/lake-formation-pemissions-sync). Ce mécanisme piloté par les événements réplique les tables de la région cible en fonction des journaux d'événements. + Enregistrez les tables dans la région secondaire lorsque vous devez basculer. Pour cette option, vous pouvez utiliser l'utilitaire précédent ou la [procédure register\$1table](https://iceberg.apache.org/docs/latest/spark-procedures/#register_table) d'Iceberg et le faire pointer vers le dernier fichier. `metadata.json`