View a markdown version of this page

So funktioniert die Replikation von S3-Tabellen - Amazon Simple Storage Service
Was wird repliziertWie werden Daten repliziertSnapshot-ReplikationÜberlegungen und Einschränkungen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

So funktioniert die Replikation von S3-Tabellen

Bei der S3-Tabellenreplikation werden schreibgeschützte Replikate Ihrer Apache Iceberg-Tabellen in den Regionen und erstellt. AWS-Konten Replikattabellen werden automatisch vom S3 Tables-Dienst verwaltet und enthalten die vollständigen Daten, Metadaten und den Snapshot-Verlauf aus Ihrer Quelltabelle, sodass sie mit jeder Iceberg-compatible Engine für Analysen und Zeitreise-Operationen abgefragt werden können.

Wenn Sie die Replikation für eine Tabelle konfigurieren, gilt Folgendes für S3-Tabellen:

  • Erstellt in jedem Zieltabellen-Bucket eine schreibgeschützte Replikattabelle mit demselben Namen und Namespace wie die Quelltabelle.

  • Füllt das Replikat mit dem neuesten Status der Quelltabelle auf

  • Überwacht die Quelltabelle auf neue Aktualisierungen

  • Zur Wahrung der Konsistenz werden alle Aktualisierungen in derselben Reihenfolge wie die Quelle an die Replikate übertragen

Weitere Informationen finden Sie in den folgenden Abschnitten.

Was wird repliziert

Die folgenden Tabellenkomponenten werden repliziert:

  • Tabellen-Snapshots — Alle Snapshots, einschließlich komprimierter Snapshots, werden in chronologischer Reihenfolge repliziert, wobei Eltern-Kind-Beziehungen und Sequenznummern aus der Quelltabelle beibehalten werden. Dadurch wird sichergestellt, dass Replikattabellen dieselben Funktionen für Zeitreisen bieten wie Quelltabellen.

  • Tabellendaten — Alle Datendateien, auf die durch Tabellen-Snapshots verwiesen wird, werden in die Zielregion repliziert. Dies umfasst:

    • Metadatendateien — Metadata.json-Dateien der Tabelle, Manifeste, Manifestlisten, Partitionsstatistiken und Tabellenstatistiken.

    • Dateien löschen — Alle gelöschten Dateien werden repliziert, um die Datengenauigkeit in den Replikattabellen aufrechtzuerhalten.

    • Datendateien — Alle Datendateien, auf die in Manifesten verwiesen wird, werden repliziert.

  • Tabellenmetadaten — Vollständige Metadatenreplikation, einschließlich Schemainformationen (aktuell und historisch), Partitionsspezifikationen, Sortierreihenfolgen und Tabelleneigenschaften.

    • Schemainformationen — Alle Tabellenschemas werden repliziert, einschließlich des aktuellen Schemas und historischer Schemaversionen. Dadurch wird sichergestellt, dass Abfragen für Replikattabellen die richtigen Spaltendefinitionen, Datentypen und Feldzuordnungen verwenden. Beim Replikationsprozess wird der Verlauf der Schemaentwicklung beibehalten, sodass Time-Travel-Abfragen in Replikattabellen ordnungsgemäß funktionieren.

    • Partitionsspezifikationen — Aktuelle und historische Partitionsspezifikationen werden repliziert, sodass für Replikattabellen dieselbe Partitionierungsstrategie wie für Quelltabellen gilt.

    • Sortierreihenfolgen — Die Sortierreihenfolgen der Tabellen werden repliziert, um die Abfrageleistung zu optimieren.

Wie werden Daten repliziert

Die Replikation bestimmt einen gültigen Status für Replikattabellen, indem die Metadaten der Apache Iceberg-Tabelle zwischen der Quell- und der Replikattabelle verglichen werden. Die Replikation verarbeitet Metadaten in drei Kategorien, um Ihre Replikattabelle zu aktualisieren.

Für Tabellenmetadaten

