Apache Iceberg V3 の deletion vectors と row lineage でデータレイク操作を高速化する

本記事は 2025 年 11 月 26 日に公開された「Accelerate data lake operations with Apache Iceberg V3 deletion vectors and row lineage」を翻訳したものです。

ペタバイト規模のデータレイクを構築する組織は、データの増大に伴い課題が増えています。バッチ更新やコンプライアンス対応の削除処理により位置削除ファイル (positional delete files) が増加し、下流のデータパイプラインが遅くなり、ストレージコストも上昇します。監査証跡や増分処理のためにデータ変更を追跡するには、エンジン固有のカスタム実装が必要で、複雑さと保守負荷が増します。データ量が増えるほど課題は深刻化し、データチームはデータの鮮度とコンプライアンスを維持するためだけに、カスタムソリューションの管理と運用コストの増大に追われることになります。

Apache Iceberg V3 は、deletion vectors (削除ベクトル) と row lineage (行リネージ) という 2 つの機能で上記の課題に対応します。AWS は Amazon EMR 7.12 上の Apache Spark、AWS Glue、Amazon SageMaker ノートブック、Amazon S3 Tables、AWS Glue Data Catalog でこの機能を提供しており、カスタム実装なしで統合された Iceberg V3 での体験を利用できます。書き込みの高速化、ストレージコストの削減、完全な監査証跡、効率的な増分処理を、データレイクアーキテクチャ全体で実現できます。

本記事では、Iceberg V3 の新機能を紹介し、deletion vectors と row lineage がどのように課題を解決するかを説明します。さらに、業界横断のユースケースを紹介し、AWS のアナリティクス、カタログ、ストレージサービスで Iceberg V3 機能の実装手順を紹介します。

Iceberg V3 の新機能

Iceberg V3 では新しい機能とデータ型が導入されました。中でも deletion vectors と row lineage が上記の課題を解決する主要な機能です。

Deletion vectors は、位置削除ファイルを Puffin ファイルとして保存される効率的なバイナリ形式に置き換えます。削除操作ごとに個別の削除ファイルを作成する代わりに、削除参照をデータファイルごとに 1 つの deletion vector に集約します。クエリ実行時、エンジンはこのコンパクトなベクトルを使って削除済みの行を効率的にフィルタリングし、複数の削除ファイルをマージせずにクエリパフォーマンスを維持できます。

ランダムなバッチ更新や GDPR コンプライアンス削除による書き込み増幅を回避でき、データの鮮度維持にかかる負荷を大幅に削減します。高頻度の更新ワークロードでは、書き込みパフォーマンスの向上と小さな削除ファイルの減少によるストレージコスト削減をすぐに実感できます。さらに、小さな削除ファイルが減ることで、コンパクション操作のテーブルメンテナンスコストも低減します。

Row lineage は、行レベルで正確な変更追跡と完全な監査を実現します。各データファイルに、行の作成日時と最終更新日時を追跡するメタデータフィールドを追加します。_row_id フィールドは各行を一意に識別し、_last_updated_sequence_number フィールドは行が最後に変更されたスナップショットを追跡します。テーブル全体をスキャンせずに効率的な変更追跡クエリが可能になり、カスタムコードなしで Iceberg 仕様により自動的に管理されます。

Row lineage 以前は、Iceberg の変更追跡はスナップショット間の差分のみを提供しており、個々のレコードの変更を追跡するのが困難でした。Row lineage のメタデータフィールドをクエリすることで、すべての増分変更を取得でき、データ変更の監査や規制コンプライアンスに必要な正確性を確保できます。データ変換では、下流システムが変更を増分的に処理できるため、変更データキャプチャ (CDC) ワークフローのデータパイプラインが高速化し、コンピューティングコストが削減されます。Row lineage はエンジンに依存せず、相互運用可能で、Iceberg V3 仕様に組み込まれているため、エンジン固有のカスタム変更追跡実装が不要になります。

実際のユースケース

Iceberg V3 の新機能は、複数の業界で重要な課題に対応します。

