1 2026/01/21 Saki Kitaoka ゼロからはじめる！ Open Table Format Apache Iceberg とはなにか？ 

Agenda 1 (前提) Open Table Format とは何か？ 2 Apache Icebergとはなにか？ 

自己紹介 Saki Kitaoka (@ktksq) 趣味 本を読むこと、ミュージカル鑑賞 出版 有志で技術書典で本を出版しています！ Blog https://ktksq.hatenablog.com/ (最近更新できていなくて悲しい) Twitter 会社の公式Twitterの中の人やってます！ @DatabricksJP New! 

(前提) Open Table Formatとは何か？ 

Open Table Formatの歴史 (1/2) DWHの信頼性と、データレイクの柔軟性を両立するために、 Open Table Formatが生まれた。 OLTP (オンライン・トランザクション ) OLAP (オンライン分析処理) データレイク オープンテーブルフォーマット 1970年後半〜 1990年代〜 2000年代後半〜 20210年代後半〜 

Open Table Formatの歴史 (1/2) 1件ずつの更新を、低遅延で確実に 反映したい ACIDで「二重計上しない／整合が 崩れない」を担保 ✅ 強い：書き込みの正確さ／同時 実行制御 ❌ 苦手：大量スキャン・集計（「全体 を見たい」用途） 取引は守れたが、「経営・分析で横 断集計したい」要求が出る “すべてを DWHに整形して入れ る”のが追いつかなくなる “柔軟だけど壊れやすい ” を解 決するため、テーブルとしての ルールが必要に レイクの柔軟性の上に、 DWH級 の信頼性を “後付け”する 分析は基本が 大量スキャン＋集計 ＋結合 データ品質を保つため、取り込みは ETLで整形してから載せる 前提 ✅ 強い：定型BI・KPI集計・ガバナン スされた指標 ❌ 限界： ・取り込み・スキーマ変更が重い ・ストレージと計算が密結合 しがちで 拡張が硬い ・多様な形式（JSON/ログ/画像など） をそのまま扱いにくい S3/GCS等で 低コストにスケール 、 多様なデータをそのまま保存 Schema-on-read：読む側が解釈 すれば良い ✅ 強い：柔軟性／スピード（取り込 みが軽い）／多様なデータ ❌ 限界： ・ファイル寄せ集めで 更新・削除・ 履歴管理が難しい ・小さなファイル乱立やパーティショ ン管理が運用負債に オブジェクトストレージ上のデータを、 テーブルとして管理 する標準 ストレージと計算を分離 ：同じデータを 複数エンジンで共通利用 ✅ レイクの柔軟性 × DWHの信頼性 × 相互運用性 ❗ポイント：テーブルの “状態”をファイ ル集合ではなく メタデータで定義 する OLTP (オンライン・トランザクション ) OLAP (オンライン分析処理) データレイク オープンテーブルフォーマット 1970年後半〜 1990年代〜 2000年代後半〜 2010年代後半〜 

『Lakehouse』の誕生 Open Table Formatを用いることで、データレイクの低コスト・柔軟性の上に、 DWH の信頼性・性能・ガバナンスを統合したデータ基盤アー キテクチャを構築可能になる。 構造化テーブル 構造化されていないファイル : ログ、テキスト、画像、動画 データウェアハウス データレイク ガバナンスとセキュリティ テーブルACL データサイエンス & ML ガバナンスとセキュリティ ファイルとBlob データ ストリーミング ビジネス インテリジェンス SQL分析 データサブセットの コピー 分断され重複する データサイロ 互換性のない セキュリティ、 ガバナンスモデル ユースケースに対する 不完全なサポート 「データレイクの安さ・柔軟さ」と「 DWHの信頼性・性能・ガバナンス」を、同じデータの上で両立するアーキテクチャ 

