【AWS Summit Japan 2026】Apache Iceberg on AWS 実践ガイド [ANT355] セッションレポート

セッション概要
第1章なぜ今 Apache Iceberg なのか
第2章 AWS スタックの全体像
第3章実装パターン
まとめ
余談

こんにちは😺アプリケーションサービス部の山本です。

中途入社社員向けにトレーニングをしています。

AWS Summit Japan のブレイクアウトセッション 「Apache Iceberg on AWS 実践ガイド - 設計・取り込み・活用のベストプラクティス [ANT355]」 に参加してきました。Apache Iceberg を中核としたレイクハウスを AWS 上で本番運用するための設計指針が、現場目線でまとまった濃いセッションでした。本記事では、その内容をスライドとともに振り返ります。

セッション概要

項目	内容
タイトル	Apache Iceberg on AWS 実践ガイド - 設計・取り込み・活用のベストプラクティス [ANT355]
登壇者	ソリューションアーキテクト, AWS Japan
日時	6月26日(金) 15:00 - 15:40 JST
会場	Hall 8: Room 05
セッション種別	ブレイクアウトセッション
関心領域	オープンデータ / ガバナンス・リスク・コンプライアンス / イノベーションと変革
対象ロール	データエンジニア / 開発者・エンジニア / ソリューション・システムアーキテクト
関連サービス	Amazon EMR / Amazon SageMaker / Amazon S3

セッションは大きく3部構成でした。

なぜ今 Iceberg なのか — 従来のデータレイクの課題と、エージェンティック AI 時代に求められるデータ基盤の要件
AWS スタックの全体像 — Glue Data Catalog・Lake Formation・S3 Tables などによるカタログ・ストレージ・ガバナンスの統合アーキテクチャ
実装パターン — メダリオンアーキテクチャに基づくバッチ ETL とストリーミングの取り込みパターン

以下、章ごとに内容をまとめていきます。

第1章なぜ今 Apache Iceberg なのか

AI の基盤であるデータ

セッションは「AI の基盤であるデータ」という話から始まりました。スライドでは氷山が描かれており、水面の上に出ているのは AI アプリケーションとエージェントオーケストレーション のごく一部。その下に、はるかに大きな データ基盤 が広がっている、という構図です。

データ基盤を構成する要素として、次の3つが挙げられていました。

データストレージ & 管理
データ処理 & 変換
データカタログ & ガバナンス

派手な AI 機能はあくまで氷山の一角であり、それを支える足元のデータ基盤こそが本質、というメッセージが印象的でした。

Agentic AI におけるデータの障壁

続いて、エージェンティック AI を実現するうえで立ちはだかる データの障壁 が4つ提示されました。

データの分断とサイロ化 — データが各所に散在し、横断的に扱えない
パフォーマンスとスケーラビリティ — データ量の増大に処理が追いつかない
データ品質とガバナンス — 信頼できるデータを維持・統制する難しさ
セキュリティと信頼性 — 安全に、かつ安定してデータを扱えるか

AI の高度化が進むほど、こうした足元の課題がボトルネックとして効いてくる、という整理です。

Apache Iceberg というオープンテーブルフォーマット

これらの障壁に対する解として登場するのが Apache Iceberg です。スライドでは「Agentic AI 時代のデータ基盤を支えるオープンテーブルフォーマット」と位置づけられ、主な特徴として次の4点が挙げられていました。

ACID トランザクション — 複数の書き込みでも一貫性を保てる
スキーマ進化 — テーブル定義を安全に変更できる
クエリパフォーマンス — メタデータを活かした効率的なスキャン
タイムトラベル — 過去時点のスナップショットを参照できる

データレイクの柔軟さを保ちながら、データウェアハウス並みの信頼性を持ち込める点が Iceberg の強みです。

Apache Iceberg V3

さらに、最新の Apache Iceberg V3 仕様についても触れられていました。スライドでは4つの強化ポイントが挙げられていました。

Variant データ型 — 半構造化データを効率的に取り扱う
削除ベクトル(deletion vectors) — 書き込み性能の最適化
行リネージ(row lineage) — スケーラブルな変更追跡
デフォルト値 — データ処理を標準化および簡素化

