――　データシステムを提供するベンダー各社は、なぜIcebergを扱えるように機能の追加や拡充を急いでいるのですか。

ファーマー氏　理由の一つは、データを効率よく管理するためのテーブルフォーマットを巡る規格争いが、ほぼ決着しているためだ。現状ではIcebergが事実上の標準になりつつある。そうなれば、ベンダーとして業界の大きなトレンドから外れるわけにはいかない。自社のシステムに組み込まざるを得ない。

　最も大きな理由は、技術の買い手である企業から候補外にされるのを防ぐことだ。欧米のIT調達プロセスでは、RFP（提案依頼書）の要件を完全に満たしているかどうかが厳格に問われる。要件にIcebergが含まれていれば、当然それを扱えるようにする必要がある。ベンダーの規模にかかわらず、ある技術がこれほど一般化してしまえば、取り入れざるを得ない。例えば、SAPはDremioを買収した。SAPはIceberg向けに作られたエンジンを持っていなかったため、外部から調達しなければならなかった。

　顧客から排除されたくないという否定的な見方がある一方で、肯定的な見方をすれば、Icebergを中心に構築されたデータレイクハウスが、今やAIエージェントのインフラになっていることが挙げられる。自律型AIの課題は、AIエージェントを支えるデータ構造が組織内で断片化し、孤立している点にある。Icebergを活用したデータレイクハウスは、そうしたばらばらの構造の上にAIエージェントを構築するのではなく、全てを1つに集約し、AIエージェントが稼働するための極めて中立的なシステム構成を提供する。

――　データ分野のリーダーやチームにとって、現時点で「従来のデータレイク」と呼ばれる保管庫では実現できず、Icebergであれば実現できる機能とは何ですか。

ファーマー氏　従来のデータレイクは、実質的にはオブジェクトストア（大容量の非構造化データを保存するストレージ）内のファイル群に過ぎない。特に最近では、「Hive形式」と呼ばれる伝統的なディレクトリ構造を持つオブジェクトストア内のParquetファイル（列ごとにデータを保存して処理を高速化する形式）が一般的だ。Icebergは、その上に「データについてのデータ」であるメタデータ層を追加する。単なるファイル保管庫ではなく、メタデータ層に加えて一種のトランザクション層も備えている。例えば、データの正確性と安全性を保証する「ACIDトランザクション」をある程度まで実行できる。

　Icebergはスキーマ（データの設計図）を後から安全に変更する機能も可能にする。そのため、列の追加や名前の変更、あるいは列の型変更をしても、データファイルを書き直す手間がかからない。データを一定のルールで分割して処理を速くするパーティションについても同様の機能を備えており、既存のデータを書き直すことなく分割ルールを変更できる。オブジェクトストア内に緩い構造でファイルを置いただけの、いわゆる単調なデータレイクのレベルを超える機能を備えている。

――　なぜDelta LakeやApache Hudiではなく、あるいはこの3つが横並びの競合として存続するのではなく、Icebergが標準のテーブルフォーマットになったのでしょうか。

ファーマー氏　公平に見れば、Delta Lakeを導入しているシステムも一定数存在する。データ分析ツール「Microsoft Fabric」では標準フォーマットとして組み込まれている。Delta Lakeが消え去ったわけではないが、よりオープンな業界標準としてはIcebergが優勢になっているという見方だ。

　その理由の一つは管理体制にある。IcebergはApache Software Foundationのプロジェクトだが、Delta LakeはDatabricksから生まれた。オープンソースであるとはいえ、単一のITベンダーに支配されている印象を与える。特定の技術に縛られることをユーザー企業は極度に嫌う傾向があるため、そこが懸念点になる。データカタログ層を見ると、Icebergは標準的な通信ルールに基づく「RESTカタログAPI」を備えているのに対し、Delta LakeはDatabricksの「Unity Catalog」を通じて管理される。これは強力な仕組みだが、特定のベンダーに依存している側面がある。