Open Table Formatの歴史 (2/2) データレイクの「ファイルの寄せ集め」問題（更新・削除・履歴管理の難しさ）を解決するため、 メタデータ管理で ACID / Time Travel / スキーマ進化を提供する Open Table Format が登場した。用途に合わせて複数の実装が発展している。 2017年 Apach Hudi ● ストリーミング取り込み・増分処 理(incremental)を重視して誕生 ● Upsert / CDC / レコード単位の 更新を効率化（COW/MOR） ● レイク上で “準リアルタイムな運 用” を実現しやすい 2018年 2019年 Apach Iceberg ● 大規模分析で必要な 信頼性と スケール をレイクに持ち込む ● Snapshot/Manifest による高速 プランニング、Time Travel、ス キーマ進化 ● エンジン非依存 (Spark/Trino/Flink など)で 相互 運用しやすい Delta Lake ● レイク上に トランザクションログ （Delta log） を置き、ACID を提 供 ● Batch + Streaming の統合、 更新/削除/マージを実務で扱い やすく取り込み〜運用を一気通 貫で回す設計（最適化・運用機 能も充実） 

Open Table Formatの歴史 (2/2) データレイクの「ファイルの寄せ集め」問題（更新・削除・履歴管理の難しさ）を解決するため、 メタデータ管理で ACID / Time Travel / スキーマ進化を提供する Open Table Format が登場した。用途に合わせて複数の実装が発展している。 2017年 Apach Hudi ● ストリーミング取り込み・増分処 理(incremental)を重視して誕生 ● Upsert / CDC / レコード単位の 更新を効率化（COW/MOR） ● レイク上で “準リアルタイムな運 用” を実現しやすい 2018年 2019年 Apach Iceberg ● 大規模分析で必要な 信頼性と スケール をレイクに持ち込む ● Snapshot/Manifest による高速 プランニング、Time Travel、ス キーマ進化 ● エンジン非依存 (Spark/Trino/Flink など)で 相互 運用しやすい Delta Lake ● レイク上に トランザクションログ （Delta log） を置き、ACID を提 供 ● Batch + Streaming の統合、 更新/削除/マージを実務で扱い やすく取り込み〜運用を一気通 貫で回す設計（最適化・運用機 能も充実） 

Apache Iceberg とは何か？ 

Icebergの実体 (1/2) ②メタデータレイヤー ③データレイヤー (出典: Apach Iceberg活用入門 インプレス出版、2025年) ①カタログレイヤー ● 役割：db.table のようなテーブル名から、“現在有効なメタデータファイル （最新版） ” の場所を解決する入口。 ● 中身：Hive Metastore / Glue / REST Catalog / Nessie などの カタログ サービス。 ● ポイント：更新時は 参照（ポインタ）を新しいメタデータに切り替える ことで、 原子的コミットと同時更新制御（楽観ロック）を実現。 ● 役割：実データそのものを保持する層。 ● 中身：主に Parquet/ORC/Avro のデータファイル （＋必要に応じて Delete ファ イル）。 ● ポイント：Iceberg はデータを直接上書きしにくいオブジェクトストレージ上でも、 新しいファイルを追加し、メタデータ参照を切り替える ことで更新・削除を表現で きる。 ②メタデータレイヤー ● 役割：テーブルの状態を表す “設計図”で、どのデータをどう読むか を決める。 ● ポイント：クエリ時はここを辿って 必要なファイルだけを特定（プルーニング） し、オブジェクトストレージの “大量ファイル探索” を避けることができる。 ③データレイヤー 

