Apache Data Lakehouse WeeklyのIceberg V4とPolaris MCP認証を調べた

Alex Mercedの Apache Data Lakehouse Weekly: July 21 to July 29, 2026 が、Apache Iceberg、Polaris、Parquet、Arrow、DataFusion、Ossieの動きをまとめている。

プロジェクト	動き	状況
Iceberg	equality delete（等価削除）のV4非推奨	議論中
Iceberg	RESTカタログの式表現、remote signing（リモート署名）、incremental scan（増分スキャン）	議論中
Parquet	浮動小数点向けALP符号化の形式への追加	投票で可決
Parquet	`parquet.thrift` の `parquet-java` への取り込み	提案が出た
Polaris	1.7.0 rc0	ライセンス文書の不足で取り下げ
Polaris	主体属性（principal properties）とMCP向け認証モード	検討中
Arrow	複合型のnull許容フラグの意味	議論中

先に書いた MCP仕様2026-07-28でプロトコルがステートレス化した記事は、セッションID廃止や server/discover をプロトコル側から調べた。
今回のPolarisで議論されているのは、MCPプロセスからカタログへ接続するときの権限主体だ。誰の権限でカタログへ到達するかは、プロトコルのステートレス化とは別にカタログ側で決まる。

Iceberg V4のequality delete非推奨

Icebergでは、equality deleteをV4で非推奨にする議論が出ている。
equality deleteは「idが42の行を消す」のように、対象行がどのファイルにあるかを書き込み側が知らなくても削除を書ける仕組みだ。
ストリーミング書き込みでは、削除対象のファイル内位置を事前に持たなくても処理できる。
代わりに読み取り側は毎回削除条件を照合しながらスキャンする。プランナーは「この削除がどのファイルに対応するか」を絞り込む条件を持たず、削除対象を広めに見積もって評価する。

Weeklyの記事では、Ryan BlueがHuaxin Gaoの提案に強く賛成し、既存V2/V3テーブルのequality deleteはアップグレード後も読み取り可能にする一方、V4では新規書き込みを禁止する案を示している。
移行経路として、Flinkによるバックグラウンド変換と、将来の共有索引を使った書き込み時の削除ベクトル（delete vector）生成が議論されている。

この提案は、FlinkやCDC（変更データキャプチャ）系の取り込みをIcebergへ直接流す構成に影響する。
既存分は変換やコンパクションで解消する。変換後の削除は削除ベクトルに置き換わり、コンパクション後は書き換え済みデータに反映される。行位置を解決できない書き込み側については、V3でequality deleteを書き続けながらバックグラウンド変換を併用する案と、将来の共有索引を使って削除ベクトルを生成しV4へ移る案が議論されている。

flowchart TD
    EQ[V2/V3テーブルの<br/>equality delete] -->|アップグレード後も<br/>読み取りは可能| V4[V4テーブル<br/>新規書き込みは禁止]
    EQ -->|Flinkによる<br/>バックグラウンド変換| DV[削除ベクトルへ<br/>置き換え]
    W[行位置を解決できない<br/>書き込み側] -->|案1| EQ3[V3でequality deleteを<br/>書き続けながら<br/>変換を併用]
    W -->|案2| DV2[将来の共有索引で<br/>削除ベクトルを生成しV4へ]

incremental scanでも、実装差を仕様で定義する議論が出ている。
現在のREST incremental scan APIはファイル集合を返し、追記のみの差分を扱う。
削除や更新を含む差分は、ファイル集合の形では表せない。
V4の変更検知（change detection）では、スナップショット間の差分の意味を仕様から読める方向に進んでいる。

Parquet ALP符号化の投票

Parquet側では、ALP符号化を形式へ入れる提案が投票で可決された。
Weeklyの記事によると +1 が11票、そのうちbinding vote（拘束票）が7票。
ALPはAdaptive Lossless floating-Pointの略で、double型やfloat型を10進表現へ近づけて整数として符号化し、パターンに合わない値は別方式へ退避する。

Parquetファイルを読むエンジンがALPに対応していなければ、その符号化を使った列を読めない。
公式ALP仕様は、10進数由来のセンサー値や価格を、ALPの利用に向いている例として挙げている。
埋め込み成分など他の浮動小数点列は、実データの例外率と圧縮率によって向き不向きが変わる。
ALPを使うには、書き込み側と読み取り側の両方が対応していなければならない。

同じParquetの週では、parquet.thrift を parquet-java へ取り込む提案も出ている。
今は parquet-java が parquet-format のJARに入ったThrift定義へ依存しており、形式変更をJava側で試すだけでも形式定義JARのリリース待ちになる。
単一の正本は定義のずれを防ぐ一方、Java側のCIとマージは新しい形式定義JARの公開まで進められない。

polaris-toolsの認証モード

Polarisでは、1.7.0 rc0の取り下げと並行して、polaris-tools の認証モードも議論された。
同じ週のrc0の投票では、269個のステージング済みJARのうち44個に META-INF/LICENSE と META-INF/NOTICE が欠けていたため、拘束力のある -1 票が入り、投票はキャンセルされた。

HTTP/SSEで公開するリモート共有MCPで議論に出ている認証モードは、service credentials（サービス資格情報）、caller token forwarding（呼び出し元トークン転送）、OAuth token exchange（OAuthトークン交換）。

構成	トークンの扱い
ローカル単一ユーザー	ユーザー自身のPolarisトークンを使う
リモート共有で、受け取ったトークンがPolaris向け	そのトークンをそのまま転送する（caller token forwarding）
リモート共有で、MCPサーバー向けトークンを受け取る	外部の認可サーバーが別のPolaris向けトークンを発行する（OAuth token exchangeが候補）

リモート共有構成の設計項目は、資格情報の優先順位、トークンやヘッダーの由来、ユーザーとサービス双方の識別方法である。
AIエージェントによる読み取り、権限変更、ディレクトリやカタログ作成を、ユーザーとサービスのどちらの操作として記録するかが問題になる。
MCPのステートレス化はHTTP通信のセッション管理を減らす変更であり、カタログの認証主体はPolaris側で定める。

原典では、リモートMCPの設計項目に、トークンのオーディエンス（対象サービス）、ヘッダーの由来、信頼できるプロキシ、サービスIDが挙げられている。

Arrowのnull許容フラグは観測か契約か

Arrowのnull許容フラグでも、nullable: false が何を保証するかが議論になっている。
struct、list、map のような複合型で nullable: false が付いているとき、それがフィールド自体だけを指すのか、子要素のnullまで含むのかは、仕様上どちらとも取れる。

読み方	意味	下流の扱い
観測	このバッチにはnullがない	一時的な情報として扱う
契約	今後このストリームに流れるデータでnullは来ない	オプティマイザや読み取り側がnullチェックを省く根拠になる

Arrow形式では親配列と子配列が別々のvalidity bitmap（有効性ビットマップ）を持ち、親フィールドの nullable: false は子要素のnull可否まで決めない。

Iceberg V4のequality delete非推奨

Parquet ALP符号化の投票

polaris-toolsの認証モード

Arrowのnull許容フラグは観測か契約か

参考