Apache Iceberg・Delta Lake・Hudiとは？オープンテーブルフォーマット比較

オープンテーブルフォーマットとは何か

オープンテーブルフォーマットとは、データレイク上のParquetファイルに対してDWH相当の機能(ACID・タイムトラベル・スキーマ進化・パーティション管理)を付与するメタデータ管理レイヤーです。S3やGCSなどのオブジェクトストレージをベースに、DWH(BigQuery・Snowflake等)に依存せずエンタープライズ級のデータ管理を実現します。

データレイクの弱点は「生データを蓄積できるが、更新・削除・トランザクションが苦手」な点でした。オープンテーブルフォーマットはこの弱点を補い、データレイクハウス(A-04)を実現する中核技術となっています。代表的な実装がDelta Lake・Apache Iceberg・Apache Hudiの3つで、それぞれ異なる発祥と強みを持ちます。

Delta Lake

Delta LakeはDatabricksが2019年に開発し、2023年にLinux Foundation傘下でOSS化されたフォーマットです。Apache Sparkとの深い統合が最大の強みで、Databricks環境では追加設定なしで利用できます。

主な機能: ACIDトランザクション・タイムトラベル(DESCRIBE HISTORY/RESTORE)・スキーマ強制・Z-Orderクラスタリング(クエリ高速化)。DatabricksのManaged Delta TablesはVACUUM・OPTIMIZE を自動実行するフル管理型サービスとして提供されています。

Delta Lakeテーブル作成SQL

CREATE TABLE orders (
    order_id    BIGINT,
    customer_id INT,
    amount      DECIMAL(10,2),
    created_at  TIMESTAMP
)
USING DELTA
LOCATION 's3://my-bucket/delta/orders';

-- タイムトラベル: 1時間前のスナップショットを参照
SELECT * FROM orders TIMESTAMP AS OF (now() - INTERVAL 1 HOUR);

Databricks環境でのZero-ETL的なワークロードや、Spark Streamingでのリアルタイム書き込みに強みを発揮します。一方、Spark以外のエンジン(Trino・Flink等)からの読み取りは2023年以降改善されていますが、Icebergと比べると互換性がやや劣ります。

Apache Iceberg

Apache IcebergはNetflixが2018年に開発し、Apache Software Foundationに寄贈されたフォーマットです。「エンジン非依存」を設計原則とし、Spark・Flink・Trino・Hive・DuckDB等の多くのクエリエンジンがIcebergをネイティブ読み取り可能です。

特筆すべき機能はHidden Partitioning(隠れたパーティショニング)とPartition Evolution(パーティション進化)です。ユーザーはパーティションキーを意識せずクエリを書け、後からパーティション戦略を変更してもクエリを書き直す必要がありません。スキーマ進化も型変換・列の並び替え・列削除を含む豊富な操作をサポートします。

Icebergテーブル作成SQL

CREATE TABLE catalog.orders (
    order_id    BIGINT,
    customer_id INT,
    amount      DECIMAL(10,2),
    created_at  TIMESTAMP
)
USING iceberg
PARTITIONED BY (days(created_at))
LOCATION 's3://my-bucket/iceberg/orders';

-- スキーマ進化: カラム追加
ALTER TABLE catalog.orders ADD COLUMN shipping_fee DECIMAL(10,2);

2026年時点では、SnowflakeのIcebergネイティブ対応・BigQueryのIceberg読み取り・AWS S3 TablesのIceberg採用など、主要クラウドベンダーが一斉にIcebergを標準フォーマットとして採用しており、業界標準化が急速に進んでいます。

Apache Hudi

Apache HudiはUberが2016年に開発し、2019年にApacheに寄贈されたフォーマットです。「大規模な増分データ処理」を設計目的とし、CDC的なUPSERT/DELETE操作に最適化されています。

2つのテーブルタイプが特徴です。Copy-on-Write(CoW)は書き込み時にParquetファイルを書き直し、読み取りが高速。Merge-on-Read(MoR)は書き込みを差分ログに記録し読み取り時にマージするため書き込みが高速。ユースケースに応じて選択します。

HudiテーブルへのUPSERT設定例(PySpark)

hudi_options = {
    'hoodie.table.name': 'orders',
    'hoodie.datasource.write.recordkey.field': 'order_id',
    'hoodie.datasource.write.precombine.field': 'updated_at',
    'hoodie.datasource.write.operation': 'upsert',
    'hoodie.datasource.write.table.type': 'COPY_ON_WRITE',
}
orders_df.write.format('hudi').options(**hudi_options).mode('append').save('s3://my-bucket/hudi/orders')

3フォーマット徹底比較

エコシステム関係図