Icebergの実体 (2/2) (出典: Apach Iceberg活用入門 インプレス出版、2025年) カタログ メタデータファイル マニフェストリスト マニフェストファイル データファイル テーブル名（例: db1.table1）から 「現在有効なメタデータファイルの場所」 を引く ための台帳。コミット時は 新しいメタデータへの参照（ポインタ）を原子的に更新 し、同時更新を制御する。 テーブルの定義と状態を表す“設計図”。スキーマ、パーティション仕様、テーブ ル設定、現在のスナップショット ID などを持ち、どのスナップショットが最新版か を示す。 あるスナップショットが参照する マニフェストファイルの一覧 。クエリ計画時に、ど のマニフェストを読めばよいかを素早く絞り込むための“索引”。 データファイル（＋削除ファイル）単位の台帳 。各ファイルの 追加/削除状態、 パーティション値、行数・サイズ、列統計（ min/max/null数など） を持ち、読み 取り時の ファイルスキップ（プルーニング） に使われる。 実データ本体（多くは Parquet/ORC/Avro）。Iceberg はデータを直接“上書き更 新”するのではなく、新しいデータファイルを追加 し、参照関係（メタデータ）を切り 替えることでテーブル更新を表現する。 

メタデータレイヤーの実体 Icebergテーブルを作成 メタデータレイヤーの中身 

