Apache Iceberg と Delta Lake の比較
はじめに
データレイクハウスアーキテクチャが標準となる中、その中心である「オープンテーブルフォーマット」の選定は大事。中でも、Apache IcebergとDelta Lakeについての違いを整理したのでメモを残します。
なぜテーブルフォーマットが必要だったのか？その背景
従来のHiveデータレイクは、dt=2025-07-08のようなディレクトリ構造でファイルを管理していました。この「ファイルの集まり」には、信頼性、パフォーマンス、更新の難しさといった根深い課題がありました。
テーブルフォーマットは、データファイルとは別に 「テーブルの正確な状態を定義するメタデータ」 を管理するレイヤーです。これにより、単なるファイルの集まりを、信頼性と性能を備えた「テーブル」として扱えるようにしました。IcebergとDelta Lakeは、このメタデータをどう管理するかのアプローチが異なります。
Apache Iceberg：エンジン非依存と長期的な柔軟性
Netflixによって開発され、Apache Software Foundation (ASF) がホストするIcebergは、特定のエンジンに依存しないオープンな仕様を哲学としています。
Icebergの思想：物理レイアウトからの解放
Icebergの核心は、テーブルの 「論理的な定義」と「物理的なファイル配置」を完全に分離した点にあります。テーブルの状態は、ファイルシステムを直接スキャンするのではなく、階層的なメタデータファイル群によって定義されます。
【Icebergの階層的メタデータ構造】
[ Catalog (Hive, Nessie, etc.) ] <-- 現在のメタデータファイルの場所を指す
|
[ Metadata File (table-v3.json) ] <-- スキーマ、パーティション情報、現行スナップショットを定義
|
[ Manifest List (snapshot-123.avro) ] <-- スナップショットを構成するマニフェストファイルをリスト化
|
[ Manifest File (manifest-abc.avro) ] <-- データファイルとその統計情報をリスト化
|
[ Data Files (file1.parquet, file2.parquet) ] <-- 実際のデータ
この構造により、エンジンはCatalogからメタデータを辿るだけで、ファイルシステムをスキャンすることなくテーブルの全貌を把握できます。これがエンジン非依存性とスケーラビリティの源泉です。
主な特徴と強み
-
隠れたパーティショニング (Hidden Partitioning): ユーザーは物理構造を意識せずクエリ可能。後からパーティション戦略を変更しても、過去のデータを書き換える必要がない点は、長期運用において絶大なメリットです。また、
WHERE event_timestamp >= '2025-07-08'のようにクエリを書くだけで、Icebergが裏でdt=2025-07-08のような物理パーティションを自動で認識し、スキャン対象を絞り込んでくれます。 - 柔軟なスキーマ進化: カラム名のリネームや型の変更が安全に行えます。
-
エンジン中立性: Spark, Flink, Trinoなど多種多様なエンジンから同じテーブルにアクセス可能。
- 具体的なユースケース: Flinkでリアルタイムに書き込み、Trinoで低遅延な分析クエリを実行するなど、複数のエンジンを組み合わせる基盤に最適です。
ここで挙げた主要なエンジンは、それぞれ以下のような特徴を持っています。
- Spark: バッチ処理、リアルタイム処理、機械学習など、幅広い用途に対応できる非常に人気の高い汎用エンジンです。データの書き込みや変換処理で中心的な役割を担うことが多いです。
- Trino (旧PrestoSQL): 様々な場所（データベース、クラウドストレージなど）にあるデータに対して、高速にSQLで問い合わせ（クエリ）ができるエンジンです。アドホックな分析やBIツールからの接続で強みを発揮します。
- Flink: リアルタイムで発生し続けるデータ（ストリームデータ）の処理に特化しており、低遅延でのデータ取り込みや集計に適しています。
- Hive: もともとはHadoop上でSQLを使うためのソフトウェアですが、現在ではIcebergテーブルを読み書きするエンジンとしても利用できます。ただし、パフォーマンス面から、主要な選択肢はSparkやTrino、Flinkとなることが多いです。
考慮事項とトレードオフ
- カタログ選定の重要性と複雑さ: 上図の「Catalog」の選定、構築、運用が導入における最初で最大のハードルになる可能性があります。具体的には、AWS Glue Catalog、Project Nessie、JDBC Catalog、あるいはセルフホストのREST Catalogなどから選択する必要があり、それぞれに一長一短があります。
- メタデータのメンテナンス: 古いスナップショットや不要になったデータファイルは自動では消えません。定期的なクリーンアップ処理をパイプラインに組み込む運用設計が必須です。
- エコシステムの成熟度: 対応エンジンは多いですが、各エンジンでのサポートレベルや安定性にはまだバラつきが見られます。
Delta Lake：Sparkエコシステムとの一体感と信頼性
Databricksによって開発され、Linux FoundationがホストするDelta Lakeは、「データレイクにデータベースレベルの信頼性をシンプルにもたらす」 という明確な目的を持って生まれました。
Delta Lakeの思想：トランザクションログによる信頼性の注入
Delta Lakeの核は、_delta_logディレクトリに時系列で記録されるトランザクションログです。すべての変更（COMMIT）は、新しいJSONファイルとしてアトミックに記録されます（アトミックとは、成功か失敗かの二者択一であり、決して中途半端な状態で終わらないということ）。
【Delta Lakeのトランザクションログ】
my_table/
├── _delta_log/
│ ├── 00000.json <-- COMMIT 1: 2つのファイル(A,B)を追加
│ ├── 00001.json <-- COMMIT 2: 1つのファイル(C)を追加
│ ├── 00002.json <-- COMMIT 3: ファイルBを削除
│ └── ...
├── data_file_A.parquet
├── data_file_C.parquet
└── ...
エンジンは、このログを最初から最後まで再生することで、テーブルの現在の状態（どのファイルが有効か）を決定します。このシンプルな仕組みが、堅牢なACIDトランザクションを実現しています。
主な特徴と強み
- 堅牢なACIDトランザクション: シンプルなログ追記モデルにより、高い並列処理環境でもデータの信頼性を保証します。
-
強力なDMLサポート (MERGE/UPDATE/DELETE): レコードレベルの更新や差分マージが得意です。
- 具体的なユースケース: 日次のバッチ処理で、CDCデータ（変更履歴）をマスターテーブルにマージ（MERGE）するといったETL処理を劇的に簡素化します。
-
Sparkとのシームレスな統合: Sparkユーザーなら学習コストほぼゼロで利用可能。
OPTIMIZEやZ-ORDERといった便利な運用コマンドが組み込まれています。
考慮事項とトレードオフ
- トランザクションログの管理: エンジンはテーブル状態を把握するためにログを読み込みますが、JSONログが増えすぎると読み込みに時間がかかります。そのため、定期的にOPTIMIZEコマンドを実行し、ログ情報をParquet形式のチェックポイントファイルに集約する運用が不可欠です。
- Spark中心のエコシステム: Spark以外のエンジンでの利用体験はまだ発展途上な面があります。最新機能が使えなかったり、パフォーマンスがSparkほど最適化されていなかったりする場合があります。
- 硬直的なパーティショニング: パーティションは従来のHive形式に依存しており、一度決定すると後からの変更は大規模なデータ書き換えが必要でした。（注: 近年のバージョンではパーティション列の変更もサポートされ始めています）
どちらを選ぶか？
| 項目 | Apache Iceberg | Delta Lake |
|---|---|---|
| 設計思想 | 物理レイアウトからの解放 | データレイクへの信頼性の注入 |
| ガバナンス | コミュニティ主導 (ASF) | 企業主導から発展 (LF) |
| 主な強み | 長期的な柔軟性 (隠れたパーティショニング)、エンジン中立性 | Sparkとの一体感、強力なDML、導入のシンプルさ |
| 主なトレードオフ | カタログ管理の複雑さ、自前での運用設計コスト | Sparkへの最適化バイアス、硬直的なパーティショニング |
| スキーマ進化 | 非常に柔軟 (カラムIDで管理し、リネーム/型変更が安全) | 比較的柔軟 (カラム名で管理。一部制約あり) |
| パフォーマンス最適化 | ファイル・パーティションプルーニング | プルーニング + Z-Ordering (多次元クラスタリング) |
| エコシステム | ベンダー中立で広範 (Spark, Trino, Flink, Snowflake, BigQuery...) | Spark/Databricks中心に強力。他エンジンは追従中。 |
| フィットするシナリオ | マルチエンジン環境 (Flink+Trino等)でのリアルタイム分析 | 日次バッチでの大規模なMERGE処理など、Spark中心のETL |
-
Apache Icebergを選ぶ場合:
- 特定のベンダーやエンジンへのロックインを避けたいという強い方針がある。
- 複数のエンジン（Spark, Flink, Trino等）を併用することが前提のアーキテクチャ。
- 数十年単位でデータを保持する可能性があり、将来のパーティション変更に備えたい。
- 受け入れるトレードオフ: カタログの選定・構築・運用という初期コストと継続的な管理コスト。
【Iceberg: マルチエンジン環境】
リアルタイム書き込み アドホック分析 バッチ処理
↓ ↓ ↓
[ Flink ] --------→ [ Iceberg ] ←-------- [ Trino ]
Table ↑
↑ |
| 低遅延クエリ
| |
[ Spark ] |
バッチ処理・ETL [ BI Tool ]
特徴:
✓ 各エンジンが得意分野を活かせる
✓ 同じテーブルに複数エンジンからアクセス
✓ エンジン間でのデータ整合性を保証
-
Delta Lakeを選ぶ場合:
- 主体がSpark/Databricksで、エコシステム内で完結させたい。
- レコードレベルの更新 (MERGE) が最重要要件である。
- 運用をシンプルに保ち、迅速に信頼性の高い基盤を立ち上げたい。
- 受け入れるトレードオフ: 将来のエンジン変更の可能性は低い。パーティションは初期設計で固定化される。
【Delta Lake: Spark中心】
主要な処理エンジン
↓
ETL処理 → [ Spark ] → [ Delta Lake ] → 分析・ML
MERGE処理 Table 機械学習
バッチ処理 ↓
[ Databricks ]
他エンジン（限定的サポート）
↓
[ Trino/Presto ] → [ Delta Lake ]
[ Flink ] Table
↑
読み込み性能・機能に
制限がある場合も
特徴:
✓ Sparkエコシステムで最適化
✓ 強力なDML（MERGE/UPDATE/DELETE）
✓ 他エンジンからのアクセスは発展途上
おわりに
DatabricksのDelta Lake UniFormという機能もありました。これは、データレイクハウスの相互運用性を向上させる機能で、Apache Icebergにも対応しています。これにより、Snowflakeをはじめとする、オープンテーブルフォーマットに対応した製品とのシームレスな相互運用性を実現できるとのこと。
色々整理しましたが、双方同じような課題意識をもって立ち上がって来た歴史があり、データ活用に取り組む上で、うまく活用していけたらなと思います！
Discussion