Apache Icebergとは：レイクハウスの新標準と、その実装の中身

「Snowflakeに入れたデータをBigQueryからも読みたい」「Databricksで作ったデータを他のエンジンでも分析したい」。データのベンダーロックインを避けたいニーズは、データ基盤の規模が大きくなるほど切実になります。Apache Icebergは、この「データのオープン化」を技術的に支える、いま最も注目されているテーブルフォーマットです。

2017年にNetflixが社内開発し、Apacheソフトウェア財団に寄贈されたOSSです。Snowflake、BigQuery、Databricks、Trino、Spark、Flinkといった主要なクエリエンジンが対応しており、「データを1か所に置いて、複数のエンジンから読む」アーキテクチャを成立させます。実装の中身と運用設計を順に解説します。

Icebergの3層メタデータ構造

Icebergのテーブルは「データファイル」と「メタデータ」の2つで構成されます。メタデータは3層に分かれており、これが大規模テーブルでの性能と、ベンダー中立性を支えています。

この3層構造により、巨大テーブルでも「クエリに関係するファイルだけを高速に絞り込む」（プルーニング）ができます。Manifest内の統計情報を使い、ファイルレベルで枝刈りをするため、Hiveのような「ディレクトリリスト走査」と比べて何桁も速くなります。

隠しパーティション（Hidden Partitioning）

Icebergの特徴的な機能が「隠しパーティション」です。従来のHiveでは、`/year=2026/month=06/day=13/`のように物理ディレクトリでパーティションを切り、利用者はWHERE句に`year=…`と書く必要がありました。Icebergでは、パーティション情報をメタデータで管理し、利用者は「ordered_at」のような通常のカラムだけ書けば、Icebergが内部でパーティションプルーニングを行います。

-- パーティションをordered_atの日次で定義（テーブル作成時）
CREATE TABLE orders (
  order_id BIGINT,
  customer_id BIGINT,
  ordered_at TIMESTAMP,
  order_total DECIMAL(10,2)
)
PARTITIONED BY (days(ordered_at));

-- 利用者はordered_atで普通にWHEREを書くだけ
SELECT * FROM orders WHERE ordered_at >= '2026-06-01';
-- Icebergが内部でdays(ordered_at)に変換し、適切なファイルだけ読む

これにより、パーティション戦略を後から変えてもクエリを書き換える必要がありません。「Hiveの最大の運用負荷」がIcebergで解消されます。

タイムトラベルとスナップショット

Icebergは書き込みのたびに「スナップショット」を作ります。過去の状態を後から参照できるタイムトラベル機能が標準で備わります。

-- 過去のスナップショットIDで読む
SELECT * FROM orders FOR VERSION AS OF 12345;

-- タイムスタンプで読む（過去時点の状態）
SELECT * FROM orders FOR TIMESTAMP AS OF '2026-06-01 00:00:00';

「昨日時点のデータで分析したい」「事故が起きる前の状態に戻したい」といった要件に、コードの変更だけで応えられます。SCDの履歴管理はdbt snapshotsでSCD Type 2を参照してください。

カタログの選び方

Icebergの「Catalog」は、テーブル名から最新メタデータへのポインタを管理します。複数の実装があり、選び方が重要です。

「どのクエリエンジンが同じカタログを参照するか」が選定の起点です。マルチエンジン運用なら、REST Catalogプロトコルに対応したNessieやPolarisが将来性高いです。

主要クエリエンジンの対応

2024年のDatabricks/Tabular買収以降、業界全体でIceberg互換性を強化する方向に動いています。各クラウドDWHの基本はクラウドDWH入門、Snowflake固有の話はSnowflakeとはを参照してください。

運用上のハマりどころ

• 小さなファイルの蓄積：書き込みのたびに小さなParquetファイルが増え、読み取り性能が下がる。定期的なcompactionが必要。
• 古いスナップショットの肥大化：書き込み履歴が積み重なり、ストレージが膨らむ。`expire_snapshots`で古いスナップショットを削除する運用を組む。
• カタログの整合性：複数のエンジンから書き込むときに、カタログを介した排他制御が要る。OCC（楽観的排他制御）の仕組みを理解する。
• パーティション戦略の変更：隠しパーティションのおかげで戦略を変えやすいが、変更前の古いデータには適用されない点に注意。

向く・向かない場面

• 向く：複数のクエリエンジンからデータを使いたい、データのオープン化を進めたい、巨大テーブルの効率を求める、新規プロジェクトで将来性重視
• 向かない：Databricks中心で他のエンジンを使わない（→Delta Lake）、更新と削除が極めて多い独自要件（→Hudi）、簡単な小規模データ（テーブルフォーマット自体が不要）

まとめ

• Apache IcebergはNetflix発の、ベンダー中立を強みとするテーブルフォーマット。
• 3層メタデータ構造で、巨大テーブルでも高速にプルーニング。
• 隠しパーティション・タイムトラベル・スキーマ進化が標準で備わる。
• Snowflake・BigQuery・Databricks他、主要クエリエンジンが対応を進行中。
• 新規レイクハウスプロジェクトの「無難で将来性のある選択」になりつつある。

全体像はレイクハウステーブルフォーマット比較、隣接の選択肢はDelta Lake とは・Apache Hudi とはにあります。Icebergの導入や設計の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。

よくある質問（FAQ）

Q. IcebergとDelta、どちらを選ぶべきですか？

A. 既にDatabricksで作り込んでいるならDelta、新規でベンダーを限定したくないならIcebergが基本線です。2024年以降の業界の流れは「Iceberg互換性を全方位で強化」する方向で、DatabricksもUniFormでIceberg互換読み取りを提供しています。「将来Snowflake/BigQueryからも読みたい」可能性があるなら、Icebergで書く判断が安全です。

Q. Snowflake Native Iceberg Tablesと、External Iceberg Tablesの違いは？

A. Snowflakeが書き込み・カタログ管理まで担当するのがNative、データの実体は外部ストレージにIceberg形式で置きつつ、Snowflakeはカタログ参照だけするのがExternalです。Nativeはマネージドの安心、Externalはデータ所有権を自社で保つ、と整理できます。マルチエンジンで読み書きしたいなら、External＋共有カタログ（PolarisやUnity）が将来性ある構成です。

Q. compactionはいつ走らせるべきですか？

A. 書き込み頻度に応じて変わります。日次バッチ書き込みなら週次compactionで足り、リアルタイムストリーミングなら数時間ごとが目安です。「小さなファイルが100万個」のような状態になる前に手を打ちます。Spark/TrinoのプロシージャCALL で実行できるので、オーケストレーターから定期実行する運用が定石です。

Q. Icebergで作ったテーブルを、Snowflakeから書き込みできますか？

A. Native Iceberg Tablesなら可能です。Snowflakeが書き手として動き、外部カタログ（Polaris等）と連携できます。External Iceberg Tablesは原則読み取り専用です。「どこから書き込み、どこから読むか」を設計初期に決めると、後の運用が安定します。