マーケティング・広告サービス企業 – GDPR の忘れられる権利リクエストや規制コンプライアンス削除を、パイプラインパフォーマンスを低下させていた書き込み増幅なしに効率的に処理できます。Row lineage はデータ変更の完全な監査証跡を提供し、データガバナンスの厳格な規制要件を満たします。
毎日数百万件の商品更新や在庫変更を処理する E コマースプラットフォーム – ストレージコストを削減しながらデータの鮮度を維持できます。Deletion vectors により高速な upsert 操作が可能になり、ピーク時の厳しい SLA 要件を満たせます。
ヘルスケア・ライフサイエンス企業 – コンプライアンス目的で患者データの変更を正確に追跡しながら、大規模なゲノムデータセットを効率的に処理できます。Row lineage は、臨床試験の監査や規制当局への提出に必要な詳細な変更履歴を提供します。
大規模な視聴データカタログを管理するメディア・エンターテインメントプロバイダー – レコメンデーションエンジン向けの増分変更を効率的に処理できます。Row lineage により、下流の分析システムは変更されたレコードのみを処理でき、増分処理シナリオのコンピューティングコストを削減できます。

Iceberg V3 を使い始める

Iceberg V3 で deletion vectors による書き込み最適化と row lineage による組み込みの変更追跡を活用するには、テーブル作成時にテーブルプロパティ format-version = 3 を設定します。既存の Iceberg V2 テーブルにこのプロパティを設定すると、データの書き換えなしにアトミックにアップグレードされます。V3 テーブルの作成やアップグレードの前に、ソリューション内の Iceberg エンジンが V3 に対応していることを確認してください。詳細は Apache Iceberg V3 on AWS を参照してください。

Amazon EMR 7.12 上の Apache Spark で V3 テーブルを新規作成する

以下のコードは customer_data という名前のテーブルを新規作成します。テーブルプロパティ format-version = 3 を設定すると V3 テーブルが作成されます。format-version テーブルプロパティを明示的に設定しない場合、V2 テーブルが作成されます。V2 は現在 Iceberg のデフォルトテーブルバージョンです。write.delete.mode、write.update.mode、write.merge.mode を merge-on-read に設定すると、テーブルに対する delete、update、merge ステートメントで Spark が deletion vectors を書き込むように構成されます。

CREATE TABLE customer_data (
customer_id bigint,
name string,
email string,
last_purchase timestamp,
total_spent decimal(10,2)
)
USING iceberg
TBLPROPERTIES (
'format-version' = '3',
'write.delete.mode' = 'merge-on-read',
'write.update.mode' = 'merge-on-read',
'write.merge.mode' = 'merge-on-read'
)

以下のコードを実行して customer_data テーブルにレコードを挿入します。

INSERT INTO customer_data VALUES
 (1, 'Alejandro Rosalez', 'alejandro_rosalez@example.org', TIMESTAMP '2025-11-24 18:55:27', 42.97)
,(2, 'Akua Mansa', 'akua_mansa@example.org', TIMESTAMP '2025-11-24 17:55:27', 25.02)
,(3, 'Ana Carolina Silva','anacarolina_silva@example.org', TIMESTAMP '2025-11-24 16:55:27', 43.67)
,(4, 'Arnav Desai','arnav_desai@example.org', TIMESTAMP '2025-11-24 15:55:27', 98.32)
,(5, 'Carlos Salazar','carlos_salazar@example.org', TIMESTAMP '2025-11-24 12:55:27', 76.45)

customer_id = 5 のレコードを削除して削除ファイルを生成します。

DELETE 
  FROM customer_data 
  WHERE customer_id = 5

以下の update ステートメントでレコードを更新すると、削除ファイルも生成されます。

UPDATE customer_data
  SET name = 'Mansa Akua' 
  WHERE customer_id = 2

この例の最後に、マニフェストのメタデータテーブルをクエリして削除ファイルが生成されたことを確認します。

SELECT added_snapshot_id
      ,sum(added_delete_files_count) as added_delete_files_count 
FROM customer_data.manifests 
GROUP BY added_snapshot_id 
ORDER BY added_snapshot_id

このクエリは以下のスクリーンショットのように 3 件のレコードを返します。レコードを挿入した最初のスナップショットの added_delete_files_count は 0 になります。対応する delete ステートメントと update ステートメントの次の 2 つのスナップショットでは、added_delete_files_count の値がそれぞれ 1 になります。

Row lineage で変更を追跡するクエリ

Row lineage は V3 テーブルで自動的に有効になります。以下の例では、row lineage のメタデータフィールドを含め、特定のシーケンス番号以降のテーブル変更をクエリする方法を示します。

SELECT
customer_id,
name,
email,
_row_id,
_last_updated_sequence_number
FROM customer_data
WHERE _last_updated_sequence_number > 0
ORDER BY _last_updated_sequence_number, _row_id

