Apache Icebergとレイクハウス — テーブルフォーマット戦争の現在地

オブジェクトストレージ上のテーブルフォーマットは、この2年でApache Icebergへの収斂が決定的になりました。AWS S3 Tables、Snowflake Polaris、Databricksによるイニシアチブ買収、そしてv3仕様。海外で先に起きた「フォーマット戦争の決着」を、日本のエンタープライズのデータ基盤にどう翻訳すべきか整理します。

01「テーブルフォーマット」とは何を指すのか

データレイクの実務でここ数年繰り返し出てくる「テーブルフォーマット」という言葉は、ファイルフォーマット（ParquetやORC）とは別のレイヤーを指します。S3のようなオブジェクトストレージにParquetファイルを並べただけでは、ACIDトランザクション、スキーマ変更、タイムトラベル、効率的なパーティション運用は成立しません。テーブルフォーマットは、大量のデータファイル群の上に「メタデータの層」を重ね、それらを一つの論理テーブルとして扱えるようにする仕様です。

代表格が Apache Iceberg、Databricks系の Delta Lake、そして Apache Hudi の3つです。いずれもオブジェクトストレージ上でトランザクション整合性とスキーマ進化を実現しますが、設計思想が異なります。そして2024〜2025年にかけて、業界はこの3つのうち Iceberg を相互運用の標準として選び始めました。本記事では、その「なぜ」を一次情報で追いながら、既存のデータ基盤を持つエンタープライズが何を意識すべきかを整理します。

現場のコツ：テーブルフォーマットの議論を「どのクエリエンジンが速いか」に矮小化しないでください。本質は「同じデータを複数エンジンから安全に共有できるか」という相互運用性の問題です。標準化が進む理由もここにあります。

02Iceberg / Delta / Hudi の設計思想の違い

3フォーマットは表面的には似ていますが、生まれた背景が違います。実務で選定に関わる方向けに、要点を整理します。

Apache Iceberg：Netflix発。「仕様（spec）が製品」という思想で、特定のエンジンに依存しません。メタデータをマニフェスト・マニフェストリスト・メタデータファイルの階層で持ち、パーティション情報をデータのディレクトリ構造ではなくメタデータで管理する（hidden partitioning）のが特徴です。パーティション設計の変更がメタデータ操作だけで済み、既存データの物理的な再配置を要しません。
Delta Lake：Databricks（Spark）発。トランザクションログ（_delta_log）を中心とする設計で、Sparkとの統合が最も深い。Databricksプラットフォーム上での実績が厚いフォーマットです。
Apache Hudi：Uber発。レコード単位のupsert（更新・挿入）と増分処理に強く、取り込み・コンパクション・クラスタリングといった書き込みパスの運用機能を内蔵した「管理システム寄り」の設計です。

大まかに言えば、読み取り主体の分析ワークロードでの相互運用性はIceberg、Spark中心の環境ではDelta、レコード単位の頻繁な更新はHudiが得意、という住み分けでした。しかし2024年以降、この構図は「Icebergを共通語（lingua franca）として、他フォーマットがそこに合わせにいく」方向へ動きます。

図：Icebergはカタログを起点にメタデータを階層的にたどり、統計情報で不要なファイルを読み飛ばす。パーティションはメタデータ側で管理される。

03なぜ業界はIcebergに収斂したのか

標準化を決定づけた出来事が2024年に集中しました。象徴的なのが、Databricksによる Tabular（Icebergの原作者 Ryan Blue らが創業）の買収です。Databricksの公式発表は、DeltaとIcebergという「2大オープンレイクハウスフォーマットの原作者を一つにする」と明言し、短期的にはDelta Lake UniFormでの互換性、長期的には「単一のオープンな相互運用標準への収斂」を目指すと述べています。自社フォーマットDeltaを持つDatabricksが、Icebergのエコシステム到達度を実質的に認めた形です。

もう一つの軸がカタログです。2024年6月、Snowflakeは Polaris Catalog を発表し、IcebergのREST Catalog仕様を実装するベンダー中立のオープンソースカタログとしてApacheに寄贈しました。Apache Polaris は Spark、Flink、Trino、Dremio、StarRocks、Doris など幅広いエンジンとの相互運用を掲げ、AWS・Google Cloud・Microsoft・Confluent・dbt Labs など多数のベンダーが統合・貢献を表明しました。「フォーマットはIceberg、カタログはREST仕様」という共通土台に、競合各社が相乗りする構図が生まれたのです。

現場のコツ：収斂の理由を一言でいえば「顧客がロックインを嫌ったから」です。同じデータをSnowflakeでもDatabricksでもAthenaでも読める状態を顧客が求めた結果、ベンダー側が相互運用性で競わざるを得なくなりました。標準化は理念ではなく市場圧力の産物です。

04AWS S3 Tables — クラウドがIcebergを取り込んだ

クラウド事業者の動きも標準化を後押ししました。決定的だったのが、AWSが2024年12月に発表した Amazon S3 Tables です。これは「Apache Icebergサポートを組み込んだ最初のクラウドオブジェクトストア」と位置づけられ、tabular data専用の新しいバケット種別（table bucket）を導入しました。