クエリエンジン層
┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐
│  Spark   │  │  Flink   │  │  Trino   │  │  Hive    │
└────┬─────┘  └────┬─────┘  └────┬─────┘  └────┬─────┘
     └──────────────┴─────────────┴──────────────┘
                           │ 対応状況が異なる
     ┌─────────────────────┼────────────────────┐
     ▼                     ▼                    ▼
┌─────────┐          ┌──────────┐          ┌──────────┐
│  Delta  │          │ Iceberg  │          │   Hudi   │
│  Lake   │          │(最広互換) │          │(増分特化) │
└─────────┘          └──────────┘          └──────────┘
     └─────────────────────┴────────────────────┘
                           │
               ┌───────────▼───────────┐
               │  オブジェクトストレージ  │
               │  (S3 / GCS / ADLS)    │
               └───────────────────────┘

機能比較表

比較軸	Delta Lake	Apache Iceberg	Apache Hudi
開発元	Databricks(2019→Linux Foundation)	Netflix→Apache(2018)	Uber→Apache(2019)
ACIDトランザクション	✅	✅	✅
タイムトラベル	✅	✅	✅
スキーマ進化	✅	✅(最も豊富)	✅
パーティション進化	△(手動変更)	✅(Hidden Partitioning)	△
エンジン互換性	中(Spark中心、改善中)	高(Spark/Flink/Trino/Hive等)	中(Spark中心)
増分UPSEREスループット	中	中	高(MoR最適)
コミュニティ規模	大	大(急成長)	中
2026年トレンド	Iceberg互換強化中	業界標準化が進む	CDC特化用途で継続採用

どれを選ぶべきか

2026年時点での選定指針を示します。SnowflakeのIceberg Tables・AWS S3 TablesのIceberg採用・BigQueryのIceberg対応など、主要クラウドが一斉にIcebergを採用しており、新規構築であれば特段の理由がない限りIcebergを選択することを推奨します。

選定判断マトリクス

ケース	推奨	理由
DatabricksメインのSpark環境	Delta Lake	Databricksとの深い統合、Managed Delta Tableが利用可能
マルチエンジン環境(Trino/Flink/Spark混在)	Iceberg	エンジン非依存性が最高、Trino/Flink/Hiveが公式対応
リアルタイム増分UPSERTが主体	Hudi(MoR)	CDC的な書き込みパターンに最適化
Snowflake/BigQueryとの連携が必要	Iceberg	両サービスがIcebergネイティブ読み取りに対応
新規レイクハウス構築(2026年時点)	Iceberg	業界標準化が進み、将来の互換性リスクが最小

既存DatabricksユーザーがDelta Lakeからの移行を急ぐ必要はありません。DatabricksはUniFormという機能でDelta LakeファイルをIceberg互換メタデータで読み取れるようにしており、「今はDelta Lake、将来Icebergに移行」という段階的な対応が可能です。

まとめ

オープンテーブルフォーマットはデータレイクハウスの中核技術として不可欠な存在です。2026年時点での選択指針をまとめます。

• 3フォーマットすべてがACID・タイムトラベル・スキーマ進化をサポート
• Icebergが業界標準化の流れ——マルチエンジン・マルチクラウドで最も互換性が高い
• Databricks環境ではDelta LakeがファーストチョイスでIceberg互換(UniForm)も提供
• CDC的なリアルタイム増分UPSERTが最重要要件ならHudiが強み
• 既存Parquetファイルはいずれのフォーマットでも既存データを登録する移行パスあり

関連記事: データレイクハウスとは(A-04) / CDCとは(A-19)

よくある質問(FAQ)

Q. オープンテーブルフォーマットは必要ですか?

A. データレイクハウスを構築する場合は必須です。DWH(BigQuery/Snowflake)を単体で使う場合は不要で、DWH側がテーブル管理を担います。S3等のオブジェクトストレージにデータを持ちつつ、複数エンジンでACIDトランザクションやタイムトラベルを使いたい場合に導入を検討してください。

Q. IcebergとDelta Lakeのどちらが主流ですか?

A. 2026年時点ではIcebergがエンジン非依存性で業界標準化が進んでいます。DatabricksもIceberg互換(UniForm)を強化しており、SnowflakeはIcebergネイティブ対応しています。新規構築ではIceberg、既存Databricks環境ではDelta Lakeが依然として主流です。

Q. 既存のParquetファイルからの移行は可能ですか?

A. はい。いずれのフォーマットもParquetをベースストレージとして使うため、既存のParquetファイルをテーブルとして登録する移行パスが用意されています。ただし、既存ファイルの書き直しが必要なケースもあり、データ量によっては初期ロードに時間がかかります。