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 で生成されたシステムテーブルではサポートされていません。
-
圧縮されたスナップショットを含むすべてのテーブルスナップショットは、ソーステーブルからレプリケートされます。そのため、レプリカテーブルでは圧縮はサポートされていません。