公式発表によれば、S3 Tables は自己管理のIcebergテーブルと比べて最大3倍のクエリスループットと最大10倍のトランザクション毎秒（TPS）を実現するとされています。さらに、コンパクション・スナップショット管理・未参照ファイルの削除といった運用タスクをポリシー駆動で自動化する「テーブルメンテナンス」を備えます。これは実務上大きな意味を持ちます。Icebergは放置するとメタデータや小さなファイルが増殖し、コンパクションや古いスナップショットの掃除といった「運用の宿題」が発生するフォーマットです。その運用をマネージド側が引き受ける、という設計です。

S3 Tables は Iceberg REST Catalog API を公開しており、Spark・Trino・Flink・Athena・Redshift に加え、Snowflakeなどサードパーティのエンジンからも同じテーブルを扱えます。「AWSがIcebergをS3の一級市民にした」ことは、フォーマット選定を迷っていたエンタープライズにとって強いシグナルになりました。マルチアカウント環境でのデータ共有設計とも密接に絡むため、統制の観点はマルチアカウント統制もあわせて検討する価値があります。

図：エンジンはカタログ経由でテーブルの現在地を取得し、同一データを共有する。RESTカタログ仕様が「共通のコンセント」の役割を果たす。

05v3仕様が示す「次の一手」

標準が固まると、次は仕様そのものの進化フェーズに入ります。Icebergは format version で仕様を管理しており、v1（初期）、v2（行レベル削除の導入）に続き、v3仕様が2025年にかけて各リリース（v1.8.0以降）へ順次実装されました。v3の主な追加点は実務的に重要です。

Deletion Vectors（削除ベクトル）：従来のpositional deleteファイルを、Puffinファイルに格納する効率的なバイナリ形式へ置き換え。削除の適用が高速化します。
Row Lineage（行系譜）：行IDと最終更新シーケンス番号を行メタデータとして持ち、どのスナップショットで行が変更されたかを追跡可能に。増分処理やCDCの精度が上がります。
新しいデータ型：JSONなど半構造化データ向けの VARIANT 型、地理空間解析向けの GEOMETRY / GEOGRAPHY 型、ナノ秒精度のタイムスタンプ型の追加。

2025年11月には AWSがIceberg V3の削除ベクトルと行系譜のサポートを発表し、クラウド側の実装も追随しています。Databricksも v3を「エコシステムの統一に向けた動き」と位置づけました。v3は、DeltaとIcebergの機能差（特に削除ベクトルやVARIANT型）を埋め、両フォーマットの相互運用をさらに現実的にする布石でもあります。

現場のコツ：v3対応をうたうエンジンでも、実装状況は機能単位でまちまちです。書き込みエンジンと読み取りエンジンの双方が、使いたいv3機能（例：削除ベクトル）に対応しているかを、PoCで必ず突き合わせてください。「Iceberg対応」という一言を鵜呑みにしないのが鉄則です。

06既存データ基盤への影響と移行の勘所

すでにデータレイクやDWHを運用しているエンタープライズにとって、Icebergは「全面刷新」ではなく「相互運用レイヤーの追加」として捉えるのが現実的です。実務上の論点を整理します。

既存Parquetからの移行：多くのエンジンで、既存のParquetデータをコピーせずにIcebergテーブルとして登録する方式（add_files等）が使えます。まずは一部のテーブルをIceberg化し、複数エンジンから読めることを確認するのが低リスクです。
Deltaからの相互運用：Delta Lake UniFormを使えば、DeltaテーブルをIcebergのREST Catalogインターフェース経由で読めます。Databricks環境を残しつつ、他エンジンからの読み取りを開く選択肢があります。
カタログの選定が要：フォーマット以上に、どのカタログ（AWS Glue、S3 Tables、Apache Polaris、Snowflake Open Catalog等）を「正」とするかが運用を左右します。RESTカタログ仕様に準拠しているかを最初に確認してください。
運用（メンテナンス）の設計：コンパクション、スナップショット期限切れ、孤立ファイル削除は避けて通れません。S3 Tablesのようなマネージドに寄せるか、自前でジョブを組むかを早期に決めます。

EMWでは、大手SIerやエンタープライズのAWS基盤構築を数多く支援してきました。データ基盤の相互運用性やアカウントをまたいだ共有設計は、セキュリティ・統制と一体で考える必要があります。具体的な検討は導入事例もご参照ください。

—まとめ

テーブルフォーマット「戦争」は、勝者が一つに絞られたというより、Icebergが相互運用の共通語として選ばれ、DeltaやHudiがそこへ歩み寄る形で決着しつつあります。決め手はベンチマークの速さではなく、「同じデータをどのエンジンからも安全に扱える」という顧客からの市場圧力でした。Databricksの原作者チーム取り込み、SnowflakeのPolaris寄贈、AWS S3 Tables、そしてv3仕様——これらは同じ潮流の別の断面です。

日本のエンタープライズにとっての実務的な含意はシンプルです。新規のデータ基盤ではIcebergとRESTカタログを前提に置き、既存基盤には相互運用レイヤーとして段階的に導入する。フォーマット選定に悩む段階は終わり、論点は「カタログと運用をどう設計するか」に移りました。海外で先に固まったこの構図を、自社の統制要件に合わせて翻訳することが次の一手になります。

—参考（一次情報）

既存のデータレイクをIceberg/レイクハウス構成へ移行する設計や検証でお困りの際は、お問い合わせください。

相談する

← ブログ一覧へ戻る