前述の insert、update、delete ステートメントの後にこのクエリを実行すると、以下のスクリーンショットのように 4 件のレコードが返されます。削除されたレコードは除外されています。customer_id = 2 の更新に対する _last_updated_sequence_number は 3 です。

既存の V2 テーブルをアップグレードする

既存の V2 テーブルを V3 にアップグレードするには、以下のコマンドを実行します。

ALTER TABLE existing_customer_data
SET TBLPROPERTIES ('format-version' = '3')

テーブルを V2 から V3 にアップグレードすると、いくつかの重要な操作がアトミックに実行されます。

新しいメタデータスナップショットがアトミックに作成され、データ損失は発生しません。
既存の Parquet データファイルは変更なしで再利用されます。
Row lineage フィールド (_row_id と _last_updated_sequence_number) がテーブルメタデータに追加されます。
次のコンパクション操作で古い V2 の位置削除ファイルが削除されます。コンパクション実行前に新しい deletion vector ファイルが生成された場合、既存の V2 位置削除ファイルがマージされます。
新しい変更は自動的に V3 の deletion vector ファイルを使用します。
アップグレードでは、row lineage の変更追跡レコードの過去データのバックフィルは行われません。

アップグレードプロセスは同期的で、ほとんどのテーブルで数秒で完了します。アップグレードが失敗した場合、エラーメッセージが即座に返され、テーブルは V2 の状態のまま維持されます。

Iceberg V3 を最大限に活用する

Iceberg V3 をすでに使用しているお客様から得た知見を紹介します。

ワークロードパターンを把握する

Deletion vectors は、高頻度の更新、バッチ削除、ランダムな非追記型更新を行う CDC ワークロードなど、書き込みが多い場合に最も効果を発揮します。読み取りよりも書き込みが多い場合、deletion vectors ですぐにパフォーマンスが向上します。deletion vectors の効果を得るには、テーブルの delete、update、merge 操作を merge-on-read モードに設定してください。

AWS にコンパクションを任せる

Data Catalog で自動コンパクションを有効にするか、S3 Tables (デフォルトで自動コンパクションが有効) を使用してください。カスタムメンテナンスジョブを構築せずに、自動的に最適化されます。Deletion vectors は Iceberg V2 の位置削除よりも削除ファイルが少なくなります。同様のパターンと変更レコード量であれば、V3 のコンパクションは V2 よりも高速かつ低コストになります。

V2 の changelog を使用する場合の row lineage の重要性を理解する

Iceberg V2 の Spark changelog プロシージャでは、スナップショット間で行が挿入されてから削除されると、変更フィードに表示されず、その行を確認できません。Iceberg V3 の row lineage は、_last_updated_sequence_number が変更のたびに更新されるため、両方の操作をキャプチャします。すべてのレコードに何が起きたかを証明する必要がある監査証跡や規制コンプライアンスにおいて、完全な変更履歴を残せる点が重要です。パフォーマンス面では、V2 の changelog は変更を計算するために削除ファイルのスキャンとマージが必要で、読み取りのたびにコンピューティングコストが発生します。V3 の row lineage はメタデータフィールドを各行に直接保存するため、_last_updated_sequence_number によるフィルタリングはシンプルなメタデータスキャンで済みます。

アップグレード前にテストする

Iceberg V3 のアップグレードはアトミックで高速ですが、まず開発環境でテストしてください。共有テーブルをアップグレードする前に、すべてのクエリエンジンが Iceberg V3 に対応していることを確認してください。V2 と V3 のエンジンが混在すると問題が発生します。アップグレード後は、パフォーマンスを検証する間、タイムトラベルクエリ用に V2 のスナップショットを一時的に保持しておくことをお勧めします。

まとめ

AWS のアナリティクス、カタログ、ストレージサービスでの Iceberg V3 サポートは、データレイク機能の重要なアップデートです。Deletion vectors の書き込み最適化と row lineage の変更追跡を組み合わせることで、より効率的で監査可能、かつコスト効率の高いデータレイクを大規模に構築できます。AWS サービス間の相互運用性により、データレイクアーキテクチャの柔軟性と将来への対応力が確保されます。

AWS での Iceberg V3 サポートの詳細は、Using Apache Iceberg on AWS を参照してください。

AWS での Iceberg を使用したモダンデータレイク構築の詳細は、Analytics on AWS を参照してください。

著者について

この記事は Kiro が翻訳を担当し、Solutions Architect の松岡勝也がレビューしました。

Amazon Web Services ブログ