2026 年、テーブルフォーマット戦争の決着点
- 年頃の「Iceberg vs Delta vs Hudi」はまだ技術的な優劣で揺れていたが、2026 年に入ってからの業界の動きは明確に政治的・エコシステム的なフェーズへ移った。まず 2024 年末の Databricks による Tabular 買収が象徴的で、Iceberg と Delta Lake の「統合ロードマップ」がようやく絵空事ではなくなった。続いて Snowflake が Iceberg 書き込みを 2025 年に GA し、AWS は S3 Tables という Iceberg マネージドサービスを主力に据え、Databricks は Unity Catalog を OSS 化して Iceberg REST カタログとの互換を宣言した。
結論を先に書くと、新規プロジェクトで迷うなら Iceberg 1.7 を選ぶのが 2026 年 4 月時点の合理解である。Delta Lake 3.3 は Databricks 環境で圧倒的に最適化されているため既存 Databricks 顧客は継続が合理的だが、「複数クエリエンジン・複数クラウド」を跨ぐ要件では Iceberg の REST カタログ経由の多エンジン対応が他を寄せ付けない。Hudi 1.0 は CDC／ストリーミング主体のワークロードで依然として有力な選択肢だが、バッチ中心のデータウェアハウス用途では相対的にニッチになった。
三形式の 2026 年アーキテクチャ差分
まず設計哲学の違いを整理する。
Apache Iceberg 1.7 は snapshot-based の不変マニフェストツリーと、メタデータファイルの階層構造が中核にある。1.7 で導入された V3 仕様では、row-level lineage（各行がどの書き込み操作で生まれたかを追える）、variant 型（半構造化 JSON のネイティブサポート）、deletion vectors（Delta 由来の仕組みを取り込んだもの）が標準化された。これで Delta Lake との機能ギャップはほぼ消えた。
Delta Lake 3.3 は UniForm の成熟が最大の変化点だ。Delta として書き込んだテーブルを、同じストレージ上で Iceberg メタデータとしても読めるようにするこの仕組みは、2025 年の 3.2 時点ではまだ書き込みパフォーマンスが劣化するケースが多かったが、3.3 の「コミット時同時生成」方式で実用レベルになった。Deletion vectors、Liquid Clustering、predictive optimization が組み合わさると、TPC-DS 10TB で Iceberg 1.7 に対して 10～15% 速い。ただしこれは Databricks Runtime 上限定で、OSS Spark 4.0 + Delta では差は 3～5% 程度に縮む。
Apache Hudi 1.0 は Merge-on-Read (MoR) と Copy-on-Write (CoW) の二モードの設計思想がそもそも違う。1.0 で最大のアップデートは「Timeline Server の非中央化」と「Table APIs v2」で、大規模 streaming upsert のスループットが前バージョン比で 2 倍以上になった。CDC ワークロードでの性能は依然トップクラスで、特に 1 秒以内のデータ鮮度を要求するケース（金融決済ログ、IoT テレメトリ）では Iceberg／Delta より明確に速い。
Snowflake Iceberg 書き込みの衝撃
- 年の業界を最も動かしたのは、Snowflake が Iceberg テーブルへの書き込みを GA した件である。これまで Snowflake は内部フォーマット（micro-partition）がブラックボックスで、データを外に出すには UNLOAD しかなかったが、Iceberg テーブル（Snowflake-managed Iceberg、または External Iceberg）に書き込めるようになったことで「Snowflake で ETL したデータを Databricks／Trino／DuckDB でそのまま読む」という構成が現実的になった。
KGA の製造業顧客では、基幹 SAP データの取り込みを Snowflake で処理し、ML 特徴量ストアを Databricks Mosaic で、ダッシュボード系クエリを Trino で分散する構成を 2026 Q1 に本番投入した。Iceberg REST カタログ（Polaris または Snowflake Open Catalog）を単一のメタデータソースとして、それぞれのエンジンがそれぞれ得意なワークロードを担当する「ポリグロット・データプラットフォーム」が現実解になっている。
ただし落とし穴もある。Snowflake-managed Iceberg は定期的に Snowflake 側で compaction／optimization が走るため、外部エンジンからの書き込み中にファイル配置が変わる。Trino／Spark 側で書き込みを行う場合は External Iceberg（Snowflake は読み取り専用）を選ぶべきで、両方から書き込みたい場合は Iceberg REST カタログをハブにした慎重な設計が要る。
Databricks Unity Catalog オープン化と S3 Tables
Databricks は 2025 年に Unity Catalog を OSS 化し、Iceberg REST カタログ仕様への準拠を宣言した。これにより Delta テーブルを Unity Catalog 経由で Iceberg クライアントから読めるようになった。Unity Catalog OSS 版は Hive Metastore の正当な後継と言っていい出来で、権限管理、data lineage、audit log が一体化している点が実運用で効く。
AWS S3 Tables は 2024 年末に発表され、2025 年を通じてリージョン展開された。これは S3 バケットに Iceberg テーブル向けの最適化（自動 compaction、snapshot expiration、orphan file cleanup）を組み込んだ専用バケットタイプで、Lake Formation と連携した列レベルのアクセス制御までマネージドで提供する。料金モデルは通常 S3 の 2 倍弱だが、compaction 省力化と Athena／EMR／Redshift Spectrum から素直に読めるメリットは大きい。
この 3 者（Snowflake Polaris、Databricks Unity Catalog、AWS S3 Tables）がいずれも Iceberg REST カタログ仕様を中心に据えた結果、2026 年のデファクトカタログ API は事実上 Iceberg REST に一本化された。Hive Metastore は依然として稼働するが、新規プロジェクトで選ぶ理由は減った。
クエリエンジンとの相性マトリクス
KGA の検証環境で、TPC-DS 1TB・10TB の両方をテーブルフォーマット × クエリエンジンの組で回した結果を要約する。
Trino 465: Iceberg との組み合わせが最も成熟している。dynamic filtering、materialized view、cost-based optimizer のいずれも Iceberg メタデータを深く活用し、複雑 join を含む Q72、Q78 系で Delta 比 8～12% 速い。Hudi もサポートされるが、MoR テーブルでの読み出しは Iceberg／Delta より明確に遅い。
Apache Spark 4.0: 3 形式すべてを書き込めるが、Delta が最適化されている。特に Photon（Databricks 独自）を使わない OSS Spark では、Spark 4.0 の Columnar Processing と Adaptive Query Execution v2 が Iceberg／Delta の両方にほぼ同等の恩恵をもたらす。Hudi は書き込み側が強く、streaming sink として使うのが最適。
DuckDB 1.2: Iceberg の読み取りサポートが本格化し、Iceberg REST カタログ経由で S3 のテーブルを直接クエリできるようになった。10GB までのアドホック分析、特にノートブック上での探索用途で絶大な威力を発揮する。Delta の読み取りも可能だが、deletion vectors サポートが完全ではなくバージョン 1.3 を待つ必要がある。
StarRocks 3.4: 近年最も勢いのある Trino 代替で、Iceberg 外部テーブルへのクエリ性能がベンチマークによっては Trino 465 を上回る。特に star schema 型の BI ワークロードで data cache を効かせた場合、Q1～Q10 のような集計支配クエリで 1.5～2 倍速い。日本国内でも LINE ヤフー、DeNA、サイバーエージェント等の採用事例が増えた。
どれを選ぶか: 2026 年版意思決定ツリー
新規プロジェクトで考えるなら次の順序で絞る。
- 既に Databricks 主体で、複数クラウドに出る予定がない: Delta Lake 3.3 を選ぶ。Photon／Liquid Clustering／Predictive Optimization の恩恵が他形式では得られない。
- Snowflake を中心に、外部ツールからも読み書きしたい: Iceberg（Snowflake-managed または External）を選ぶ。Snowflake Open Catalog／Polaris が統一メタデータ層。
- AWS 中心、複数エンジンから読みたい: S3 Tables + Iceberg を選ぶ。マネージドの compaction は運用工数を大幅に削る。
- CDC／streaming upsert が主でデータ鮮度 1 分未満を要求: Hudi 1.0 を選ぶ。Flink／Kafka との統合は依然最強。
- マルチクラウド、複数エンジン、ベンダーロックイン回避: Iceberg + Unity Catalog OSS または Polaris を選ぶ。
KGA の推奨は、既存 Databricks 顧客以外のグリーンフィールド案件であればほぼ例外なく Iceberg である。理由は単純で、どのクエリエンジン、どのクラウド、どのカタログサービスでも読める選択肢が 2026 年時点で Iceberg だけだからだ。データ基盤は 5 年、10 年使う資産であり、その間にベンダー勢力図が再度塗り替わっても、Iceberg を選んでおけば移行コストは最小化できる。
2026 年後半への展望
Iceberg V4 仕様の議論が既に始まっており、geospatial 型のネイティブサポート、vectors 型（埋め込み検索用）、更に強化された row-level lineage が提案されている。Delta Lake はさらに UniForm を双方向化し、Iceberg 書き込みの GA へ向かっている。Hudi は Table APIs v2 の安定化とカタログ機能の強化で Iceberg への対抗軸を保とうとしている。
KGA は顧客案件でのテーブルフォーマット選定を「技術的最適」と「政治的安全性」の両軸で支援している。技術の優劣だけではなく、自社のクラウド戦略、既存ベンダー契約、エンジニア採用市場まで見た総合判断が、長期的には TCO を大きく左右する。