データレイクハウス（データレイクの柔軟性とデータウェアハウスの管理機能を両立させる基盤）を Apache Iceberg で構築しているチームに向けた内容です。Iceberg のテーブルフォーマット仕様が V4 で変わろうとしており、ストリーミング処理の設計に影響する可能性があります。対岸の火事にせず、自分のパイプラインが該当するか確認できる材料を整理します。
何が起きているか
2026年7月時点の Apache Iceberg 開発者メーリングリストで、equality delete（等価削除）を V4 仕様から廃止する提案が再燃しました。
equality delete は、行の物理的な位置ではなく「このカラムのこの値を持つ行を削除せよ」という条件で削除を表現する仕組みです。Iceberg には他に position delete（削除対象の行をファイルとオフセットで直接指定する方式）があり、V3 以降はこちらが主流になりつつあります。
この提案には Flink（ストリーム処理エンジン）のコミッターである Maximilian Michels 氏が強く反応しました。氏は equality delete を「ストリーミングユースケース最大の悩みの種」と表現しています。
merge-on-read（読み取り時にベースデータと削除情報をマージする方式）のコストが高く見えた時点で、多くの利用者が Iceberg のコア機能を諦め、独自の回避策を組み上げてしまうという指摘です。この議論だけで9件の実質的なやり取りが交わされており、注目度の高さがうかがえます。
併せて、Iceberg Rust 0.10.0（JVM を使わない Rust 実装）のリリース投票が可決され、Terraform provider の v0.1.0 RC1（インフラをコードで管理する仕組みの Iceberg 版）も投票段階に進みました。フォーマット層の議論と、運用を支えるツール群の整備が同時並行で進んでいる状況です。
なぜこの変更が起きているか
原因を段階的に見ていきます。
まず、equality delete は書き込み側にとって書きやすい仕組みです。値さえ分かれば削除条件を書けるため、CDC（Change Data Capture、データベースの変更をイベントとして流す仕組み）のようなストリーミング用途と相性が良いとされてきました。
しかし読み取り側の負担が大きい点が問題視されています。equality delete が指す行を特定するには、対象ファイル全体をスキャンして条件に一致する行を洗い出す必要があります。position delete のように行の位置を直接指すやり方に比べ、クエリのたびに割高な処理が発生しやすい構造です。
さらに Flink 側の実装状況が、廃止議論を後押ししています。Michels 氏によれば、equality delete を position delete 相当のインデックスに変換する仕組み（ConvertEqualityDeletes）が Flink の RocksDB（永続化対応のキーバリューストア）ベースの管理状態に組み込まれ、チェックポイントごとに更新される段階まで進んでいます。
ただし、この変換自体は今のところ Flink エンジンに依存しており、他のエンジンでは使えません。このインデックスを Iceberg 側に保存し、どのエンジンからも扱える形にすることが次の目標とされています。エンジン非依存という Iceberg の設計思想からすると、equality delete が「特定エンジン頼み」の残存機能になっている状態自体が技術的負債と見なされている構図です。
自分のプロジェクトが該当するか確認する方法
この変更が影響するかどうかは、書き込みパスと削除方式を実際に確認しないと判断できません。
以下の観点でチェックしてみてください。
- 使用しているテーブルフォーマットのバージョンを、テーブルのメタデータ JSON の
format-versionフィールドで確認する（V1〜V3 の現行値、V4 は策定中） - Flink、Spark Streaming、Kafka Connect などのストリーミング書き込みを Iceberg テーブルに行っているかを、書き込みジョブの設定から棚卸しする
- 使用中の書き込みエンジンが equality delete と position delete のどちらを生成しているかを、Iceberg のカタログツールや
iceberg-cliのfilesコマンド系でデータファイルの delete ファイルタイプを確認する - クエリのレイテンシが想定より高い場合、merge-on-read のコストが原因かどうかを、クエリエンジンの実行計画（EXPLAIN 結果）で delete ファイルのスキャン量を確認する
バッチ書き込みが中心で position delete のみを使っている構成であれば、今回の議論の影響は限定的です。一方、CDC 経由でリアルタイムに Upsert（更新か挿入かを自動判定する処理）を行い、Flink 以外のエンジンでもテーブルを読み書きしている場合は要注意です。
対策の手順
該当する可能性がある場合、次の順序で備えるのが現実的です。
1. 使用中の Iceberg クライアントライブラリ（Java 実装、PyIceberg、Iceberg Rust など）のバージョンと、equality delete のサポート状況を公式リリースノートで確認する
2. ストリーミング書き込みパスが position delete ベースの実装に移行できるか、Flink Iceberg connector のドキュメントで対応バージョンを調べる
3. merge-on-read によるクエリコストが許容範囲かどうかを、実データの規模でベンチマークし、compaction（削除ファイルをマージしてテーブルを最適化する処理）の頻度を見直す
4. V4 仕様の策定状況を Apache Iceberg の GitHub リポジトリと dev メーリングリストで定期的に追跡し、破壊的変更が確定する前に移行計画を立てる
Terraform provider のような IaC（Infrastructure as Code）ツールの整備も、この移行を安全に進める助けになります。カタログのテーブル定義やプロパティをコードで宣言しておけば、V4 移行時のテーブルプロパティ変更も plan ステップで事前に検知できます。
まとめ
Apache Iceberg の equality delete 廃止議論は、ストリーミング書き込みとクエリ性能のトレードオフを、フォーマット層でどこまで許容するかという設計判断です。
自分のプロジェクトが影響を受けるかは、テーブルの format-version、書き込みエンジンの種類、delete ファイルの方式という3点をまず確認することで判断できます。
Flink 以外のエンジンでも equality delete を扱えるようにする動きはまだ道半ばであり、性能とエンジン互換性のどちらを優先するかは今後も議論が続く見込みです。自分たちの書き込みパスがどちら側に立っているか、まずは delete ファイルの中身を覗くところから始めてみてください。