Apache Iceberg：技術仕様の理解とREST Catalogによるマルチエンジン運用の整理

Last updated at 2026-05-12Posted at 2026-05-12

Apache Icebergについて、公式ドキュメントやクラウドベンダーの技術資料に基づき、その設計思想から具体的な運用、エンジンの接続設定までを技術的なつながりに沿って整理しました。

1. 設計思想と内部構造：物理ディレクトリから「論理ファイルリスト」へ

データレイクの従来形式であるApache Hiveは、データを物理的なディレクトリ（フォルダ）構造で管理します。しかし、大規模環境ではクエリ実行計画（プランニング）時にストレージへ大量の「ファイル一覧取得（listリクエスト）」を行う必要があり、データ量が増大するとこれだけで数分を要する課題がありました。

Icebergは、テーブルを物理的なフォルダではなく 「論理的なファイルリスト」 として管理することでこの問題を解決しています。Icebergの構造は以下の三層のメタデータ階層で定義されます。

メタデータファイル (metadata.json): テーブルの現在のスキーマ、パーティション定義、および最新のスナップショット（ある時点でのテーブルの状態）へのポインタを保持するルートファイルです。
マニフェストリスト: 特定のスナップショットを構成するマニフェストファイルの一覧と、各ファイルがカバーするパーティション範囲の統計情報（最小値・最大値など）を保持します。
マニフェストファイル: 個別のデータファイルのパスと、カラムレベルの統計情報を直接管理します。

エンジンはこれらのメタデータを順番に辿るだけで必要なファイルを一義的に特定できるため、ストレージへの物理的なリスト要求を最小限に抑え、プランニング時間を大幅に短縮できます。

2. 運用の実務：詳細な管理ゆえに必要となる「メンテナンス」

Icebergはファイル単位で詳細な追跡を行うため、データの書き込みや更新を繰り返すと、小さなデータファイルや古いスナップショットが蓄積し、逆に性能劣化やコスト増を招く性質があります。性能を維持するためには、以下のメンテナンス処理を定期実行する運用設計が必要です。

コンパクション（小ファイル統合）: 書き込みごとに生成される小さなファイルを、128MB〜512MB程度の適切なサイズにまとめ直します。
スナップショットの有効期限切れ (Snapshot Expiry) : 履歴データが増えすぎないよう、通常7〜30日程度で古いスナップショットを削除し、関連する不要なデータファイルを整理します。
孤立ファイルの削除 (Orphan File Cleanup) : どのメタデータからも参照されなくなった不要な実ファイルを消去します。書き込み中のファイルを誤消去しないよう、3日程度の猶予期間を設けるのが一般的です。

3. カタログの役割とREST Catalogの重要性

第1章で述べた「メタデータ階層」のファイル群は、ストレージ（S3等）上に保存されています。しかし、データが更新されるたびに新しい metadata.json が生成されるため、クエリエンジンは 「数あるファイルの中で、どれが現時点での正解（最新断面）なのか」 という ポインタ（指針） を知る必要があります。

この最新のメタデータファイルへの場所を保持し、ACIDトランザクション（データの不整合を防ぐ仕組み）の起点となるコンポーネントが「カタログ」です。従来、カタログの実装はベンダーごとに異なり（AWS GlueやHive Metastoreなど）、接続するエンジン側で個別の対応が必要でしたが、現在はREST Catalogという標準プロトコルが業界標準となっています。

REST Catalogの重要性は以下の点に集約されます。

相互運用性の向上（マルチエンジンの実現）: OpenAPI仕様に基づいた標準的なHTTP APIを介すことで、Spark, Trino, Athena, Snowflake, BigQueryといった異なるエンジンから、 単一の共通APIで同じテーブルを参照・操作 できるようになります。
サーバーサイドでの制御: コミット操作（データの確定）のロジックをサーバー側に集約できるため、複数のエンジンが同時に書き込みを試みた際の競合解決やリトライがより確実に行われ、信頼性が向上します。
Credential Vending（認証情報の払い出し）: エンジンがカタログにアクセスした際、カタログ側がそのクエリに必要なストレージのパスだけに限定した 「一時的な認証情報」を発行 する仕組みです。これにより、各エンジンにS3のフルアクセスキーなどを永続的に持たせる必要がなくなり、ガバナンスとセキュリティが大幅に向上します。

主な実装例として、オープンソースの Apache Polarisや、Databricksの Unity Catalog 、AWSのS3 Tablesなどが挙げられます。

4. 未実施の調査ポイントとその背景

今後は、さらに高度な運用やマルチエンジン間での一貫性を担保するために、以下の仕様・設定での調査が有用と考えています。

① Iceberg V3仕様における「Deletion Vectors」の挙動と設定

背景: 2025年に登場したIceberg V3仕様 では、行レベルの削除をさらに効率化する 「Deletion Vectors」 が導入されています。
調査ポイント:
- V2までの「Positional/Equality Deletes」との技術的な差異。
- 各エンジン（Spark, Trino等）でこの新仕様を有効化するためのテーブルプロパティ設定。
- 読み取り時のマージ処理が、具体的にどのレイヤーでどのように抽象化されているかの仕様理解。

② REST Catalogを介した「マルチテーブル・トランザクション」の仕様

背景: IcebergのACID特性は原則として「テーブル単位」ですが、REST CatalogやNessieの仕様では、複数のテーブルにまたがるアトミックな更新（マルチテーブル・トランザクション） が検討・実装されつつあります。
調査ポイント:
- REST API仕様で定義されている「CatalogTransaction」プロトコルの詳細。
- 複数テーブルのスキーマ変更を同時に確定させる際の、サーバーサイドでのコミットロジックの制約。

③ カタログ主導の「リモート・サイニング（Remote Signing）」仕様

背景: クライアントがストレージに直接アクセスするための「Credential Vending」以外に、REST Catalog仕様には「Remote Signing」という、カタログ側が署名付きURLを生成して提供する仕組みが存在します。
調査ポイント:
- Credential VendingとRemote Signingの設定の使い分け。
- セキュリティ・ガバナンス上の優位性と、カタログサーバー側に求められるリソース要件の把握。

④ マテリアライズド・ビュー（MV）の共通仕様

背景: Icebergコミュニティでは、特定のクエリエンジンに依存しないマテリアライズド・ビュー（MV）の標準仕様の策定が進んでいます。
調査ポイント:
- MVの定義（SQL）と最新スナップショットの状態を、メタデータファイル内でどのように保持・追跡するかの仕様。
- あるエンジンで作ったMVを、別のエンジンで透過的に「古い断面」として参照する際の一貫性管理。

引用記事一覧

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up