【ITニュース解説】Apache Iceberg dev list digest (Sept 8–12, 2025)

Apache Icebergは、大量のデータを効率的に管理するためのオープンソースのテーブルフォーマットであり、特にデータレイクハウスと呼ばれる新しいデータ基盤の構築において中心的な役割を担っている。その開発コミュニティは非常に活発で、常に進化を続けている。この期間に、コミュニティでは多岐にわたる議論が交わされ、多くの進展があった。

まず、Apache Iceberg 1.10.0のリリースが大きなニュースとなった。リリース候補版であるRC5の投票が行われ、開発者からの多数の賛成票を得て無事に承認された。この新バージョンには、データ管理の効率を高める重要な機能が多数含まれている。特に注目すべきは、新しいV3フォーマットへの対応だ。これは、より柔軟で高性能なデータ処理を可能にするための基盤を提供する。また、ベクタライズド読み込みという、一度に多くのデータをまとめて効率的に処理する技術が改善され、データ読み込みの速度が向上した。さらに、RESTカタログエンドポイントという新しい機能が追加されたことで、異なるシステム間でのデータ連携がよりスムーズになることが期待される。これはIcebergを様々な環境で利用しやすくするための重要な一歩と言える。

一方で、既存のシステムを新しいバージョンに移行する際の課題についても活発な議論があった。特に古いV1テーブルをV3テーブルにアップグレードする際に、過去のマニフェストと呼ばれるデータ管理情報に「行数カウント」という情報が不足しているケースがあることが報告された。この情報がない状態でスナップショット（ある時点のテーブルの状態を記録したもの）を作成しようとすると、プログラムが予期せぬエラー（NullPointerException）を起こしてしまう問題だ。これに対して開発者たちは、単にエラーを出すのではなく、不足している行数カウントが検出された場合に、より明確なエラーメッセージを表示し、メタデータ（データに関するデータ）を修正する機能の完成を急ぐべきだと提案した。この問題は非常に古いテーブルに限定されるため、多くのユーザーには影響がないが、システムの堅牢性を高めるための重要な改善点である。

機能改善の議論は、API（アプリケーション・プログラミング・インターフェース）の設計にも及んだ。新しいFileFormat APIの設計については、どのようにデータを書き込むためのインターフェースを設計すべきか、意見が交換された。特に、特定の形式に特化した書き込み機能を持つべきか、あるいは共通のインターフェースで特殊なケース（例えば、特定のデータを削除するためのファイル）を扱うべきか、という点が議論の中心だった。これは、開発者がより簡単にIcebergを利用し、拡張できるようにするための重要な検討事項である。

また、データ型に関する進化も議題に上がった。特にDECIMAL型（小数点以下の精度を持つ数値）の扱いの拡張が提案された。これは、データベースの世界で標準となっているSQL:2011という規格に準拠し、データファイルの内容を書き換えずに、DECIMAL型の精度やスケール（小数点以下の桁数）を変更できるようにしようというものだ。この変更が実現すれば、スキーマの変更がより柔軟に行えるようになり、データの管理がさらに容易になる。同時に、REST APIの仕様も強化され、テーブル間の参照関係をクライアントが確認できるようにする機能や、RESTカタログモデルをPythonパッケージとして独立させることで、他のアプリケーションが公式のモデルを直接利用できるようにする提案もされた。

さらに、一部の古い機能の非推奨化も進められた。特に、Iceberg V2で導入された「行データを含む位置削除」という機能は、ほとんど利用されていないことが指摘され、非推奨とすることが投票によって決定された。これは、Iceberg 2.0のリリース時に書き込みサポートを削除し、読み込みサポートは後方互換性のために残す方針だ。プロジェクトの複雑さを減らし、より利用頻度の高い機能に開発リソースを集中させるための賢明な判断と言える。

開発体制やツールの改善についても話し合いが行われた。Iceberg-RustというRust言語でIcebergを扱うためのプロジェクトでは、PyIceberg（Python言語版）の設定を参考にして、GitHub上で古くなった（stale）Issue（課題）を自動的にマークし、クローズする仕組みを導入することが提案された。これは、プロジェクトの健全性を保ち、開発者の負担を軽減するための取り組みだ。また、PyIcebergにおける外部ライブラリへの依存関係についても懸念が示された。PyIcebergがpandasやpolarsといった他のデータ処理ライブラリにオプションで依存していることで、これらのライブラリのバージョン競合が発生し、ユーザーが困るケースがあるという問題だ。開発者たちは、PyIcebergが便利なレイヤーであるべきという設計思想は維持しつつも、バージョン競合を避けるために、外部ライブラリ側でIcebergとの統合を実装すべきではないか、という議論を行った。

セキュリティ面では、Iceberg REST APIにおけるきめ細かなアクセス制御（FGAC）のOpenAPIに関する合意が形成された。これは、データのアクセス権限をより詳細に設定するための仕組みだ。Icebergの式（expressions）とユーザー定義関数（UDF）のみが、アクセス保護のための指示を取得する唯一のメカニズムとなることが決定された。これにより、アクセス制御のポリシー（規則）の定義と、そのポリシーを実際に適用する仕組みが明確に分離され、セキュリティの管理がしやすくなる。

最後に、Icebergエコシステムの拡張に向けた動きも紹介された。Amazon S3 Analytics Acceleratorとの統合が進められており、これによりS3上に保存された大量のデータをIcebergを使ってより高速に分析できるようになる見込みだ。その他にも、IcebergのメタデータAPIの改善提案や、開発者コミュニティの交流を深めるためのミートアップの開催が告知された。

これらの議論は、Apache Icebergが単なるデータフォーマットにとどまらず、データレイクハウスの主要な基盤として、機能性、安定性、セキュリティ、そして開発者体験の全てにおいて進化を追求していることを示している。新しいバージョンのリリース、古い問題への対処、将来の機能拡張、そしてコミュニティの活発な交流は、Icebergプロジェクトが今後もデータ管理の最前線を走り続けることを予感させる。