半構造化データへの対応や変更追跡の強化など、エージェンティック AI のワークロードを見据えた進化が続いている、というアップデートでした。

なお、ここで挙がっているのは Apache Iceberg V3 仕様としての機能です。執筆時点で AWS がサポートを明言しているのは 削除ベクトルと行リネージ で、Spark 経由の Amazon EMR 7.12 以降 / AWS Glue / Amazon SageMaker Unified Studio ノートブック / Amazon S3 Tables が対象です（Amazon Athena (Trino) は V3 未対応）。実際に採用する際は、利用するエンジンの V3 対応状況を確認しておくと安心です。

第2章 AWS スタックの全体像

AWS アナリティクススタック

第2章では、Iceberg を AWS 上で扱うための アナリティクススタック全体像 が示されました。スライドは、下から上へ積み上がるレイヤー構造で描かれていました。

データソース — ビジネスアプリケーション / オペレーショナルデータベース / データウェアハウス / ストリーミング / 他のデータソース / Iceberg REST カタログ
取り込み — AWS Glue / Amazon EMR / Amazon MSK / Amazon MSF / Amazon Data Firehose
ストレージ — Amazon S3 / Amazon S3 Tables / Redshift Managed Storage (RMS)
処理 — AWS Glue / Amazon EMR / Amazon Redshift / Amazon Athena / 3P Apache Iceberg 互換エンジン
活用 — Amazon Bedrock(生成 AI / ML)/ Amazon Quick(Agentic AI / BI)/ Amazon SageMaker Unified Studio / ISV ソリューション

これらを横断する形で、左側に Zero-ETL、右側に カタログ & ガバナンス の柱が立っています。カタログ & ガバナンスは、Amazon SageMaker Catalog(ビジネスカタログ)、AWS Lake Formation(統合アクセス制御)、AWS Glue Data Catalog(テクニカルカタログ)の3層構成で、クエリフェデレーション／カタログフェデレーションによって外部データソースともつながります。

各レイヤーに複数のサービスが対応づき、Amazon S3 / S3 Tables を中心としたストレージの上で、Iceberg を共通フォーマットとして処理・活用していく、という統合像でした。

AWS Glue Data Catalog

スタックの中核となるのが AWS Glue Data Catalog です。さまざまな分析エンジンから共通で参照できる中央メタデータカタログとして、次のような特徴が紹介されました。

高可用性・スケーラビリティ・耐久性
高水準のセキュリティ・コンプライアンス・監査機能
サーバーレスで優れたコスト効率
外部メタデータストアのフェデレーション
Hive Metastore API 互換
オープンテーブルフォーマット対応 — Apache Iceberg / Delta Lake / Apache Hudi

特定のフォーマットに縛られず、Iceberg を含む主要なオープンテーブルフォーマットを横断的に扱える点が強調されていました。

Glue Data Catalog による Iceberg テーブルの自動最適化

Glue Data Catalog は、Iceberg テーブルの 運用管理を自動化 してくれます。スライドでは3つの自動最適化が挙げられていました。

コンパクション — スモールファイルを自動的に大きなファイルへ統合してクエリパフォーマンスを向上。さらに Sort / Z-order でのクエリパターンに応じたデータ配置にも対応
スナップショット管理 — 古いスナップショットを自動削除し、ストレージコストを削減
孤立ファイルの削除 — メタデータから参照されていないファイルを定期的に特定して削除

Iceberg テーブルは運用を続けると小さなファイルや不要なスナップショットが溜まり、放置すると性能やコストに効いてきます。これらを自動で面倒見てくれるため、手作業のメンテナンス負荷を大きく下げられます。

カタログフェデレーション（リモート Iceberg カタログ）

最後に、カタログフェデレーション の話題がありました。リモートの Iceberg カタログを Glue Data Catalog 経由で扱う仕組みで、ポイントは次の4つです。

データの移動や複製なし に、リモートカタログ経由で Amazon S3 上の Iceberg テーブルへ直接アクセス
Glue Data Catalog とリモートカタログ間の リアルタイムメタデータ同期 で、最新のクエリ結果を保証
AWS の分析エンジンからデータを発見・読み取り 可能
リモートテーブルへ きめ細かい権限 を適用し、一貫したセキュリティポリシーを確保