Bei versionierten Metadatenfeldern führt die Replikation Werte aus der Quelltabelle mit den Arrays der Replikattabelle für die folgenden Felder zusammen:

  • snapshots— Führt alle Snapshots aus der Quelltabelle anhand der Snapshot-ID in das Snapshot-Array der Replikattabelle ein.

  • snapshot-log— Führt Snapshot-Logs aus der Quelltabelle mit dem Snapshot-Log-Array der Replikattabelle zusammen, sortiert nach Zeitstempel und Snapshot-ID.

  • sort-orders— Führt Sortierreihenfolge-Definitionen aus der Quelltabelle mit dem Sortierreihenfolge-Array der Replikattabelle nach Ordnungs-ID zusammen.

  • partition-specs— Führt die Partitionsspezifikationen aus der Quelltabelle anhand der Spezifikations-ID in das Partitionsspezifikations-Array der Replikattabelle ein.

  • schemas— Führt Schemadefinitionen aus der Quelltabelle anhand der Schema-ID in das Schema-Array der Replikattabelle ein.

Für die Tabellenkonfiguration

Für Felder, die eine Tabellenkonfiguration darstellen, kopiert die Replikation Werte direkt aus der Quelltabelle:

  • properties

  • partition-statistics

  • statistics

Der aktuelle Tabellenstatus wird ebenfalls aus der Quelltabelle übertragen:

  • current-snapshot-id

  • current-schema-id

  • last-column-id

  • last-partition-id

  • last-sequence-number

  • default-sort-order-id

  • next-row-id(Eisberg V3)

  • encryption-keys(Eisberg V3)

Replica-specific Staat

Die folgenden Felder werden aus zusammengeführten Daten berechnet und für die Replikattabelle aktualisiert:

  • locationwird während der Replikation aktualisiert, sodass sie auf den richtigen Dateispeicherort im Replikattabellen-Bucket verweist. Dadurch wird sichergestellt, dass alle Dateiverweise in der Zielumgebung gültig sind.

  • metadata-logenthält alle Ziel-Metadatendateinamen und wird nach jeder erfolgreichen Replikation mit dem aktuellen Metadaten-Dateinamen aktualisiert.

  • Alle Dateipfade werden so geändert, dass sie auf die Speicherorte der Replikattabelle verweisen.

Snapshot-Replikation

Bei der S3-Tabellenreplikation wird der vollständige Snapshot-Verlauf über Regionen hinweg beibehalten, indem alle Tabellen-Snapshots in derselben Commit-Reihenfolge wie die Quelltabelle repliziert werden. Die Eltern-Kind-Beziehungen aus der Quelltabelle werden in der Replikattabelle beibehalten.

Snapshot-Aufbewahrung

Sie können einen benutzerdefinierten Snapshot-Aufbewahrungszeitraum für Ihre replizierten Tabellen konfigurieren, der sich vom Aufbewahrungszeitraum der Quelle unterscheidet. Das heißt, selbst wenn Snapshots abgelaufen sind und nicht mehr in der Quelltabelle verfügbar sind, können sie in Replikaten aufbewahrt werden.

Wenn Ihre Quelltabelle beispielsweise eine 30-tägige Snapshot-Aufbewahrungsfrist hat, Ihre Replikattabelle jedoch mit einer 90-tägigen Aufbewahrungsfrist konfiguriert ist, verwaltet das Replikat Snapshots der letzten zwei Monate, die in der Quelltabelle nicht mehr verfügbar sind.

Snapshots, die Sie in der Quelltabelle manuell abgelaufen haben, werden ebenfalls in der Replikattabelle beibehalten. Wenn Sie beispielsweise mithilfe einer Spark-Prozedur Snapshots vom Februar in der Quelltabelle abgelaufen haben, können Sie immer noch Zeitreisen zu den Snapshots in der Replikattabelle durchführen.

Überlegungen und Einschränkungen

Die folgenden Überlegungen gelten für replizierte Tabellen:

  • S3 Tables repliziert sowohl Iceberg V2- als auch V3-Tabellen. Die Replikation aktualisierter Tabellen (V2 → V3) wird jedoch nicht unterstützt.

  • Metadatendateien, die größer als 500 MB sind, werden nicht unterstützt.

  • Während Tabellenaktualisierungen in der Regel innerhalb von Minuten repliziert werden, kann die Replikation je nach Größe der zu replizierenden Tabellenaktualisierung länger dauern, z. B. wenn die Replikation mit dem Backfilling beginnt.

  • Tabellen mit Tags oder Verzweigungen werden nicht unterstützt.

  • Die Replikation wird für Amazon S3-Metadatentabellen oder andere AWS generierte Systemtabellen nicht unterstützt.

  • Alle Tabellen-Snapshots, einschließlich komprimierter Snapshots, werden aus der Quelltabelle repliziert. Daher wird die Komprimierung für Replikattabellen nicht unterstützt.