【AWS】Iceberg データレイクハウスの高度な設計 — Lake Formation・マルチエンジン連携・本番運用
はじめに
本シリーズでは Apache Iceberg on AWS を段階的に解説してきました。
- 第 1 弾「Apache Iceberg 実践入門」: Iceberg の基本概念と Athena での操作、メダリオンアーキテクチャ
- 第 2 弾「運用コスト最適化」: コンパクション・スナップショット管理・ストレージ戦略のコスト最適化
- 第 3 弾「Data Firehose ストリーミング取り込み」: CDC パイプラインとコンパクション戦略
ここまでの内容で、Iceberg テーブルの作成・運用・ストリーミング取り込みの基盤は整いました。しかし、エンタープライズ環境での本番運用には、まだ解決すべき課題が残っています。
- 誰が何のデータにアクセスできるかを、列レベル・行レベルで制御したい
- 複数の分析エンジン（Athena、Redshift、EMR、Glue）を同じ Iceberg テーブルに対して使い分けたい
- 外部カタログ（Snowflake、Databricks）のテーブルも統合的にクエリしたい
- テーブルメンテナンスを完全自動化し、運用負荷をゼロに近づけたい
この記事では、Iceberg データレイクハウスを本番環境で運用するための高度な設計パターンを解説します。Lake Formation によるきめ細かなアクセス制御、マルチエンジンの適材適所な使い分け、Glue Data Catalog の最新機能、そして本番運用のメンテナンス自動化までをカバーします。
この記事で得られること：
- Lake Formation によるテーブル/列/行/セルレベルのアクセス制御設計
- ハイブリッドアクセスモードによる段階的な Lake Formation 移行パターン
- Athena / Redshift / EMR / Glue の役割分担と使い分けの判断基準
- カタログフェデレーション・マテリアライズドビュー・Iceberg REST Catalog の活用
- Glue テーブルオプティマイザによるメンテナンス完全自動化
Lake Formation によるアクセス制御
なぜ IAM だけでは不十分なのか
Iceberg テーブルの実データは S3 に保存されるため、IAM ポリシーで S3 バケットやプレフィックスへのアクセスを制御できます。しかし、IAM ベースの制御には根本的な限界があります。
| 要件 | IAM ポリシー | Lake Formation |
|---|---|---|
| テーブル単位のアクセス制御 | S3 プレフィックスで近似 | テーブル名で直接制御 |
| 列レベルの非表示 | 不可 | データフィルタで制御 |
| 行レベルのフィルタリング | 不可 | データフィルタで制御 |
| セルレベル（列+行の組み合わせ） | 不可 | データフィルタで制御 |
| クロスアカウント共有 | S3 バケットポリシー | Lake Formation で一括管理 |
たとえば「営業部門には customers テーブルを見せるが、email 列は非表示にする」「テナント A のユーザーには tenant_id = 'A' の行だけを返す」といった要件は、IAM だけでは実現できません。
AWS Lake Formation は Glue Data Catalog に登録された Iceberg テーブルに対して、スコープ付きクレデンシャルを分析エンジンに発行することで、きめ細かなアクセス制御を実現します。
2026 年 3 月のアップデート: S3 Tables と Iceberg マテリアライズドビューに限り、Glue Data Catalog が IAM ベースの認可をサポート開始しました。ストレージ・カタログ・クエリエンジンの権限を単一の IAM ポリシーで定義でき、Lake Formation なしでもテーブルレベルのアクセス制御が可能です。列/行レベルの制御が不要で S3 Tables を使用する場合は、IAM ベースの認可で十分なケースもあります。
アクセス制御の 4 つのレベル
Lake Formation のデータフィルタ機能で、4 段階の粒度でアクセスを制御できます。
| レベル | 説明 | ユースケース |
|---|---|---|
| テーブルレベル | テーブル全体の読み取り/書き込み制御 | 部門別のテーブルアクセス制限 |
| 列レベル | 特定カラムの表示/非表示 | PII（個人情報）カラムの保護 |
| 行レベル | 行フィルタによる条件付きアクセス | テナント別データの分離 |
| セルレベル | 列フィルタ + 行フィルタの組み合わせ | 最も粒度の細かい制御 |
実装例 — データフィルタの定義:
データフィルタ名: SalesTeamFilter
対象テーブル: analytics.customers
列アクセス: customer_id, name, region, purchase_history を許可
email, phone, address を除外
行フィルタ: region = 'ap-northeast-1'
このフィルタを営業チームの IAM ロールに付与すると、そのロールが Athena や EMR 経由で analytics.customers をクエリした際、自動的に email, phone, address が非表示になり、region = 'ap-northeast-1' の行だけが返されます。
対応エンジンと制約
| エンジン | テーブル | 列 | 行 | セル | 備考 |
|---|---|---|---|---|---|
| Athena | ✓ | ✓ | ✓ | ✓ | フル対応 |
| EMR (Spark) | ✓ | ✓ | ✓ | ✓ | EMR 6.15.0+ / 7.7+、Spark SQL |
| EMR on EKS | ✓ | ✓ | ✓ | ✓ | EMR 7.7+（2025 年 2 月〜） |
| Glue ETL | ✓ | ✓ | ✓ | ✓ | Glue 4.0+ |
| Redshift Spectrum | ✓ | ✓ | ✓ | ✓ | フル対応 |
全エンジンが Lake Formation のデータフィルタに対応しており、エンジン選択をアクセス制御の観点で制限する必要はありません。
2026 年 2 月のアップデート: Glue 5.1 で Lake Formation の細粒度アクセス制御が書き込み操作（DML/DDL）にも拡張されました。従来は読み取り操作のみが対象でしたが、Spark DataFrames および Spark SQL による書き込みにも Lake Formation 権限が適用されるようになり、データガバナンスの一貫性が向上しています。
ハイブリッドアクセスモード — 段階的移行の実践
Lake Formation を既存環境に導入する際の最大の懸念は、既存の IAM ベースのアクセスが壊れないかです。ハイブリッドアクセスモードはこの課題を解決します。
仕組み:
同じ Iceberg テーブルに対して、Lake Formation 管理のユーザーと IAM 管理のユーザーを共存させることができます。
-
Opted-in プリンシパル: Lake Formation 権限 + IAM 権限の両方が必要
-
非 Opted-in プリンシパル: 従来通り IAM 権限のみでアクセス
-
[Opted-in] data-analyst-role: Lake Formation のデータフィルタ適用（列制限: email, phone を非表示 / 行制限: region = 'ap-northeast-1'）
-
[非 Opted-in] legacy-etl-role: IAM ポリシーのみでアクセス（全列・全行にアクセス可能、従来通り）
段階的移行のステップ:
- Phase 1: ハイブリッドアクセスモードを有効化。既存の全ユーザーは非 Opted-in のまま
- Phase 2: 新規ユーザーを Opted-in として追加。Lake Formation のデータフィルタを設定
- Phase 3: 既存ユーザーを順次 Opted-in に移行。動作確認後に IAM ポリシーのデータアクセス権限を削除
- Phase 4: 全ユーザーの移行完了後、ハイブリッドモードを無効化（任意）
移行時の注意点:
- Lake Formation 管理テーブルに書き込むには、IAM ロールに
DATA LOCATION権限の付与が必要です - 移行期間中は IAM ポリシーと Lake Formation 権限の二重管理が発生するため、権限の棚卸しを並行して進めます
- テスト環境で Opted-in 切り替えの動作を十分に検証してから本番に適用します
クロスアカウント共有
Lake Formation は Iceberg テーブルのクロスアカウント共有もサポートしています。データ分析基盤を複数の AWS アカウントで運用する場合に有効です。
共有の流れ:
- 共有元アカウントで Lake Formation 権限を設定（テーブル/列/行レベル）
- AWS RAM（Resource Access Manager）または Lake Formation の直接共有で共有先アカウントに権限を付与
- 共有先アカウントで Resource Link を作成し、自アカウントの Glue Data Catalog に登録
- 共有先のユーザーは Resource Link 経由でクエリ（共有元のアクセス制御が自動適用）
クロスアカウントでも列レベル・行レベルの制御が適用されるため、部門別アカウント構成でもきめ細かなデータガバナンスを維持できます。
マルチエンジン連携 — 適材適所の使い分け
エンジン別の役割と機能マトリクス
Iceberg データレイクハウスの強みは、同じテーブルに対して複数のエンジンがそれぞれの強みを発揮できることです。Glue Data Catalog を中心に、全エンジンが同じメタデータを共有します。
| エンジン | 主な役割 | Iceberg 書き込み | 強み |
|---|---|---|---|
| Athena | アドホッククエリ、軽量 ETL | ✓（CRUD + OPTIMIZE + VACUUM） | サーバーレス、即座に利用可能、VACUUM 無料 |
| Redshift | 大規模結合、BI 連携 | ✓（CREATE TABLE + INSERT）※制限あり | マテリアライズドビュー、同時接続性能 |
| EMR (Spark) | 大規模 ETL、ML 前処理 | ✓（フル CRUD + コンパクション） | 柔軟性、カスタムロジック、ライブラリ |
| Glue ETL | スケジュール ETL、ストリーミング | ✓（フル CRUD） | マネージド Spark、自動スケール、低運用負荷 |
使い分けの指針:
- 「とりあえずクエリしたい」 → Athena（インフラ不要、SQL だけで始められる）
- 「BI ダッシュボードに接続したい」 → Redshift（QuickSight / Tableau との統合性能）
- 「複雑な ETL・ML パイプラインを実行したい」 → EMR Spark（PySpark / Scala の自由度）
- 「定期バッチをマネージドに実行したい」 → Glue ETL（スケジューリング + 自動スケール）
Redshift の Iceberg 書き込み（2025 年 11 月 GA）
2025 年 11 月に GA となった Redshift の Iceberg 書き込みにより、データウェアハウスとデータレイクの境界がさらに薄くなりました。Redshift で集計・変換した結果を Iceberg テーブルに書き出し、他のエンジンから参照するパターンが可能になります。
サポートされる SQL:
-- Iceberg テーブルの作成（CTAS）
CREATE TABLE analytics.daily_summary
USING ICEBERG
LOCATION 's3://my-data-lake/warehouse/daily_summary'
AS SELECT
region,
product_category,
DATE_TRUNC('day', sale_time) AS sale_date,
COUNT(*) AS order_count,
SUM(amount) AS total_revenue
FROM raw_data.transactions
GROUP BY 1, 2, 3;
-- データの追加
INSERT INTO analytics.daily_summary
SELECT region, product_category,
DATE_TRUNC('day', sale_time), COUNT(*), SUM(amount)
FROM raw_data.transactions
WHERE sale_time >= CURRENT_DATE - INTERVAL '1 day'
GROUP BY 1, 2, 3;
-- テーブル定義の確認
SHOW TABLE analytics.daily_summary;
-- テーブルの削除
DROP TABLE analytics.daily_summary;
サポートされない SQL（2026 年 2 月時点）:
-
UPDATE,DELETE,MERGE INTO,ALTER TABLE
⚠️ 重要: Redshift から Iceberg テーブルへの書き込みは INSERT / CTAS のみ（追記型ワークロード限定） です。CDC パイプライン（第 3 弾参照）で必要な
MERGE INTOによる行レベルの更新・削除は Redshift では実行できません。CDC ワークロードでは Athena の MERGE INTO または EMR Spark を使用してください。
Redshift Iceberg 書き込みの適切なユースケース:
- BI ダッシュボード用のサマリーテーブルを Iceberg で作成し、Athena / EMR からも参照
- Redshift 内の DWH データを Iceberg テーブルにエクスポートし、データレイクに統合
- 日次集計結果の追記型書き出し（DELETE 不要のユースケース）
エンジン間の同時実行制御
複数のエンジンが同じ Iceberg テーブルにアクセスする場合、同時実行の安全性が重要になります。Iceberg の楽観的同時実行制御がこれを保証します。
書き込みの流れ:
- Writer が現在の
metadata.jsonを読み取り、書き込み対象を決定 - 新しいデータファイルを S3 に書き込み、新しい
metadata.jsonを作成 - Glue Data Catalog のカタログポインタを If-Match 条件付きでアトミックに更新
- 別の Writer が先にコミットしていた場合はコンフリクトが検出され、リトライ
書き込み対象の分離がベストプラクティス:
エンジン間でコンフリクトを最小化するため、書き込み対象を明確に分離します。
- Firehose: Bronze データの書き込み（INSERT のみ、ホットパーティション）
- Glue ETL: Silver/Gold への変換書き込み（MERGE INTO、コールドパーティション）
- Athena: アドホッククエリ（読み取り専用）+ VACUUM
- Redshift: BI クエリ（読み取り専用）+ サマリー書き出し
同じパーティションへの同時書き込みを避けることで、リトライの頻度を最小限に抑えられます。Firehose がホットパーティション（当日分）に書き込み、Glue ETL がコールドパーティション（過去分）を変換する——という時間軸での分離が効果的です。
Glue Data Catalog の高度機能
前セクションで見たように、マルチエンジン連携の中心にはすべてのエンジンが共有する Glue Data Catalog があります。この Glue Data Catalog 自体も、2025 年の re:Invent で発表された新機能により、単なるメタデータストアから Iceberg データレイクハウスの統合プラットフォームへと進化しています。
カタログフェデレーション — 外部 Iceberg カタログの統合
2025 年 11 月に発表されたカタログフェデレーションにより、外部の Iceberg カタログのテーブルをデータのコピーなしで AWS 分析エンジンからクエリできるようになりました。
対応カタログ:
- Snowflake Polaris Catalog
- Databricks Unity Catalog
- Apache Iceberg REST 仕様準拠のカスタムカタログ
仕組み:
外部カタログ（Snowflake Polaris / Databricks Unity）と Glue Data Catalog（Federated Connection）がメタデータを同期し、Athena・Redshift・EMR からクエリできます。
メタデータはリアルタイムで同期され、外部カタログのスキーマ変更やデータ更新が即座に反映されます。Lake Formation のアクセス制御もフェデレーテッドテーブルに適用できるため、外部データに対しても列レベル・行レベルのセキュリティを維持できます。
ユースケース:
- マルチクラウド環境で Snowflake と AWS の両方に分散したデータを統合分析
- 買収した企業の Databricks 環境のデータを、データ移行なしで即座にクエリ
- パートナー企業が公開する Iceberg REST Catalog のデータにセキュアにアクセス
マテリアライズドビュー — Iceberg ベースの事前計算
2025 年 11 月に発表された Glue Data Catalog のマテリアライズドビューは、SQL クエリの事前計算結果を Iceberg テーブルとして保存し、インクリメンタルに自動更新する機能です。
仕組み:
-- マテリアライズドビューの作成（Spark SQL）
CREATE MATERIALIZED VIEW analytics.events_daily_summary
AS SELECT
region,
product_category,
DATE_TRUNC('day', event_time) AS event_date,
COUNT(*) AS event_count,
SUM(revenue) AS total_revenue
FROM analytics.events
GROUP BY 1, 2, 3;
ソーステーブルに新しいデータが書き込まれると、Glue が変更分だけを検知して差分更新を実行します。フルリフレッシュではなくインクリメンタル更新のため、計算コストが大幅に抑えられます。
効果:
- クエリ性能が最大 8 倍向上（事前集計済みのデータを直接参照するため）
- コンピュートコスト削減（スキャンデータ量が劇的に減少）
- パイプラインの簡素化（集約・フィルタ・結合を SQL で定義するだけで、バッチジョブが不要に）
自動クエリリライト:
AWS マネージド Spark エンジン（Athena、EMR、Glue）がクエリを実行する際、マテリアライズドビューで回答可能なクエリを自動的にリライトします。ユーザーはマテリアライズドビューの存在を意識せずに高速なクエリ結果を得られます。
注意: マテリアライズドビューの作成と自動クエリリライトは AWS マネージド Spark エンジン限定の機能です。Iceberg REST Catalog 経由で接続する OSS Spark からは利用できません。
要件:
- Spark 3.5.6 以上（Athena、EMR、Glue）
- AWS Glue 5.1 以上
- ストレージ: S3 汎用バケットまたは S3 Tables
Iceberg REST Catalog エンドポイント
Glue Data Catalog は Apache Iceberg REST Catalog 仕様に準拠した REST API を公開しています。これにより、AWS マネージドサービスだけでなく、サードパーティエンジンからも Glue Data Catalog の Iceberg テーブルに直接接続できます。
エンドポイント:
https://glue.{region}.amazonaws.com/iceberg
対応クライアント:
- OSS Apache Spark（Iceberg REST Catalog コネクタ）
- Trino / Presto
- PyIceberg（Python クライアント）
- その他 Iceberg REST Catalog 仕様準拠のクライアント
Spark からの接続例:
spark = SparkSession.builder \
.config("spark.sql.catalog.my_catalog", "org.apache.iceberg.spark.SparkCatalog") \
.config("spark.sql.catalog.my_catalog.type", "rest") \
.config("spark.sql.catalog.my_catalog.uri",
"https://glue.ap-northeast-1.amazonaws.com/iceberg") \
.config("spark.sql.catalog.my_catalog.warehouse", "<AWS_ACCOUNT_ID>") \
.config("spark.sql.catalog.my_catalog.rest.sigv4-enabled", "true") \
.config("spark.sql.catalog.my_catalog.rest.signing-name", "glue") \
.config("spark.sql.catalog.my_catalog.rest.signing-region", "ap-northeast-1") \
.getOrCreate()
# Glue Data Catalog の Iceberg テーブルにクエリ
df = spark.sql("SELECT * FROM my_catalog.analytics.events LIMIT 10")
Iceberg v1 / v2 の両方に対応し、SigV4 認証で AWS の認証基盤とシームレスに統合されます。オンプレミスの Spark クラスタや他クラウドの計算リソースからでも、Glue Data Catalog の Iceberg テーブルに安全にアクセスできます。
本番運用のメンテナンス自動化
Glue テーブルオプティマイザ — 3 つの自動メンテナンス
第 2 弾「運用コスト最適化」ではコンパクションや VACUUM を手動・半自動で実行する方法を解説しました。Glue Data Catalog のテーブルオプティマイザを使えば、これらのメンテナンスを完全自動化できます。
| 操作 | 説明 | デフォルト設定 |
|---|---|---|
| 自動コンパクション | スモールファイルの統合（Binpack / Sort / Z-order） | 100 ファイル超 + 75% 未満でトリガー |
| スナップショット有効期限 | 古いスナップショットのメタデータとデータファイルを削除 | 保持期間: 1 日、最小保持数: 5 |
| 孤立ファイル削除 | メタデータから参照されない不要ファイルを削除 | 日次で自動スキャン |
3 つを組み合わせた運用サイクル:
書き込み（Firehose / Glue ETL）→ 自動コンパクション（100 ファイル超でトリガー）→ スナップショット有効期限（保持期間超のスナップショットを削除）→ 孤立ファイル削除（不要ファイルを検出・削除）の順で自動実行されます。
この 3 つが自動的に連携することで、手動での VACUUM 実行や EMR コンパクションジョブが不要になります。
スナップショット有効期限の設定パラメータ:
| パラメータ | デフォルト | 説明 |
|---|---|---|
snapshotRetentionPeriodInDays |
1 | スナップショットの保持日数 |
numberOfSnapshotsToRetain |
5 | 保持するスナップショットの最小数 |
タイムトラベルで過去データを参照する要件がある場合は、保持日数を延長します。監査要件で 30 日間のデータ参照が必要な場合は snapshotRetentionPeriodInDays = 30 に設定しますが、保持期間が長いほどストレージコストが増加する点に注意してください。
有効化方法:
Glue コンソールのテーブル設定から「テーブルオプティマイザ」を有効化します。新規テーブルに対してはカタログ設定で自動有効化が可能で、一度の設定で以降に作成される全テーブルに適用されます。
テーブルオプティマイザ vs 手動メンテナンスのコスト比較
第2弾で紹介した手動メンテナンスとの比較です。
| 項目 | 手動（Athena OPTIMIZE + VACUUM） | Glue テーブルオプティマイザ |
|---|---|---|
| コンパクション | $5/TB（OPTIMIZE スキャン課金） | $0.44/DPU-hour（DPU 課金） |
| スナップショット管理 | 無料（VACUUM コンピュート無料） | DPU 課金 |
| 孤立ファイル削除 | VACUUM に含む | 自動（DPU 課金） |
| 運用負荷 | Step Functions 等で自動化が必要 | 設定のみ |
| 適するケース | コスト最小化が最優先 | 運用負荷最小化が最優先 |
コスト最優先なら Athena VACUUM（無料）+ 手動コンパクション、運用負荷ゼロを目指すなら Glue テーブルオプティマイザという使い分けが実用的です。テーブル数が増えてくると、テーブルごとの VACUUM スケジュール管理が煩雑になるため、テーブルオプティマイザのメリットが大きくなります。
SageMaker Lakehouse の位置づけ
Amazon SageMaker Lakehouse は、Iceberg を基盤とした統合データアクセスレイヤーです。S3 データレイク、Redshift DWH、外部データソース（カタログフェデレーション経由）を統合的に管理するハブとして機能し、テーブルオプティマイザの自動有効化や Iceberg REST Catalog への標準 API アクセスを統合コンソールから管理できます。
S3 Tables + SageMaker Lakehouse の詳細なアーキテクチャとコスト分析は、第 5 弾「S3 Tables と SageMaker Lakehouse で進化する Iceberg データレイク」で解説します。
エンタープライズアーキテクチャパターン
全体アーキテクチャ
ここまで解説した各要素を統合した、エンタープライズ Iceberg データレイクハウスの全体像です。アーキテクチャは 5 つの層で構成されます。データ取り込み層（Firehose / Glue ETL / カタログフェデレーション）がストレージ層（Iceberg Tables on S3、メダリオンアーキテクチャ）にデータを格納し、分析エンジン層（Athena / Redshift / EMR / Glue）がクエリを実行します。メタデータ管理層（Glue Data Catalog + テーブルオプティマイザ）がテーブル定義と最適化を担い、アクセス制御層（Lake Formation）が全体のセキュリティを統括します。
各層の役割:
| 層 | 役割 | 主な技術要素 |
|---|---|---|
| アクセス制御 | 誰が何にアクセスできるかを一元管理 | Lake Formation データフィルタ |
| メタデータ管理 | テーブル定義、最適化、外部カタログ統合 | Glue Data Catalog + オプティマイザ |
| 分析エンジン | ワークロードに応じたエンジン選択 | Athena / Redshift / EMR / Glue |
| データストレージ | メダリオンアーキテクチャで品質を段階管理 | Iceberg Tables on S3 |
| データ取り込み | バッチ / ストリーミング / 外部カタログ | Firehose / Glue ETL / フェデレーション |
段階的導入ロードマップ
エンタープライズ環境への Iceberg データレイクハウス導入は、一度にすべてを構築するのではなく、段階的に進めるのが現実的です。
Phase 1: 基盤構築（1〜2 ヶ月）
- Athena + Glue Data Catalog で Iceberg テーブルを作成
- メダリオンアーキテクチャ（Bronze / Silver / Gold）を構築
- Glue ETL でバッチ取り込みパイプラインを構築
- テーブルオプティマイザで自動メンテナンスを有効化
Phase 2: アクセス制御の導入（1 ヶ月）
- Lake Formation をハイブリッドアクセスモードで有効化
- 新規ユーザーを Opted-in で追加
- データフィルタ（列/行レベル）を PII 対象テーブルに適用
- 既存ユーザーの段階的移行を開始
Phase 3: マルチエンジン統合（1〜2 ヶ月）
- BI ダッシュボード用に Redshift を追加（Iceberg テーブルのサマリー書き出し）
- ストリーミング要件があれば Firehose による CDC パイプラインを構築（第 3 弾参照）
- マテリアライズドビューで頻出クエリの高速化を検討
- 必要に応じてカタログフェデレーションで外部データを統合
まとめ
Iceberg データレイクハウスの本番運用には、テーブルの作成・クエリだけでなく、アクセス制御、マルチエンジン連携、メンテナンス自動化の 3 つの柱が不可欠です。
本番運用チェックリスト:
アクセス制御:
- Lake Formation でテーブル/列/行レベルのデータフィルタを設定しているか
- ハイブリッドアクセスモードで既存環境への影響を最小化しているか
- クロスアカウント共有が必要な場合、Resource Link を設定しているか
エンジン選定:
- アドホッククエリは Athena、BI 連携は Redshift、大規模 ETL は EMR/Glue と使い分けているか
- エンジン間の書き込み対象を分離し、コンフリクトを最小化しているか
- Redshift Iceberg 書き込みの制限（INSERT/CTAS のみ）を理解しているか
メンテナンス自動化:
- Glue テーブルオプティマイザ（コンパクション + スナップショット有効期限 + 孤立ファイル削除）を有効化しているか
- スナップショット保持期間をタイムトラベル要件に合わせて設定しているか
- マテリアライズドビューで頻出クエリの性能を最適化しているか
Glue Data Catalog の活用:
- カタログフェデレーションで外部データソースを統合しているか（必要な場合）
- Iceberg REST Catalog エンドポイントをサードパーティエンジンに公開しているか（必要な場合）
2025 年の re:Invent で発表されたカタログフェデレーション、マテリアライズドビュー、Redshift Iceberg 書き込み GA により、AWS の Iceberg エコシステムはエンタープライズレベルの成熟度に達しました。Iceberg はもはや「新しい技術」ではなく、AWS データ分析基盤の事実上の標準フォーマットです。
Iceberg シリーズ:
- Apache Iceberg 実践入門 — Athena で始めるモダンデータレイクの設計と運用
- Iceberg テーブルの運用コスト最適化 — コンパクション・メンテナンス・ストレージ戦略
- Iceberg × Data Firehose ストリーミング取り込み — CDC パイプラインとコンパクション戦略
- Iceberg データレイクハウスの高度な設計 — Lake Formation・マルチエンジン連携・本番運用 ← 本記事
- S3 Tables と SageMaker Lakehouse で進化する Iceberg データレイク — 自動最適化とコスト分析