メタデータレイヤーの実体 マニフェストリスト例 { "manifest_path": "s3://datalake/db1/orders/metadata/62acb3d7-e992-4cbc- 8e41-58809fcacb3e.avro", "manifest_length": 6152, "added_snapshot_id": 8333017788700497002, "added_data_files_count": 1, "added_rows_count": 1, "deleted_rows_count": 0, "partitions": { "array": [ { "contains_null": false, "lower_bound": { "bytes": "¹Ô\\u0006\\u0000" }, "upper_bound": { "bytes": "¹Ô\\u0006\\u0000" } } ] } } { "data_file" : { "file_path" : "s3://datalake/db1/orders/data/order_ts_hour=2023-03-07 -08/0_0_0.parquet", "file_format" : "PARQUET", "block_size_in_bytes" : 67108864, "null_value_counts" : [], "lower_bounds" : { "array": [{ "key": 1, "value": 123 }], } "upper_bounds" : { "array": [{ "key": 1, "value": 123 }], }, } } { "table-uuid" : "072db680-d810-49ac-935c-56e901cad686", "schema" : { "type" : "struct", "schema-id" : 0, "fields" : [ { "id" : 1, "name" : "order_id", "required" : false, "type" : "long" }, { "id" : 2, "name" : "customer_id", "required" : false, "type" : "long" }, { "id" : 3, "name" : "order_amount", "required" : false, "type" : "decimal(10, 2)" }, { "id" : 4, "name" : "order_ts", "required" : false, "type" : "timestamptz" } }, "partition-spec" : [ { "name" : "order_ts_hour", "transform" : "hour", "source-id" : 4, "field-id" : 1000 } ] } マニフェストファイル例 メタデータファイル例 

Icebergにおけるメタデータの取り扱い Catalog Metadata Data manifest-1 file-A ... file-M manifest list manifest-1 file-A file-B ... file-M snapshot-1 1. Catalog：テーブル名から current snapshot（snapshot-1） を解決 2. snapshot-1：参照先の manifest list を取得 3. manifest list：読むべき manifest（manifest-1） を特定 4. manifest-1：対象の データファイル一覧（ file-A…file-M） を取得 5. Data：必要な データファイルを読み込む （結果を返す） snapshot-1 の時点のテーブルは、 manifest-1 に載っている file-A〜file-M から 成る」という スナップショットの基本構造 ● Snapshot は「データを持つ」のではなく、どのファイル集合がテーブルか を指 す“確定点” ● manifest は データファイル台帳 （＋統計）なので、毎回ストレージを ls せずに 済む 

Icebergにおけるメタデータの取り扱い Catalog Metadata Data manifest-1 file-A ... file-M manifest list manifest-1 file-A file-B ... file-M snapshot-1 manifest-2 file-N ... file-Z file-N ... file-Z manifest list manifest-1 manifest-2 snapshot-2 1. append：新しいデータ（例：file-N…file-Z）を書き出す 2. manifest-2 を新規作成 ：追加したファイル群を台帳化（ ADDEDとして記録） 3. manifest list を新規作成 ：{manifest-1（既存）, manifest-2（新規）} をまとめる 4. snapshot-2 を作成：新しい manifest list を指す“新しい版”を作る 5. Catalog 更新：current を snapshot-2 に切り替え（コミット完了） 新しいコミット（例：append）で snapshot-2 が作られ、 manifest が増えるが、昔の manifest は再利用され る、という増分管理。 ● Iceberg は更新のたびに「巨大な一覧を作り直す」 のではなく、“既存を再利用 + 追加分だけ新しく作 る” のでスケールしやすい ● これが コミットが速い / メタデータ更新量が小さい 理由 

Icebergにおけるメタデータの取り扱い Catalog Metadata Data manifest-... parquet manifest list m-1 ... m-30 manifest-1 parquet manifest-30 parquet snapshot manifest-31 file-N ... file-Z file-N ... file-Z manifest list snapshot N+1 m-1 ... m-31 1. 既存 snapshot は manifest m-1…m-30 を参照してテーブル状態を表現 2. 変更（追記/更新など）が起きた部分だけ、新しいファイル群を生成 3. その差分をまとめた 新 manifest（m-31） を追加作成 4. 新 snapshot（N+1）は m-1…m-30 を再利用 し、m-31 だけ追加 した manifest list を作る 5. 最後に Catalog の参照を N+1 に切り替え （差分コミット） 

Icebergにおけるメタデータの取り扱い Catalog Metadata Data manifest-... parquet manifest list m-1 ... m-30 manifest-1 parquet manifest-30 parquet snapshot 1. snapshot は manifest list を通じて複数 manifest（manifest-1…manifest-30）を参照 2. 各 manifest は、担当する データファイル群（ Parquetなど） を台帳化（統計付き） 3. クエリ時はまず manifest list → 対象manifestを選別（不要な manifest をスキップ） 4. 次に manifest の統計で 読むべきデータファイルだけに絞る （ファイル単位プルーニング） 5. 絞り込んだファイルだけ読み、結果を返す（＝大量ファイルでも高速） 「1つの snapshot は、manifest list を介して、複数 manifest（manifest-1…manifest-30）を参照し、そ れぞれが別々の Parquet 群を担当する」という、読 み取り最適化のための分割構造 。 ● manifest list は「索引の索引」 ● manifest は「ファイル台帳（統計つき）」 ● だから Iceberg は 大量ファイルでもプランニ ングが速い 

Icebergの特徴 1 2 3 信頼性（ACID）と履歴管理 大規模分析に強いメタデータ設計（高 速な読み取り） オープン＆相互運用 （エンジン分離） ● スナップショットでテーブル状態をバージョン 管理（Time Travel / Rollback が可能） ● コミットは 新しいメタデータを作成 → カタロ グの参照を切替（原子的に見える） ● 同時書き込みは楽観的ロックで検知・防止 （壊れた状態を作りにくい） ● スキーマ進化（列追加/リネーム/型変更な ど）を前提に設計 ● 監査・再現性：いつ誰が何をしたか（操作種 別/親snapshot等）を追跡しやすい ● Manifest / Manifest List が「データファイ ル台帳＋統計」を持ち、ファイル探索を回避 ● クエリ時に パーティション値・min/max統 計で不要なファイルをスキップ（プルーニン グ） ● “巨大な1リスト”を毎回作り直さず、差分だけ メタデータを追加してスケール ● レイク上でも DWH級の 計画生成の速さ / 読み取り性能 を狙える ● ストレージ（Parquet等）と計算エンジンを 分離：同じテーブルを複数エンジンで利用可 能 ● Spark / Trino / Flink などで共通に読み書 きしやすく、ベンダーロックインを抑制 ● カタログ（Hive/Glue/REST/Nessie など）を 選べ、環境に合わせて統合できる ● マルチクラウド/マルチツール環境で 標準 テーブル層として置きやすい Icebergは「信頼できるテーブル」をデータレイク上に実装し、分析性能と相互運用性を同時に実現することができる。 

20 Thank you! 

No content