◾️はじめに
Snowflake で Apache Iceberg でサポートされているらしいので まずは、Apache Icebergについて調べてみた
目次
【１】Apache Iceberg １）テーブル形式（Table Format）とは？ ２）クラウドサービスのサポート状況 【２】歴史 １）背景 - Hive/Hadoopの課題 【３】使用する上での利点 １）ACIDトランザクション対応 ２）スキーマ・パーティション変更が容易 ３）メタデータ管理の自動化 ４）データのクリーンアップやバキュームが安全 ５）ロールバックが簡単 ６）クロスプラットフォームをサポート 【４】Icebergの主な機能 １）スキーマ進化（Schema evolution） ２）タイムトラベル（Time travel）
【１】Apache Iceberg
* 大規模な分析データセットの管理を目的とした オープンソースのテーブル形式（Table Format） cf. Iceberg(アイスバーグ) = 氷山 * 以下の公式ドキュメントの図を参照しておくのもいいかも。
https://iceberg.apache.org/spec/#overview
１）テーブル形式（Table Format）とは？
* データレイク上のファイル群（ParquetやORCなど）を 「テーブル」として論理的に管理するための仕組み
データカタログとの違い
両者は補完し合う関係であり、どちらか一方だけでなく一緒に使われることが多い
| 項目 | テーブル形式 | データカタログ |
|---|---|---|
| 主な役割 | 物理ファイルを「テーブル」として管理し、ACIDやバージョン管理など高度なテーブル機能を提供 | データの位置・スキーマ・パーミッションなどを一元的に登録・検索 |
| 例 | Apache Iceberg, Delta Lake | AWS Glue Catalog, Hive Metastore |
| 管理範囲 | ファイル構造・スキーマ進化・バージョン・トランザクション | テーブルの所在・説明・スキーマ・権限管理 |
| 連携 | データカタログと連携し、テーブルの場所やスキーマをカタログに登録することが多い | Table Formatで管理されているテーブルの情報も記録できる |
具体例：s3://bucket/data/iceberg_table/配下のParquetファイル
* Iceberg table の場合 + s3://bucket/data/iceberg_table/ の下に 複数のParquetファイルやメタデータファイルがある => それらを一つの「テーブル」として扱うためのルール・管理方法が IcebergのTable Formatに当たる。 * AWS Glue Catalogの場合 + 「iceberg_sales」というテーブルがS3のどこにあるかや、 スキーマ、オーナー、説明文などの情報を保持
２）クラウドサービスのサポート状況
[1] Snowflakeとの関係
* 上述の通り、Snowflakeとは独立した技術 * 詳細は、以下の公式ドキュメント参照
https://docs.snowflake.com/ja/user-guide/tables-iceberg
[2] Databricksとの関係
* DatabricksはApache Icebergテーブルをネイティブにサポート * 詳細は、以下の公式ドキュメントなどを参照
https://docs.databricks.com/aws/en/external-access/iceberg
https://docs.databricks.com/aws/en/delta/uniform
[3] AWSとの関係
ついでに、AWSも...
https://aws.amazon.com/jp/what-is/apache-iceberg/
* AWSでのサポート状況は以下の通り + Amazon Redshift + Amazon Athena + Amazon EMR + AWS Glue + Amazon Data Firehose
【２】歴史
* ApacheのHive Hadoopプロジェクトで直面したさまざまな課題に 対処するためにNetflixが開発したオープンソーステーブル形式
１）背景 - Hive/Hadoopの課題
Hive形式（Hive Metastore＋Parquet/ORCファイル）による データ管理に以下のような課題があった。
[1] ACIDトランザクションが弱い
* 複数ジョブが同時にデータを書き換えると不整合が起きやすい
* 列追加・削除やパーティション方式の変更時に 運用負荷が高く、エラーも起きやすい
[3] メタデータ管理の煩雑さ
* パーティション追加/削除時にメタストアと実データのズレが発生しやすい
[4] ファイルの肥大化や管理の難しさ
* 古いファイルの削除・整理が手動で手間がかかる
[5] データのバージョン管理が難しい
* いつどんなデータが入ったか追跡しづらく、誤操作時の復旧も困難
【３】使用する上での利点
* 上記「１）背景 - Hive/Hadoopの課題」に関する解決と ＋α（６）クロスプラットフォームをサポート）が 挙げられる
１）ACIDトランザクション対応
[a] 従来（Hive/Hadoop）の場合
* ファイル管理のみで複数ユーザー/ジョブが同時にファイル操作すると、 競合や中途半端なデータ反映のリスクが高い
[b] Icebergの場合
* 全ての操作がACIDトランザクションで管理されるため、 データの一貫性を自動で担保
２）スキーマ・パーティション変更が容易
[a] 従来（Hive形式）の場合
* スキーマ変更時、古いファイルとの整合性やデータの再ロードが 必要になることが多い
[b] Icebergの場合
* スキーマ進化（schema evolution）という機能により、 スキーマやパーティションの追加・削除が安全にでき、 古いデータとの互換性も確保される
３）メタデータ管理の自動化
[a] 従来（Hive形式）の場合
* パーティションを追加・削除した際にMSCK REPAIR TABLEなどの メタデータ同期作業が必要であり、失敗やズレが発生しやすい
[b] Icebergの場合
* パーティションやスナップショットの管理がメタデータファイルとして 一元管理され、自動で最新状態に保たれる
４）データのクリーンアップやバキュームが安全
[a] 従来（Hive/Hadoop）の場合
* 古いファイルや不要なデータの削除作業は手動で行う必要があり、 必要なデータまで消してしまう事故が起こり得る
[b] Icebergの場合
* メタデータ・スナップショット管理により、 不要なデータを安全にクリーンアップできる
５）ロールバックが簡単
[a] 従来（Hive/Hadoop）の場合
* 間違ったデータ更新・削除が発生した場合、 バックアップからの復元や手動リカバリが必要
[b] Icebergの場合
* 過去のスナップショットにすぐに戻せるので、トラブル時の復旧が容易
６）クロスプラットフォームをサポート
[a] 従来（Hive/Hadoop）の場合
* エンジンごとにメタデータやファイル管理方法が異なり、整合性が崩れやすい
[b] Icebergの場合
* 共通のメタデータと管理方式により、どのエンジンからも一貫したアクセスが可能 * 例：Apache Spark、Apache Hive、Trino、Flink、Presto など
【４】Icebergの主な機能
１）スキーマ進化（Schema evolution）
* あらゆる項目変更に対応
https://iceberg.apache.org/docs/1.9.1/evolution/#schema-evolution
| Items | Explanations |
|---|---|
| Add | 項目追加 |
| Drop | 項目削除 |
| Rename | 項目名変更 |
| Update | 項目のデータ型変更 |
| Reorder | 項目順変更 |
２）タイムトラベル（Time travel）
* Icebergは、テーブル更新のたびに都度スナップショットに記録される。 => そのスナップショットを利用することで、 特定時点のテーブルに対してクエリすることが可能。
https://iceberg.apache.org/docs/1.9.1/spark-queries/#time-travel
-- time travel to October 26, 1986 at 01:21:00 SELECT * FROM prod.db.table TIMESTAMP AS OF '1986-10-26 01:21:00'; -- time travel to snapshot with id 10963874102873L SELECT * FROM prod.db.table VERSION AS OF 10963874102873; -- time travel to the head snapshot of audit-branch SELECT * FROM prod.db.table VERSION AS OF 'audit-branch'; -- time travel to the snapshot referenced by the tag historical-snapshot SELECT * FROM prod.db.table VERSION AS OF 'historical-snapshot'; -- time travel to October 26, 1986 at 01:21:00 -> uses the snapshot's schema SELECT * FROM prod.db.table TIMESTAMP AS OF '1986-10-26 01:21:00';
補足：スナップショットの有効期限
* スナップショットの有効期限は存在するので注意
https://iceberg.apache.org/docs/1.9.1/maintenance/#expire-snapshots
参考文献
Time travel
https://blog.denet.co.jp/athena-apache-iceberg-time-travel/
関連記事
Snowflake ～ 基礎知識編 ～
https://dk521123.hatenablog.com/entry/2021/11/02/130111
Snowflake ～ 入門編 / Hello world ～
https://dk521123.hatenablog.com/entry/2021/11/22/212520
Snowflake x Iceberg 〜 入門編 〜
https://dk521123.hatenablog.com/entry/2025/06/19/003715