既存のカタログ資産をそのまま活かしながら、データをコピーすることなく AWS のエコシステムから統一的にアクセスできる、という点が実運用で効いてきそうです。

Amazon S3 Tables — フルマネージドな Iceberg テーブル

ストレージ層の選択肢として Amazon S3 Tables が紹介されました。これは「フルマネージドの Apache Iceberg テーブル」と位置づけられたバケットタイプで、運用最適化が標準で組み込まれています。

コンパクション — スモールファイルを自動的に大きなファイルへ統合し、クエリパフォーマンスを向上
スナップショット管理 — スナップショットの保持期間を管理し、タイムトラベルを維持しながらストレージコストを最適化
孤立ファイルの削除 — テーブルスナップショットから参照されていないすべてのオブジェクトを特定して削除

前述の Glue Data Catalog による自動最適化と同等の運用を、S3 Tables 側で完結して受けられるイメージです。

S3 汎用バケットと S3 テーブルバケットの比較

では、従来の S3 汎用バケット と S3 テーブルバケット をどう使い分けるのか。両者の違いが整理されていました。

S3 汎用バケット

S3 汎用バケットと Glue Data Catalog を組み合わせて Iceberg テーブルを構成
Key / Prefix の設計や、テーブルを構成するデータを直接管理する
カスタマイズ性が高く、Iceberg や S3 の機能を隅々まで活かせる
Glue Data Catalog によってコストと性能の自動最適化が可能

S3 テーブルバケット

表形式データに最適化されたバケットタイプで、フルマネージドな Iceberg テーブル
API のみを通じて、テーブルの内部的な仕組みを意識することなく、安全かつ効率的に Iceberg を利用できる
S3 テーブルバケット単独でコストと性能の自動最適化機能を備える

細かく作り込みたいなら汎用バケット + Glue、手早くフルマネージドで始めたいならテーブルバケット、という棲み分けですね。

第3章実装パターン

Iceberg への取り込みに使える AWS サービス

第3章は実装パターンの話です。導入として、Iceberg テーブルへデータを取り込む際に利用できる代表的な AWS サービス が4つ整理されました。

AWS Glue — サーバーレスでスケーラブルなデータ統合サービス
Amazon EMR — Apache Spark、Trino、Flink、Hive などのマネージドクラスター
Amazon Data Firehose — ストリーミングデータをリアルタイムで配信するフルマネージドサービス
Amazon Managed Service for Apache Flink (MSF) — Apache Flink のフルマネージドサービス

バッチ処理(Glue / EMR)からストリーミング(Data Firehose / MSF)まで、ユースケースに応じて選択肢が用意されている、という全体像でした。

Apache Iceberg によるメダリオンアーキテクチャ（Bronze / Silver / Gold）

実装パターンの中心として紹介されたのが、Iceberg の機能を活かした メダリオンアーキテクチャ です。データを Bronze → Silver → Gold の3層で磨き上げていく構成で、各層で効く Iceberg の機能と運用ポイントがセットで示されました。

ブロンズ（生データ）

スキーマ進化 — ソースの変更への追従
ACID トランザクション — 複数ライターからの同時書込
スナップショット期限管理 — 低コストでの長期保存
ポイント: 生データを無期限に保持し、S3 ライフサイクルで Glacier へ

シルバー（クレンジング）

MERGE INTO — 差分データの効率的な反映
パーティション進化 — データ量の変化への適用
タイムトラベル — 変換処理失敗時の切り戻し
ポイント: 更新には MERGE を使用し、定期的にコンパクションを実施

ゴールド（分析）

マテリアライズドビュー — 集約テーブルを効率的に維持
Sort / Z-order — クエリパターンに応じた配置
自動コンパクション — ファイルを常に最適化
ポイント: Sort / Z-order コンパクション、30 日間のスナップショット保持

各層で「どの Iceberg 機能を使い、どう運用するか」が明確になっており、そのまま設計の土台にできる完成度でした。

Iceberg を利用できるクエリエンジン

