![[資料公開] 書籍『実践 Apache Iceberg』の歩き方、というタイトルで登壇しました](https://devio2024-media.developers.io/image/upload/f_auto,q_auto,w_3840/v1761839632/user-gen-eyecatch/gd8l35sqspatyno5fmos.png)
[資料公開] 書籍『実践 Apache Iceberg』の歩き方、というタイトルで登壇しました
クラウド事業本部の石川です。先日、目黒のAWS Loft Startup Loft Tokyoで開催されたイベント 『実践 Apache Iceberg』徹底解説 - 著者と共に学ぶ Iceberg の最新情報にて、書籍『実践 Apache Iceberg』の歩き方というタイトルで登壇させていただきました 。
本日は、当日の発表内容をダイジェストでご紹介します。Apache Icebergの基本から、書籍を活用した学習法、さらに一歩進んだ実践的な活用ポイントまでをまとめました。
アジェンダ
18:30-19:00 開場・受付開始
19:00-19:05 オープニング
19:05-19:10 書籍紹介
19:10-19:30 PyIceberg から入門する Apache Iceberg アマゾン ウェブ サービス ジャパン合同会社 疋田
19:30-19:50 Apache Iceberg フォーマット v3 と最新動向 アマゾン ウェブ サービス ジャパン合同会社 田中
19:50-20:00 書籍「実践 Apache Iceberg」の歩き方 クラスメソッド株式会社 石川氏
20:00-20:10 Apache Iceberg Case Study in LINE ヤフー LINE ヤフー株式会社 奥田氏
20:10-20:20 Apache Iceberg を導入した大規模データ基盤における開発と育成 株式会社 NTT ドコモ 松原氏
20:20-20:30 セキュリティ監視と Apache Iceberg 株式会社 LayerX / 三井物産デジタル・アセットマネジメント株式会社 鈴木氏
20:30-20:35 クロージング
20:35-21:30 懇親会 (現地のみ)
登壇資料
書籍『実践 Apache Iceberg』の知識を実務に繋げる、メダリオンアーキテクチャのテーブル設計から、CoW/MoR の使い分け、パーティション戦略まで、実プロジェクトで直面する課題と解決策を解説します。AWS 環境への導入を成功させるためのベストプラクティスを、具体的な注意点と対策と共にご紹介します。
なぜ今、Apache Icebergなのか？
まずは、Apache Icebergの基礎技術と、なぜ今注目されているのかについてです。
Apache Icebergとは
Apache Icebergは、データレイク上にあるペタバイト規模の巨大な分析用データセットを管理するために設計された、 オープンソースのテーブルフォーマット（OTF） です。
2021年のAWS re:InventでAmazon Athenaがサポートを開始したことで、広く注目を集めるようになりました。
従来のデータレイクが抱える課題
Apache Icebergが登場するまで、従来のデータレイクにはエンタープライズ利用において深刻な課題がありました。
- データ整合性の欠如: 複数ジョブの同時実行時、読み書きが競合してデータが不整合になる（トランザクション保証がない）。
- 少量レコード更新の非効率性: GDPR対応などで少量レコードを更新するだけでも、パーティション全体の再書き込みが必要で、コストと時間が膨大になる。
- パーティション管理の限界: パーティション数が数万に達すると、メタデータ管理のオーバーヘッドでクエリ性能が著しく劣化する。
- クエリ設計の複雑化: クエリの効率化にはパーティション構造の理解が必須で、開発者の負担が大きい。
- 過去状態の復元困難: 誤削除やデータ破損時に、特定時点へ復元することが事実上不可能。
Apache Icebergによる解決策
Apache Icebergは、これらの課題を以下のような強力な機能で解決します。
- ACIDトランザクション: 楽観的同時実行制御（Optimistic Concurrency Control）により、データの整合性を担保します。
- Row-levelの更新・削除:
MERGE、UPDATE、DELETEといったSQL操作をサポートし、少量データの更新を効率的に行えます。 - 隠しパーティション (Hidden Partitioning): ユーザーがパーティション構造を意識する必要がなくなります。
- パーティション変換 (Partition Evolution): テーブル利用後でもパーティション戦略を変更できます 。
- タイムトラベル (Time Travel): 任意の時点のスナップショットにアクセスし、過去のデータを簡単に復元・参照できます。
体系的に学ぶ『実践 Apache Iceberg』の紹介
これらの強力な機能を体系的に学び、実務に活用したい方向けの専門書が『実践 Apache Iceberg』です 。
本書は「手を動かしながら学ぶこと」を重視しており、多くの章にハンズオンが用意されています 。ハンズオンのコードはすべてiceberg_book_handsonというGitHubリポジトリにて公開されています 。
3部構成で段階的に理解を深める
本書は以下の3部構成になっています。
- 基礎編（第1部）: 従来の課題とIcebergの仕組みを解説。メタデータレイヤーとデータレイヤーの構造など、機能の土台となる知識を学びます。
- 実装編（第2部）: Spark、Flink、Trino、Hive、PyIcebergという5つの主要なクエリエンジンでの実装方法を、座学とハンズオンで学びます。
- 応用編（第3部）: CDCによるリアルタイム同期、SCD Type2による履歴管理、WAPパターンによるデータ品質管理など、実務的なソリューションを学びます。
この本を効率よく活用する読み方
本書をどう読むべきか、3つのアプローチを紹介しました。
- 即効性を求める場合: 自分の課題に最も関連する章（例：Trinoを使っているならTrinoの章）から読み、必要に応じて基礎編（1-3章）に戻る。
- 体系的に学びたい場合: 第1章から順番に読み進める。
- ハンズオン重視の場合: GitHubのサンプルコードがある章を優先的に手を動かしながら学習する 。
どのアプローチでも、第1章「データレイクの課題とApache Iceberg」 と 第2章「Apache Icebergの仕組みと機能」 は、全体の理解の基盤となるため、早い段階で目を通しておくことを強くお勧めします 。
🚀 実践で役立つ3つのポイント
書籍で体系的な知識を学んだ上で、現場で直面しやすい3つの実践的ポイントを解説しました。
1. メダリオンアーキテクチャでの活用
メダリオンアーキテクチャ（Bronze/Silver/Goldの3層でデータを管理する手法）でIcebergをどう活かすか、という点です。
| レイヤ | 役割 | 活用するIcebergの機能 |
|---|---|---|
| Bronze | 生データの保存 | スキーマ進化: ソース側のカラム追加などに柔軟に対応。 隠しパーティション: 取り込み日などでパーティションを切り、Silver層への増分処理を効率化。 |
| Silver | データのクレンジング・正規化 | ACIDトランザクション: Bronzeからの増分データをMERGE INTOでアトミックにマージ。パーティション進化: 将来のデータ量増大に備え、後からパーティション戦略を変更可能に。 |
| Gold | BI・ML用の集計データ | パフォーマンス最適化: REWRITE DATA FILESでコンパクション（ファイル結合）やソートを行い、クエリを高速化。タイムトラベル: 「先週末時点のレポート」や「前日比」など、過去の集計結果を簡単に参照。 |
2. 更新戦略 CoW と MoR の使い分け
Apache Icebergには Copy-on-Write (CoW) と Merge-on-Read (MoR) という2つの更新戦略があります 。
-
CoW (Copy-on-Write)
- 優先度: 読み取り効率を最大化。
- 仕組み: 変更行を含むデータファイル全体を再作成します。
- コスト: 書き込みコストは高いですが、読み込みコストは低いです。
- 用途: 行レベルの変更が少ない、読み取り中心のBI分析など。
-
MoR (Merge-on-Read)
- 優先度: 書き込み速度を優先。
- 仕組み: 変更差分を「削除ファイル」として記録し、読み取り時にマージします。
- コスト: 書き込みコストは低いですが、読み込みコストは高くなります。
- 用途: 頻繁な少量更新やストリーミング処理。
基本は、リアルタイム取り込みならMoR、バッチならCoWと覚えておくと良いでしょう。
注意点として、IcebergのデフォルトはCoWですが、Amazon Athenaの更新系クエリのデフォルトはMoRです。
3. 隠しパーティション設定の注意点と対策
隠しパーティションは、元の列（例：タイムスタンプ）を基にIcebergが自動でパーティションを管理する便利な仕組みです 。PARTITION BY day(order_timestamp) のように定義するだけで、クエリ時は WHERE order_timestamp > ... と元の列を指定すれば、Icebergが自動でパーティションを読み飛ばしてくれます。
しかし、この設定には「落とし穴」があります。
-
失敗事例①：パーティション粒度が細かすぎる
- 問題:
device_idのような高カーディナリティ（値の種類が非常に多い）列でそのままパーティショニングすると、パーティション数が爆発的に増加し、大量の小さなファイル（スモールファイル）が生成されます。 - 対策: 高カーディナリティ列には
bucket(N, col)関数を使い、パーティション数を固定数（例:bucket(100, device_id)）に制限し、均等に分散させます。
- 問題:
-
失敗事例②：OPTIMIZEによるストレージ爆発
- 問題: 上記で発生した大量のスモールファイルを解消するため
OPTIMIZE（コンパクション）を実行すると、古いファイルがすぐには削除されず、新しいファイルと一時的に重複して存在するため、ストレージ使用量が爆発的に増加することがあります。 - 対策: コンパクション後、必ず
expire_snapshots（スナップショット削除）を実行し、不要になった古いファイルを物理的に削除します。
- 問題: 上記で発生した大量のスモールファイルを解消するため
最後に
Apache Icebergは、従来のデータレイクが抱えていた課題を解決する強力なテーブルフォーマットです。『実践 Apache Iceberg』は、その基礎からクエリエンジンごとの実装、応用パターンまでを体系的に学べる良書であり、ハンズオンも非常に充実しています。
今回時間の関係で紹介できなかった、ストリーミングインジェッション時のテーブル最適化（OPTIMIZE）、効果的なソートオーダー、Equality Deleteといった、さらに高度な課題を解決するためにも、本書は不可欠な一冊となるはずです。
合わせて読みたい
