S3 Tables レプリケーションの仕組み - Amazon Simple Storage Service

S3 Tables レプリケーションの仕組み

S3 Tables レプリケーションは、リージョンと AWS アカウント間で Apache Iceberg テーブルの読み取り専用レプリカを作成します。レプリカテーブルは S3 Tables サービスによって自動的に管理され、ソーステーブルからの完全なデータ、メタデータ、スナップショット履歴が含まれているため、分析およびタイムトラベルオペレーションに Iceberg 互換エンジンを使用してクエリを実行できます。

テーブルのレプリケーションを設定すると、S3 Tables は次のようになります。

  • ソーステーブルと同じ名前と名前空間を使用して、各送信先テーブルバケットに読み取り専用レプリカテーブルを作成します。

  • レプリカにソーステーブルの最新状態をバックフィルします

  • ソーステーブルの新しい更新をモニタリングします

  • 整合性を維持するために、ソースと同じ順序ですべての更新をレプリカにコミットします

詳細については、次のセクションを参照してください。

レプリケーションの対象

次のテーブルコンポーネントがレプリケートされます。

  • テーブルスナップショット – 圧縮されたスナップショットを含むすべてのスナップショットは、ソーステーブルからの親子関係とシーケンス番号を維持しながら、時系列順にレプリケートされます。これにより、レプリカテーブルはソーステーブルと同じタイムトラベル機能を提供します。

  • テーブルデータ – テーブルスナップショットによって参照されるすべてのデータファイルは、コピー先のリージョンにレプリケートされます。これには、以下が含まれます。

    • メタデータファイル – テーブル metadata.json ファイル、マニフェスト、マニフェストリスト、パーティション統計、テーブル統計。

    • ファイルの削除 – レプリカテーブルのデータ精度を維持するために、すべての削除ファイルがレプリケートされます。

    • データファイル – マニフェストによって参照されるすべてのデータファイルがレプリケートされます。

  • テーブルメタデータ – スキーマ情報 (現在と履歴)、パーティション仕様、ソート順序、テーブルプロパティを含む完全なメタデータのレプリケーション。

    • スキーマ情報 – 現在のスキーマと履歴スキーマのバージョンを含むすべてのテーブルスキーマがレプリケートされます。これにより、レプリカテーブルに対するクエリが正しい列定義、データ型、フィールドマッピングを使用するようになります。レプリケーションプロセスはスキーマの進化履歴を維持し、タイムトラベルクエリをレプリカテーブルで正しく機能させることができます。

    • パーティション仕様 – 現在および過去のパーティション仕様がレプリケートされるため、レプリカテーブルはソーステーブルと同じパーティショニング戦略を維持します。

    • ソート順 – テーブルソート順は、クエリパフォーマンスの最適化を維持するためにレプリケートされます。

データのレプリケート方法

レプリケーションは、ソーステーブルとレプリカテーブル間で Apache Iceberg テーブルメタデータを比較することで、レプリカテーブルの有効な状態を決定します。レプリケーションは 3 つのカテゴリのメタデータを処理して、レプリカテーブルを更新します。

テーブルメタデータの場合

バージョン管理されたメタデータフィールドの場合、レプリケーションはソーステーブルの値を次のフィールドのレプリカテーブルの配列にマージします。

  • snapshots – snapshot-id により、ソーステーブルのすべてのスナップショットをレプリカテーブルのスナップショット配列にマージします。

  • snapshot-log – ソーステーブルのスナップショットログを、タイムスタンプと snapshot-id でソートされたレプリカテーブルの snapshot-log 配列にマージします。

  • sort-orders – ソーステーブルのソート順序定義を、レプリカテーブルの sort-orders 配列に order-id 順でマージします。

  • partition-specs – spec-id により、ソーステーブルのパーティション仕様をレプリカテーブルの partition-specs 配列にマージします。

テーブル設定の場合

テーブル設定を表すフィールドの場合、レプリケーションはソーステーブルから直接値をコピーします。

  • properties

  • partition-statistics

  • statistics

現在のテーブルの状態もソーステーブルから転送されます。

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

レプリカ固有の状態

次のフィールドは、マージされたデータから計算され、レプリカテーブルに対して更新されます。

  • location はレプリカテーブルバケット内の正しいファイルの場所を指すようにレプリケーション中に更新され、すべてのファイル参照がレプリケート先環境で有効になります。

  • metadata-log にはすべての送信先メタデータファイル名が含まれており、現在のメタデータファイル名でレプリケーションが成功するたびに更新されます。

  • すべてのファイルパスは、レプリカテーブルの場所を指すように変更されます。

スナップショットレプリケーション

S3 Tables レプリケーションは、ソーステーブルと同じコミット順序ですべてのテーブルスナップショットをレプリケートすることで、リージョン間で完全なスナップショット履歴を維持します。ソーステーブルからの親子関係は、レプリカテーブルに保持されます。

スナップショット保持期限

レプリケートされたテーブルのカスタムスナップショット保持期間は、ソースの保持期間とは異なるように設定できます。つまり、スナップショットの有効期限が切れ、ソーステーブルで使用できなくなった場合でも、レプリカに保持できます。

例えば、ソーステーブルに 30 日間のスナップショット保持期間があり、レプリカテーブルに 90 日間の保持期間が設定されている場合、レプリカはソーステーブルで使用できなくなった過去 2 か月のスナップショットを維持します。

ソーステーブルで手動で期限切れになったスナップショットもレプリカテーブルに保持されます。例えば、Spark プロシージャを使用してソーステーブルで 2 月のスナップショットを有効期限が切れにした場合でも、レプリカテーブル内のスナップショットにタイムトラベルできます。

考慮事項と制限

レプリケートされたテーブルには、次の考慮事項が適用されます。

  • S3 Tables は Iceberg V2 テーブルと V3 テーブルの両方をレプリケートします。ただし、アップグレードされたテーブル (V2 → V3) のレプリケーションはサポートされていません。

  • 500MB を超えるメタデータファイルはサポートされていません。

  • 通常、テーブルの更新は数分以内にレプリケートされますが、レプリケーションがバックフィルを開始する場合など、レプリケートするテーブルの更新のサイズによっては、レプリケーションに時間がかかることがあります。

  • タグまたはブランチを含むテーブルはサポートされていません。

  • レプリケーションは、Amazon S3 メタデータテーブルやその他の AWS で生成されたシステムテーブルではサポートされていません。

  • 圧縮されたスナップショットを含むすべてのテーブルスナップショットは、ソーステーブルからレプリケートされます。そのため、レプリカテーブルでは圧縮はサポートされていません。