Apache Iceberg V3 の使用 - Amazon Simple Storage Service

Apache Iceberg V3 の使用

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

AWS は、Apache Iceberg バージョン 3 (V3) 仕様で定義されている削除ベクトルと行リネージュをサポートしています。これらの機能は、Amazon EMR 7.12 の Apache Spark、AWS Glue ETLAmazon SageMaker Unified Studio ノートブック、および Amazon S3 Tables を含む AWS Glue Data Catalog の Apache Iceberg テーブルで使用できます。

V3 の主な機能

削除ベクトル

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

行リネージュ

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

バージョン互換性

V3 は V2 テーブルとの下位互換性を維持します。AWS のサービスは V2 テーブルと V3 テーブルの両方を同時にサポートするため、次のことが可能になります。

  • V2 テーブルと V3 テーブルの両方でクエリを実行する

  • データ書き換えなしで既存の V2 テーブルを V3 にアップグレードする

  • V2 および V3 スナップショットにまたがるタイムトラベルクエリを実行する

  • テーブルバージョン間でスキーマ進化と隠しパーティション化を使用する

重要

V3 は一方向アップグレードです。テーブルを V2 から V3 にアップグレードすると、標準オペレーションで V2 にダウングレードすることはできません。

V3 の開始方法

前提条件

V3 テーブルを使用する前に、以下を確認してください。

  • 適切な IAM アクセス許可を持つ AWS アカウント

  • 1 つ以上のAWS 分析サービス (EMR、Glue、Amazon SageMaker Unified Studio ノートブック、または S3 Tables) へのアクセス

  • テーブルデータとメタデータを保存するための S3 バケット

  • 独自の Iceberg インフラストラクチャを構築している場合は、S3 Tables または汎用 S3 バケットの使用を開始するためのテーブルバケット

  • AWS Glue カタログの設定

V3 テーブルの作成

新しい V3 テーブルの作成

新しい Iceberg V3 テーブルを作成するには、 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' )

V2 テーブルを V3 にアップグレードする

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

Spark SQL の使用:

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

V3 は一方向アップグレードです。テーブルを V2 から V3 にアップグレードすると、標準オペレーションで V2 にダウングレードすることはできません。

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

  • 新しいメタデータスナップショットがアトミックに作成されます

  • 既存の Parquet データファイルが再利用されます

  • 行リネージュフィールドがテーブルメタデータに追加されます

  • 次の圧縮では、古い V2 削除ファイルを削除します

  • 新しい変更では V3 の削除ベクトルファイルが使用されます

  • アップグレードでは、行リネージュ変更追跡レコードの履歴バックフィルは実行されません

削除ベクトルの有効化

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

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

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

変更追跡のための行リネージュの活用

V3 は、行リネージュメタデータフィールドを自動的に追加して変更を追跡します。

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 パイプラインの最適化

  • 変更のみを処理することでコンピューティングコストを削減する

V3 のベストプラクティス

どのような場合に V3 を使用するか

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

  • バッチ更新や削除を頻繁に実行する

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

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

  • 行リネージュを活用して増分処理を行う

  • タイムトラベルを使用して、コピーせずに履歴データにアクセスする

  • 統計収集を有効にしてクエリ計画を改善する

移行戦略

V2 から V3 に移行する場合:

  • 本番環境以外で最初にテストする - アップグレードプロセスとパフォーマンスを検証する

  • アクティビティの少ない時間帯にアップグレード - 同時オペレーションへの影響を最小限に抑える

  • 初期パフォーマンスのモニタリング - アップグレード後にメトリクスを追跡する

  • 圧縮の実行 - アップグレード後に削除ファイルを統合する

  • ドキュメントの更新 - V3 機能をチームドキュメントに反映する

互換性に関する考慮事項

  • エンジンバージョン - テーブルにアクセスするすべてのエンジンが V3 をサポートしていることを確認する

  • サードパーティー製ツール - アップグレード前に V3 の互換性を検証する

  • バックアップ戦略 - スナップショットベースの復旧手順をテストする

  • モニタリング - V3 固有のメトリクスのモニタリングダッシュボードを更新する

トラブルシューティング

一般的な問題

エラー: 「format-version 3 is not supported」
  • エンジンバージョンが V3 をサポートしていることを検証します

    Amazon AWS サービスの V3 サポートは次のとおりです。

    サービス V3 のサポート
    EMR Spark リリース 7.12+
    AWS Glue ETL あり
    Amazon SageMaker Unified Studio ノートブック あり
    AWS Glue: Iceberg REST API、テーブルメンテナンス あり
    Amazon S3 Tables: Iceberg REST API、テーブルメンテナンス あり
    Amazon Athena (Trino) 不可
  • カタログの互換性を確認します

  • 最新の AWS サービスバージョンを確認します

アップグレード後のパフォーマンスの低下
  • 圧縮の失敗がないことを確認します。詳細については、「S3 Tables でのログ記録とモニタリング」を参照してください。

  • 削除ベクトルが有効になっているかどうかを確認します。以下のプロパティが設定されていることを確認します。

    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
サードパーティー製ツールとの非互換性
  • ツールが V3 仕様をサポートしていることを検証します

  • サポートされていないツールの V2 テーブルの管理を検討します

  • V3 サポートタイムラインについてはツールベンダーにお問い合わせください

ヘルプの使用

  • AWS サポート: サービス固有の問題については、AWS サポートにお問い合わせください

  • Apache Iceberg コミュニティ: Iceberg Slack

  • AWS ドキュメント: AWS Analytics ドキュメント

料金

利用可能な状況

Apache Iceberg V3 のサポートは、Amazon EMR、AWS Glue Data Catalog、AWS Glue ETL、S3 Tables が動作するすべての AWS リージョンで利用できます。

その他のリソース