はじめに
データレイクは、構造化・非構造化データを低コストで蓄積できる仕組みとして発展してきました。
そんな中で Apache Iceberg はなぜ登場したのか、どんな特徴があるのかを見ていきます。
本記事では、
- これまでのデータレイクが抱えていた課題
- Iceberg がそれらをどのように解決するのか
- Iceberg の特徴と内部構造
を整理し、Iceberg が「なぜ選ばれているのか」を考えてみます。
Apache Iceberg はまだまだ日本では書籍が全然無く（2025年末時点で 2 冊程度）、情報を集めるのも一苦労、そんな Apache Iceberg を簡単にまとめていきたいと思います。
※シリーズ化して、何回か投稿していきたいなと思ってます。
これまでのデータレイクの課題
Apache Iceberg が生まれる前、データレイクにおけるテーブルフォーマットといえば、Hive でした。
S3などのオブジェクトストレージ上にParquetファイルを配置し、Hive Metastoreでスキーマやパーティション情報を管理する構成です。
しかし、運用が本格化するにつれて、Hiveテーブル特有の制約が明確になっていきます。
例えば、以下のような課題があります。
スキーマ進化が難しい：
Hive テーブルでは、スキーマは「ファイルの構造」と強く結びついています。
そのため、スキーマ変更が安全でなく、既存ファイルとメタデータの不整合が起きやすい問題があります。型変更やカラム削除は特に困難です。
UPDATE / DELETE を前提としていない：
Hiveテーブルは基本的に append-only であり、UPDATE / DELETEなどの更新操作をネイティブではサポートしていません。
パーティション設計が運用の足枷に：
Hiveでは、パーティションは ディレクトリ構造そのもの です。
そのため運用中でのパーティション変更が困難になります。
Iceberg で何が解決されるか
Hive テーブルの制約に対して、いくつかのテーブルフォーマットが登場しました。
その中の一つが Apache Iceberg です。
Apache Iceberg は Netflix 社によって開発されたテーブルフォーマットで、現在は Apache プロジェクトとして管理されています。
Iceberg は以下のような機能を提供します。
ACIDトランザクションの実現：
ACID保証が可能。
- 書き込みは原子的にコミット
- 失敗時は状態が変わらない
- 並行処理でも整合性を維持
柔軟なデータ操作：
更新操作も可能。
- INSERT
- UPDATE
- DELETE
- MERGE
エンジン非依存な設計：
Athena、Spark、Trinoなど、複数のクエリエンジンから同一テーブルを安全に操作可能。
パーティション進化：
パーティショニングはメタデータとして管理されているため、パーティション変更が可能。
隠しパーティション：
Icebergは hidden partitioning を採用しています。
- クエリ側はパーティションを意識しない
- 内部的には最適なファイルだけをスキャン
タイムトラベル：
過去のスナップショットを参照することが可能。
- 過去時点のデータ参照
- 誤更新時のロールバック
スキーマ進化：
スキーマの更新が可能。
- カラム追加・削除が安全
- 型変更も一定範囲で可能
Iceberg の内部構造
Icebergは、データファイルを直接管理するのではなく、メタデータによってテーブル状態を定義しています。
メタデータツリーを上位階層から順に挙げていくと以下の通りです。
- カタログ
- メタデータファイル
- マニフェストリスト
- マニフェストファイル
- データファイル
https://iceberg.apache.org/spec より引用
1 はカタログ層、 2~4 はメタデータ層、5 はデータ層と呼ばれます。
では、下から順に見ていきます。
データファイル
実際のデータを含むファイルです。Iceberg は Apache Parquet、Apache ORC、Apache Avro をサポートしています。一般的には Parquet が多く使われます。
マニフェストファイル
データファイルのリスト情報を保持し、データファイルのパスを指し示します。
また、各データファイルが保持するデータに対する統計情報として、レコード数や最小値、最大値を持っています。
この統計情報を使ってプルーニングすることで必要なデータファイルのみを参照することができ、パフォーマンスが向上します。
マニフェストリスト
単一スナップショットに対応するマニフェストファイルのリストを保持しているファイルです。
マニフェストファイルのパスだけで無く、パーティション情報、パーティション列の最大値と最小値を持っています。
メタデータファイル
テーブル構造を保持するファイルです。
スキーマ情報、パーティション定義に加えて、現在のスナップショットの情報を持っています。
カタログ
テーブルに対応するメタデータの格納場所を保持します。
Iceberg へのアクセスは、カタログを出発点として行います。
カタログから順に辿っていくことで、実際のデータにたどり着くことができます。
わざわざ複数のファイルを使っていることが不思議に思うかもしれませんが、この構成のおかげで効率的なデータアクセス、過去データ参照、ACID トランザクション制御が実現されています。
※実際の更新や参照操作がどのようなフローで行われるかは、別記事でまとめようかと思っています。
おわりに
Apache Iceberg を簡単に説明してみました。
今後、個別なトピックに絞って投稿していきたいと思います。
乞うご期待！