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 Replikation von S3-Tabellen werden schreibgeschützte Repliken Ihrer Apache Iceberg-Tabellen in allen 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-kompatiblen Engine für Analysen und Zeitreisen abgefragt werden können.

Wenn Sie die Replikation für eine Tabelle konfigurieren, gehen S3-Tabellen wie folgt vor:

  • 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 Updates

  • Übergibt alle Aktualisierungen an Replikate in derselben Reihenfolge wie die Quelle, um die Konsistenz zu wahren

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 die Beziehungen zwischen übergeordneten und untergeordneten Objekten und die Sequenznummern aus der Quelltabelle beibehalten werden. Dadurch wird sichergestellt, dass Replikattabellen dieselben Funktionen für Zeitreisen bieten wie Quelltabellen.

  • Tabellendaten — Alle Datendateien, auf die in Tabellenschnappschüssen verwiesen wird, werden in die Zielregion repliziert. Dies umfasst:

    • Metadatendateien — Metadata.json-Dateien für Tabellen, Manifeste, Manifestlisten, Partitionsstatistiken und Tabellenstatistiken.

    • Dateien löschen — Alle gelöschten Dateien werden repliziert, um die Datengenauigkeit in den Replikattabellen zu gewährleisten.

    • 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 der historischen 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 Zeitreiseabfragen in Replikattabellen korrekt funktionieren.

    • Partitionsspezifikationen — Aktuelle und historische Partitionsspezifikationen werden repliziert, um sicherzustellen, dass Replikattabellen dieselbe Partitionierungsstrategie wie Quelltabellen beibehalten.

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

Wie werden Daten repliziert

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

Für Tabellenmetadaten

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

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

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

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

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

Für die Tabellenkonfiguration

Bei Feldern, die die Tabellenkonfiguration repräsentieren, 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(Iceberg V3)

  • encryption-keys(Eisberg V3)

Replikatspezifischer Status

Die folgenden Felder werden anhand zusammengeführter Daten berechnet und für die Replikattabelle aktualisiert:

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

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

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

Snapshot-Replikation

Bei der Replikation von S3-Tabellen wird der vollständige Snapshot-Verlauf regionsübergreifend beibehalten, indem alle Tabellen-Snapshots in derselben Commit-Reihenfolge wie die Quelltabelle repliziert werden. Die Beziehungen zwischen über- und untergeordneten Elementen aus der Quelltabelle werden in der Replikattabelle beibehalten.

Snapshot-Aufbewahrung

Sie können einen benutzerdefinierten Aufbewahrungszeitraum für Snapshots für Ihre replizierten Tabellen konfigurieren, der sich von der Aufbewahrungsdauer der Quelle unterscheidet. Das bedeutet, dass Snapshots, auch wenn sie abgelaufen sind und nicht mehr in der Quelltabelle verfügbar sind, in Replikaten aufbewahrt werden können.

Wenn Ihre Quelltabelle beispielsweise eine Aufbewahrungsfrist von 30 Tagen für Snapshots hat, Ihre Replikattabelle jedoch mit einer Aufbewahrungsfrist von 90 Tagen konfiguriert ist, speichert 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 auch in der Replikattabelle beibehalten. Wenn Sie beispielsweise Snapshots vom Februar in der Quelltabelle mithilfe eines Spark-Verfahrens abgelaufen sind, können Sie trotzdem zu den Snapshots in der Replikattabelle eine Zeitreise unternehmen.

Überlegungen und Einschränkungen

Die folgenden Überlegungen gelten für replizierte Tabellen:

  • S3 Tables repliziert sowohl Iceberg V2- als auch Iceberg V3-Tabellen. Die Replikation von aktualisierten 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. Aus diesem Grund wird die Komprimierung für Replikattabellen nicht unterstützt.