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.
Comment fonctionne la réplication des tables S3
La réplication des tables S3 crée des répliques en lecture seule de vos tables Apache Iceberg dans les régions et. Comptes AWS Les tables de répliques sont gérées automatiquement par le service S3 Tables et contiennent les données complètes, les métadonnées et l'historique des instantanés de votre table source, ce qui les rend consultables à l'aide de n'importe quel Iceberg-compatible moteur d'analyse et d'opérations de voyage dans le temps.
Lorsque vous configurez la réplication pour une table, S3 Tables :
-
Crée une table de réplication en lecture seule dans chaque compartiment de tables de destination avec le même nom et le même espace de noms que la table source.
-
Remplit la réplique avec le dernier état de la table source
-
Surveille les nouvelles mises à jour de la table source
-
Valide toutes les mises à jour des répliques dans le même ordre que la source pour maintenir la cohérence
Pour plus d’informations, consultez les sections suivantes.
Rubriques
Qu'est-ce qui est répliqué
Les composants du tableau suivants sont répliqués :
-
Instantanés de table : tous les instantanés, y compris les instantanés compactés, sont répliqués dans l'ordre chronologique, en conservant les relations parent-enfant et les numéros de séquence de la table source. Cela garantit que les tables de répliques offrent les mêmes fonctionnalités de voyage dans le temps que les tables sources.
-
Données de table : tous les fichiers de données référencés par les instantanés de table sont répliqués dans la région de destination. Cela inclut notamment les éléments suivants :
-
Fichiers de métadonnées : fichiers .json de métadonnées de table, manifestes, listes de manifestes, statistiques de partition et statistiques de table.
-
Supprimer des fichiers : tous les fichiers supprimés sont répliqués afin de préserver l'exactitude des données dans les tables de répliques.
-
Fichiers de données : tous les fichiers de données référencés par les manifestes sont répliqués.
-
-
Métadonnées de la table : réplication complète des métadonnées, y compris les informations sur le schéma (actuel et historique), les spécifications des partitions, les ordres de tri et les propriétés des tables.
-
Informations sur le schéma : tous les schémas de tables sont répliqués, y compris le schéma actuel et les versions historiques du schéma. Cela garantit que les requêtes relatives à des tables de répliques utilisent les définitions de colonnes, les types de données et les mappages de champs appropriés. Le processus de réplication conserve l'historique de l'évolution du schéma, ce qui permet aux requêtes de voyage dans le temps de fonctionner correctement sur les tables de répliques.
-
Spécifications de partition : les spécifications de partition actuelles et historiques sont répliquées, ce qui garantit que les tables de réplication conservent la même stratégie de partitionnement que les tables sources.
-
Ordres de tri : les ordres de tri des tables sont répliqués pour optimiser les performances des requêtes.
-
Comment les données sont répliquées
La réplication détermine un état valide pour les tables de répliques en comparant les métadonnées des tables Apache Iceberg entre les tables source et les tables de réplication. La réplication traite les métadonnées dans trois catégories afin de mettre à jour votre table de répliques.
Pour les métadonnées des tableaux
Pour les champs de métadonnées versionnés, la réplication fusionne les valeurs de la table source dans les tableaux de la table de réplication pour les champs suivants :
-
snapshots— Fusionne tous les instantanés de la table source dans le tableau d'instantanés de la table de réplication par identifiant de cliché. -
snapshot-log— Fusionne les journaux d'instantanés de la table source dans le tableau de journaux d'instantanés de la table de réplication, triés par horodatage et identifiant de cliché. -
sort-orders— Fusionne les définitions d'ordre de tri de la table source dans le tableau des ordres de tri de la table de réplication par identifiant de commande. -
partition-specs— Fusionne les spécifications de partition de la table source dans le tableau de spécifications de partition de la table de réplication par identifiant de spécification. -
schemas— Fusionne les définitions de schéma de la table source dans le tableau de schémas de la table de réplication par identifiant de schéma.
Pour la configuration des tables
Pour les champs qui représentent la configuration de la table, la réplication copie les valeurs directement depuis la table source :
-
properties -
partition-statistics -
statistics
L'état actuel de la table est également transféré depuis la table source :
-
current-snapshot-id -
current-schema-id -
last-column-id -
last-partition-id -
last-sequence-number -
default-sort-order-id -
next-row-id(Iceberg V3) -
encryption-keys(Iceberg V3)
Replica-specific état
Les champs suivants sont calculés à partir de données fusionnées et mis à jour pour la table de répliques :
-
locationest mis à jour pendant la réplication pour indiquer l'emplacement de fichier correct dans le compartiment de la table de répliques, garantissant ainsi la validité de toutes les références de fichiers dans l'environnement de destination. -
metadata-logcontient tous les noms de fichiers de métadonnées de destination et est mis à jour après chaque réplication réussie avec le nom de fichier de métadonnées actuel. -
Tous les chemins de fichiers sont modifiés pour pointer vers les emplacements des tables de répliques.
Réplication de snapshots
La réplication des tables S3 conserve un historique complet des instantanés dans toutes les régions en répliquant tous les instantanés des tables dans le même ordre de validation que la table source. Les relations parent-enfant de la table source sont préservées dans la table de réplication.
Conservation des instantanés
Vous pouvez configurer une période de conservation des instantanés personnalisée pour vos tables répliquées qui diffère de la période de conservation de la source. Cela signifie que même si les instantanés ont expiré et ne sont plus disponibles dans la table source, ils peuvent être conservés dans des répliques.
Par exemple, si votre table source dispose d'une période de conservation des instantanés de 30 jours mais que votre table de réplication est configurée avec une période de conservation de 90 jours, la réplique conservera les instantanés des deux mois précédents qui ne sont plus disponibles dans la table source.
Les instantanés que vous avez expirés manuellement dans la table source sont également conservés dans la table de réplication. Par exemple, si vous avez expiré des instantanés datant de février dans la table source à l'aide d'une procédure Spark, vous pouvez toujours voyager dans le temps jusqu'aux instantanés de la table de réplication.
Considérations et restrictions
Les considérations suivantes s'appliquent aux tables répliquées :
-
S3 Tables reproduit à la fois les tables Iceberg V2 et V3. Cependant, la réplication des tables mises à niveau (V2 → V3) n'est pas prise en charge.
-
Les fichiers de métadonnées supérieurs à 500 Mo ne sont pas pris en charge.
-
Alors que les mises à jour de tables sont généralement répliquées en quelques minutes, la réplication peut prendre plus de temps en fonction de la taille de la mise à jour de table à répliquer, par exemple lorsque la réplication commence à être remplie.
-
Les tableaux comportant des balises ou des branches ne sont pas pris en charge.
-
La réplication n'est pas prise en charge pour les tables de métadonnées Amazon S3 ou d'autres tables système AWS générées.
-
Tous les instantanés de table, y compris les instantanés compactés, sont répliqués à partir de la table source. Par conséquent, le compactage n'est pas pris en charge sur les tables de répliques.
