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éplication 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 interrogeables à l'aide de n'importe quel moteur compatible avec Iceberg pour les analyses et les opérations de voyage dans le temps.
Lorsque vous configurez la réplication pour une table, les tables S3 :
-
Crée une table de réplique en lecture seule dans chaque compartiment de table 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 la table des sources pour détecter les nouvelles mises à jour
-
Valide toutes les mises à jour dans les répliques dans le même ordre que la source pour garantir la cohérence
Pour plus d’informations, consultez les sections suivantes.
Rubriques
Qu'est-ce qui est répliqué
Les composants de table suivants sont répliqués :
-
Instantanés de table : tous les instantanés, y compris les instantanés compactés, sont répliqués par ordre chronologique, en conservant les relations parent-enfant et les numéros de séquence de la table source. Cela garantit que les tables répliquées 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 des 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 de métadonnées de table .json, manifestes, listes de manifestes, statistiques de partition et statistiques de table.
-
Supprimer des fichiers : tous les fichiers de suppression sont répliqués afin de garantir l'exactitude des données dans les tables de réplication.
-
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 table : réplication complète des métadonnées, y compris les informations de schéma (actuelles et historiques), les spécifications de partition, les ordres de tri et les propriétés des tables.
-
Informations sur le schéma : tous les schémas de table sont répliqués, y compris le schéma actuel et les versions historiques du schéma. Cela garantit que les requêtes portant sur des tables de réplication 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éplication.
-
Spécifications de partition — Les spécifications de partition actuelles et historiques sont répliquées, ce qui garantit que les tables répliquées 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 répliquées en comparant les métadonnées des tables Apache Iceberg entre les tables source et les tables répliquées. 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 tables
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 capture. -
snapshot-log— Fusionne les journaux des instantanés de la table source dans le tableau des journaux des instantanés de la table de réplication, triés par horodatage et par identifiant d'instantané. -
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 des spécifications de partition de la table de réplication par identifiant de spécification.
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)
État spécifique à la réplique
Les champs suivants sont calculés à partir des données fusionnées et mis à jour pour la table de réplication :
-
locationest mis à jour pendant la réplication pour pointer vers l'emplacement correct du fichier dans le bucket de la table de réplication, garantissant ainsi que toutes les références de fichiers sont valides 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éplication.
Réplication de clichés
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 de table dans le même ordre de validation que la table source. Les relations parent-enfant de la table source sont conservé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, différente 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é les instantanés du mois de février sur 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 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 de plus de 500 Mo ne sont pas pris en charge.
-
Bien que les mises à jour des tables soient 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 remblayée.
-
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 pour les 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éplication.