磨き上げたデータを活用する側として、Iceberg テーブルを読めるクエリエンジンが4つ紹介されました。

AWS Glue — サーバーレスでスケーラブルなデータ統合サービス
Amazon EMR — Spark、Trino、Flink、Hive 等のマネージドクラスター
Amazon Athena — インタラクティブなサーバーレス分析サービス
Amazon Redshift — フルマネージドのペタバイトスケールのデータウェアハウス

同じ Iceberg テーブルを、用途に応じて複数のエンジンから読めるのがオープンテーブルフォーマットの強みです。

AWS Glue のマテリアライズドビュー

ゴールド層の集約を効率化する仕組みとして、AWS Glue のマテリアライズドビュー が取り上げられました。CREATE MATERIALIZED VIEW AS SELECT ... でビューを定義すると、次のような流れで事前計算済みデータが生成されます。

複数の Iceberg テーブル を入力にする
AWS Glue Data Catalog がビュー定義と計算を担う
結果を 事前計算済みデータ（Amazon S3 / S3 Tables 上の Iceberg）として保持
Amazon Redshift / Athena / EMR など複数エンジンからクエリ

集約処理を都度実行せず、事前計算済みの結果を使い回せるため、分析クエリのコストとレイテンシを抑えられます。

バッチ ETL の取り込みパターン（パターン1）

実装パターンの1つ目は バッチ ETL です。スライドでは、アナリティクススタックの各レイヤー（ソース → 取り込み → ストレージ → カタログ & ガバナンス → 処理 → 活用）を背景に、勘所が「設計上のポイント」「運用上のポイント」の2軸で整理されていました。

設計上のポイント

パーティション進化 — データ量やクエリパターンの変化に応じてパーティション戦略を適用する
レコードレベル更新 — MERGE・UPDATE・DELETE でデータを変更し、読み取り性能重視の場合は Copy-on-Write が最適

運用上のポイント

ファイルサイズ — 128〜512MB を目安に設定する
ソート戦略 — クエリパターンに応じて Sort / Z-order を適用する
テーブル管理 — コンパクション・スナップショット期限・列統計を整備する

ストリーミングの取り込みパターン（パターン2）

2つ目は ストリーミング の取り込みパターンです。低レイテンシでの書き込みが求められる分、バッチとは異なる勘所が示されました。

設計上のポイント

スモールファイル前提の設計 — シャッフルなしで書き込みレイテンシを最小化し、コールドパーティションをコンパクションする
Merge-on-Read を検討 — 読み取りエンジンの対応状況により採用を判断。読み取り前にコンパクションで統合する選択肢もある
ファイルフォーマットの選択 — 書き込み性能重視の場合は Avro で書き込み、コンパクション時に Parquet へ変換する

運用上のポイント

定期的なコンパクション — 自動コンパクションを活用する
スナップショットの期限管理 — メタデータの肥大化を防止する
競合の監視 — コミットリトライ率を追跡し、競合増加時に並行度を調整する

バッチとストリーミングで設計・運用のポイントが対比的に整理されており、ユースケースに応じてどちらのパターンを採るか、その際に何を押さえるべきかが明確でした。

まとめ

セッションの締めくくりとして、全体の要点が3つに整理されました。

従来のデータレイクの課題や Agentic AI の発展により、データ基盤としてレイクハウス が求められている。Apache Iceberg はそれを支えるオープンテーブルフォーマットである
AWS アナリティクススタック が、データの取り込みから活用まで各レイヤーで Apache Iceberg をサポートする。Glue Data Catalog・S3 Tables 等で運用負荷を最小化できる
ユースケースに応じた取り込みパターンの選択 が重要。バッチ ETL とストリーミングで、それぞれの設計・運用上のプラクティスを参考に構築する

Iceberg を「なぜ使うのか」から「AWS でどう組むか」「どう取り込み・活用するか」までを一気通貫で押さえられる、実践志向の濃いセッションでした。氷山の図で示された通り、派手な AI 機能の足元にある データ基盤 をいかに堅牢に作るかが、エージェンティック AI 時代の競争力を左右する——そんなメッセージが強く残りました。