バージョン 3 の主な機能バージョン互換性バージョン 3 の開始方法バージョン 3 のベストプラクティス移行戦略互換性に関する考慮事項トラブルシューティング料金利用可能な状況その他のリソース

Iceberg テーブル形式仕様バージョン 3 の使用

Apache Iceberg テーブル形式の仕様の最新バージョンはバージョン 3 です。このバージョンでは、ペタバイト規模のデータレイクを構築するための高度な機能が導入され、パフォーマンスが向上し、運用オーバーヘッドが削減されます。バージョン 2 で発生する一般的なパフォーマンスのボトルネック、特にバッチ更新とコンプライアンス削除オペレーションに関するボトルネックに対処します。

AWS では、Iceberg バージョン 3 仕様で定義されている削除ベクトルと行リネージュがサポートされています。これらの機能は、以下の Apache Spark で使用できます AWS のサービス。

AWS のサービス	バージョン 3 のサポート
Amazon EMR for Apache Spark	Amazon EMR リリース 7.12 以降
AWS Glue	はい
AWS Glue: Iceberg REST API、テーブルメンテナンス	はい
Amazon SageMaker Unified Studio ノートブック	はい
Amazon S3 Tables: Iceberg REST API、テーブルメンテナンス	はい
Amazon Athena (Trino)	いいえ

バージョン 3 の主な機能

削除ベクトルは、バージョン 2 で使用された位置削除ファイルを、Puffin ファイルとして保存された効率的なバイナリ形式に置き換えます。これにより、ランダムバッチ更新や一般データ保護規則 (GDPR) コンプライアンスの削除による書き込み増幅がなくなり、新しいデータを維持するオーバーヘッドが大幅に削減されます。高頻度の更新を処理する組織では、書き込みパフォーマンスがすぐに向上し、小さなファイルが少なくてストレージコストを削減できます。

行リネージュにより、行レベルで正確な変更追跡が可能になります。ダウンストリームシステムは段階的に変更を処理し、データパイプラインを高速化し、変更データキャプチャ (CDC) ワークフローのコンピューティングコストを削減できます。この組み込み機能により、カスタム変更追跡実装が不要になります。

バージョン互換性

バージョン 3 は、バージョン 2 テーブルとの下位互換性を維持します。AWS のサービスでは、バージョン 2 とバージョン 3 の両方のテーブルを同時にサポートしているため、次のことが可能になります。

バージョン 2 とバージョン 3 の両方のテーブルでクエリを実行します。
データ書き換えなしで、既存のバージョン 2 テーブルをバージョン 3 にアップグレードします。
バージョン 2 とバージョン 3 のスナップショットにまたがるタイムトラベルクエリを実行します。
スキーマの進化とテーブルバージョン間の非表示パーティショニングを使用します。

バージョン 3 の開始方法

前提条件

バージョン 3 のテーブルを使用する前に、以下があることを確認してください。

適切な AWS Identity and Access Management (IAM) アクセス許可 AWS アカウントを持つ。
1 つ以上の AWS 分析サービス (Amazon EMR、 AWS Glue Amazon SageMaker Unified Studio ノートブック、または Amazon S3 Tables) へのアクセス。
テーブルデータとメタデータを保存するための S3 バケット。
独自の Iceberg インフラストラクチャを構築している場合は、Amazon S3 Tables または汎用 S3 バケットの使用を開始するためのテーブルバケット。
設定された AWS Glue カタログ。

バージョン 3 テーブルの作成

新しいテーブルの作成

新しい Iceberg バージョン 3 テーブルを作成するには、format-versionテーブルプロパティを 3 に設定します。

Spark SQL の使用:


CREATE TABLE IF NOT EXISTS myns.orders_v3 (
    order_id bigint,
    customer_id string,
    order_date date,
    total_amount decimal(10,2),
    status string,
    created_at timestamp
)
USING iceberg
TBLPROPERTIES (
    'format-version' = '3'
)

バージョン 2 テーブルをバージョン 3 にアップグレードする

データを書き換えることなく、既存のバージョン 2 テーブルをバージョン 3 にアトミックにアップグレードできます。

Spark SQL の使用:


ALTER TABLE myns.existing_table
SET TBLPROPERTIES ('format-version' = '3')

重要

バージョン 3 は一方向アップグレードです。テーブルをバージョン 2 からバージョン 3 にアップグレードした後は、標準オペレーションを通じてバージョン 2 にダウングレードすることはできません。

アップグレード中に何が起こるか:

新しいメタデータスナップショットがアトミックに作成されます。
既存の Parquet データファイルは再利用されます。
行の系統フィールドがテーブルメタデータに追加されます。

アップグレード後:

次の圧縮では、古いバージョン 2 の削除ファイルを削除します。
新しい変更では、バージョン 3 の削除ベクトルファイルが使用されます。

アップグレードでは、行系統変更追跡レコードの履歴バックフィルは実行されません。

削除ベクトルの有効化

更新、削除、マージの削除ベクトルを利用するには、書き込みモードを設定します。

Spark SQL の使用:


ALTER TABLE myns.orders_v3
SET TBLPROPERTIES ('format-version' = '3',
                   'write.delete.mode' = 'merge-on-read',
                   'write.update.mode' = 'merge-on-read',
                   'write.merge.mode' = 'merge-on-read'
                  )

