Databricks の Anoop Johnson氏 と Ryan Blue氏による Delta + Iceberg, Better Together のセッションは、Delta Lake と Apache Iceberg のコンテンツメタデータをより近づけるための設計意図と技術的な要点を示した。現代のデータレイクハウスでは異なるテーブルフォーマット間の連携と性能最適化が重要課題であり、今回の議論はその一助になりうるアプローチを提示している。
データレイクハウスにおける既存の課題
Delta と Iceberg は別々に進化してきたため、メタデータ表現が異なることが運用や移行の障壁になっている。たとえば、フォーマット間の差を吸収するためにセマンティックレイヤのような変換レイヤが使われるが、これはオーバーヘッドや遅延を生む。コンテンツメタデータの表現差は、効率的な共有や移行を難しくしている（Delta のオブジェクトメタデータに関する参照は こちら）。
※サイトの更新により、リンクが無効になる可能性があります。
― エーピーコミュニケーションズ GDAI部 Lakehouse
統合への道：Iceberg v4 とアーキテクチャ変革
DeltaとIcebergメタデータ統合
Anoop氏 と Ryan氏 は、共通のコンテンツメタデータ表現を設計することで、両フォーマットが同一のオンディスク構造を参照できるようにする可能性を示した。データファイルのレイアウトやカタログはそれぞれ維持しつつ、コンテンツメタデータ層を共有することで相互運用性を高めるという考え方だ。セッションでは、Iceberg v4 で導入される「adaptive metadata tree」がその基盤になると説明された（Iceberg の次世代対応に関する解説は こちら）。
技術的詳細：統合メタデータ構造のメカニズム
Iceberg v4 の adaptive metadata tree
adaptive metadata tree は、Delta の単一ファイルコミットの利点を取り入れつつ、Iceberg の柔軟性を保つ設計だ。ルートマニフェストファイルを中心に更新を行うことでコミット時のオーバーヘッドを抑え、データファイルと削除情報を共置して従来の二相プランニングを減らす。テーブルが大規模化した場合はリーフマニフェストを生成してレイテンシの観点を制御する。
相対パスによるテーブルロケーション
カタログがベースロケーションを提供し、個々のデータファイルは相対パスで参照する方式により、クローンやバックアップ、リカバリが簡素化される。
列指向メタデータ表現と列単位の更新
カラム統計とParquetマニフェスト
従来のマップベース統計から Parquet 形式の列指向メタデータへ移行することで、スキップ判定が容易になりクエリ性能が向上する。さらに、ファイル全体を書き換えずに特定列だけを上書き・追加できる機能は、特徴量の追加やスコア更新などに有効だ。
インデックス機能の強化
インデックス統合フレームワーク
インデックス追加により、行検索やマージクエリ、ストリーミング処理の性能改善が期待できる（関連概念は こちら）。
Delta 側への影響と運用上の期待
セッションでは、Delta 側で Iceberg v4 相当のメタデータツリーを利用する案が示され、Delta の今後のリリースで検討が進められている旨が語られた。Anoop氏 と Ryan氏 は、このアプローチによりチェックポイント作成の負荷やログ再生コストが低減され、ポイントクエリの応答性や読み書き性能が改善される可能性があると説明している（ストリーミングのチェックポイントに関する解説は こちら）。具体的には、変更規模に応じて「マニフェストコミット」と「ログ追記」を使い分けることで、ログサイズの増大を抑えつつ効率的な更新が可能になるという見立てだ（カタログコミットに関する実装面は こちら）。
まとめと今後の展望
Anoop氏 と Ryan氏 が示した設計は、Delta と Iceberg の間でメタデータ互換性を高めるための実装案であり、相互運用性と性能の改善につながる一歩といえる。これによりユーザーは両フォーマットの利点をより柔軟に活用できる可能性があるが、具体的な採用タイミングや運用上の影響は今後の実装と検証に依存する。