　Apache Hudiに関しては、大容量かつ高頻度のストリーミングや、変更データの抽出など、特定のシナリオにおいて非常に優れている。これを実現する優れたレコード単位のインデックス作成機能や、ストリーミングシナリオにおいて極めて高いパフォーマンスでデータを最新の状態に保つマージオンリード（変更差分だけを素早く保存し、読み込み時に結合する仕組み）を備えている。

　これだけ聞くと状況が混在しているように思えるが、全体的なトレンドとしてはそうではない。Icebergが標準的な地位を確立しつつある。

――　「Apache XTable」は、これら3つのテーブルフォーマット間の相互運用を実現する開発段階の技術です。Delta Lakeも、IcebergやApache Hudiでテーブルを読み取れるようにする「Universal Format」（UniForm）という機能を備えています。複数のテーブルフォーマットが混在するシステム構成が今後増えると考えていますか。

ファーマー氏　今後は1つに集約していくと予測している。Icebergのバージョン3は、データ層の集約において非常に優れた成果を上げた。例えば、行レベルのデータリネージ（データの来歴管理）や、半構造化データの保存に不可欠なVariantデータ型などの機能を備えている。Databricksも、最終的にはDelta LakeとIcebergが同じメタデータを使用し、テーブルを共有するようになると明確に述べている。

　確かに、UniFormやXTableのような橋渡しとなる技術は存在するし、Apache XTableにはMicrosoftやGoogleといった強力な後ろ盾がある。しかし、3つの異なるフォーマットが分立したまま互いに連携し続けるのではなく、メタデータやテーブルを共有する方向へ進むだろう。Icebergが、異なるシステム間で誰もが標準的に読み書きできる「データの共通言語」になるのだ。

――　Icebergの導入を検討しているデータチームが把握しておくべき制限や課題はありますか。例えば、移行にかかる手間や費用はどうでしょうか。

ファーマー氏　移行の手間や費用は発生する。P（ペタ）B規模の移行となれば、それは巨大なプロジェクトになる。パーティショニングやファイルパスの問題など、移行作業を煩雑にする要因もある。そうした煩雑さがなくても、単に大規模な作業になる可能性がある。

　より深刻な問題は保守管理だと考えている。Icebergは、変更のたびに新しいメタデータとデータファイルを書き込む仕組みだ。これによって、時間がたつにつれてパフォーマンスが低下する恐れがある。昔のPCでHDDの断片化を解消するためにデフラグ作業が必要だった時代と少し似た状況に陥る。非常に小さなファイルが増殖するため、計画的にその保守をしなければならない。ファイルのコンパクション（最適化して1つにまとめる処理）や、取得したデータスナップショットの期限切れ処理を実行し、全てを整理する必要がある。

　そのため、Icebergの運用計画には保守作業を組み込んでおく必要がある。システムのパフォーマンスが低下し始めてから、初めてその必要性に気付く企業が目立つ。いずれこの問題が解決されることは間違いない。しかし2026年時点では、Delta Lakeにはない保守の手間がIcebergには存在する。こうした保守の課題に加えて、既存のDelta Lake運用が安定していることや、Unity Catalogの強固な利便性を手放したくないという背景もあり、Delta LakeからIcebergへの全面的な移行が急速には進んでいないと推測する。

――　Icebergの導入や運用に関して、データチームへの追加のアドバイスやベストプラクティスはありますか。

ファーマー氏　フォーマットについて質問してくる人々には、決めるべきことは1つではないと助言している。テーブルフォーマットの選択があり、カタログ、クエリエンジン、実施すべきガバナンスと保守の選択がある。Icebergを選択するのはごく自然なことだ。しかし、特にカタログについては、一度決めると後から変更するのが困難になるため、失敗が許されない難しい決断になる。

　IcebergのRESTカタログ仕様は非常に移植性が高く、優れたAPIを備えている。Iceberg専用に構築されたオープンソースのデータカタログである「Apache Polaris」を利用してもよい。「Unity Catalog」「Snowflake Horizon Catalog」「Dremio Open Catalog」「AWS Glue」「Hive Metastore」など、その他のカタログを選択することもできる。これは非常に重要な決断だ。カタログの選択によって、Icebergが企業のシステム構成にどのように組み込まれるかが決まるからだ。