これらの設定により、データファイル全体を書き換えるのではなく、更新、削除、マージオペレーションによって削除ベクトルファイルが作成されます。

変更の追跡に行リネージュを使用する

バージョン 3 では、行系統メタデータフィールドが自動的に追加され、変更を追跡します。

Spark SQL の使用:


# Query with parameter value provided
last_processed_sequence = 47

SELECT 
    id,
    data,
    _row_id,
    _last_updated_sequence_number
FROM myns.orders_v3
WHERE _last_updated_sequence_number > :last_processed_sequence

_row_id フィールドは各行を一意に識別し_last_updated_sequence_number、行が最後に変更された日時を追跡します。これらのフィールドを使用して、次の操作を行います。

増分処理のために変更された行を特定します。
コンプライアンスに関するデータ系統を追跡します。
CDC パイプラインを最適化します。
変更のみを処理することで、コンピューティングコストを削減します。

バージョン 3 のベストプラクティス

バージョン 3 を使用するタイミング

次の場合は、バージョン 3 にアップグレードするか、バージョン 3 から開始することを検討してください。

バッチ更新や削除を頻繁に実行します。
GDPR またはコンプライアンス削除の要件を満たす必要があります。
ワークロードには、高頻度のアップサートが含まれます。
効率的な CDC ワークフローが必要です。
小さなファイルからストレージコストを削減したい。
より良い変更追跡機能が必要です。

書き込みパフォーマンスの最適化

更新が多いワークロードの削除ベクトルを有効にします。


SET TBLPROPERTIES (
'write.delete.mode' = 'merge-on-read',
'write.update.mode' = 'merge-on-read',
'write.merge.mode' = 'merge-on-read'
)

適切なファイルサイズを設定します。


SET TBLPROPERTIES (
'write.target-file-size-bytes' = '536870912'  — 512 MB
)

読み取りパフォーマンスの最適化

増分処理には行リネージュを使用します。
タイムトラベルを使用して、コピーせずに履歴データにアクセスします。
統計収集を有効にして、クエリ計画を改善します。

移行戦略

バージョン 2 からバージョン 3 に移行する場合は、次のベストプラクティスに従ってください。

まず非本番環境でテストして、アップグレードプロセスとパフォーマンスを検証します。
アクティビティが少ない時間帯にアップグレードして、同時オペレーションへの影響を最小限に抑えます。
初期パフォーマンスをモニタリングし、アップグレード後のメトリクスを追跡します。
圧縮を実行して、アップグレード後に削除ファイルを統合します。
バージョン 3 の機能を反映するようにチームのドキュメントを更新します。

互換性に関する考慮事項

エンジンバージョン – テーブルにアクセスするすべてのエンジンがバージョン 3 をサポートしていることを確認します。
サードパーティー製ツール – アップグレードする前に、ツールのバージョン 3 の互換性を確認してください。
バックアップ戦略 – スナップショットベースの復旧手順をテストします。
モニタリング – バージョン 3 固有のメトリクスのモニタリングダッシュボードを更新します。

トラブルシューティング

一般的な問題

エラー: "format-version 3 is not supported"

エンジンバージョンがバージョン 3 をサポートしていることを確認します。詳細については、このセクションの冒頭にある表を参照してください。
カタログの互換性を確認します。
の最新バージョンを使用していることを確認してください AWS のサービス。

アップグレード後のパフォーマンスの低下

圧縮圧縮の失敗がないことを確認します。詳細については、Amazon S3 ドキュメントの「S3 テーブルのログ記録とモニタリング」を参照してください。 Amazon S3
削除ベクトルが有効になっていることを確認します。次のプロパティを設定する必要があります。
```
SET TBLPROPERTIES (
'write.delete.mode' = 'merge-on-read',
'write.update.mode' = 'merge-on-read',
'write.merge.mode' = 'merge-on-read'
)
```
テーブルのプロパティは、次のコードで確認できます。
```
DESCRIBE FORMATTED myns.orders_v3
```
パーティション戦略を確認します。パーティション分割が多すぎると、小さなファイルが発生する可能性があります。次のクエリを実行して、テーブルの平均ファイルサイズを取得します。
```
SELECT avg(file_size_in_bytes) as avg_file_size_bytes 
FROM myns.orders_v3.files
```

サードパーティー製ツールとの非互換性

ツールがバージョン 3 仕様をサポートしていることを確認します。
サポートされていないツールのバージョン 2 テーブルの管理を検討してください。
バージョン 3 のサポートタイムラインについては、ツールベンダーにお問い合わせください。

ヘルプの利用

AWS のサービス固有の問題については、にお問い合わせくださいAWS サポート。
Iceberg コミュニティからサポートを受けるには、Iceberg Slack チャネルを使用します。
AWS のサービスを使用して分析ワークロードを管理する方法については、「の分析 AWS」を参照してください。

料金

利用可能な状況

Iceberg テーブル形式の仕様バージョン 3 のサポートは、Amazon EMR AWS Glue、 AWS Glue Data Catalog、および S3 Tables が動作するすべての AWS リージョンで利用できます。リージョンの可用性については、AWS のサービス「リージョン別」を参照してください。

その他のリソース

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

PyIceberg を使用した Iceberg テーブルの操作

既存のテーブルを Iceberg に移行する