LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Apache Icebergとテーブルフォーマットの基本

Apache Icebergとは、オブジェクトストレージ上に置かれたParquet等のデータファイルに対し、SQLテーブルと同等の一貫性・操作性を与えるオープンなテーブルフォーマットです^*1。公式サイトは「Iceberg is a high-performance format for huge analytic tables」と位置づけ、Spark・Trino・Flink・Presto・Hive・Impalaといった複数のエンジンが同じテーブルを支障なく共有できる点を特徴として挙げています^*1。

従来のHive形式では、テーブルの実体は「特定のディレクトリに含まれるファイル一覧」として暗黙的に定義されており、ディレクトリ構造の変更やパーティション追加がそのまま整合性リスクにつながっていました。Icebergはテーブルの状態をメタデータファイルとマニフェストで明示的に管理する方式に切り替え、この課題に対応する設計になっています^*1。

本稿では、Icebergというテーブルフォーマット固有の仕組み（スキーマ進化・パーティション進化・スナップショット・ACID・対応エンジン）に絞って解説します。DWHの全体構築やデータ変換基盤（dbt）、データ取込（Fivetran）、オーケストレーション（Airflow）といった周辺領域は本稿の対象外です。

スキーマ進化が止めない運用を支える仕組み

Icebergの公式ドキュメントでは、対応するスキーマ変更として「Add（列の追加）」「Drop（列の削除）」「Rename（列名変更）」「Update（型の拡張)」「Reorder（列順の変更）」の5種類を挙げています^*2。これらはいずれもメタデータの更新のみで完了し、既存のデータファイルを書き直す必要がないと説明されています^*2。

この堅牢性を支えているのが列ID（column ID）という仕組みです。Icebergはテーブル作成時に各列へ恒久的な列IDを割り当て、列名や位置ではなく列IDでデータファイルとスキーマを対応づけます^*2。そのため列名を変更しても、別の列の値を誤って読み込む「ゾンビデータ」のような事故が起きない構造になっています^*1。

Hive形式のテーブルでは、列の追加や型変更が既存パーティションのファイルと不整合を起こしやすく、運用担当者が手動でスキーマとファイルの対応を管理する場面が生じます。Icebergのスキーマ進化はこの調整作業をメタデータ層に吸収する仕組みと言えるでしょう。

隠蔽パーティショニングとパーティション進化

Icebergは、テーブル行に対するパーティション値の算出という煩雑で誤りやすい作業をエンジン側で処理する設計を採用しています^*1。この仕組みは「hidden partitioning（隠蔽パーティショニング）」と呼ばれ、利用者はテーブルの物理的なパーティション構成を意識せず、クエリ条件を書くだけでパーティションプルーニング（不要なファイルの読み飛ばし）の効果を得られます^*1。

Hive形式では、パーティション列（例：event_date）がテーブルの通常列として存在し、書き込み時にその値を明示的に指定する必要があります^*1。この方式は、クエリ側でも同じ列を使ったフィルタを書かなければパーティションプルーニングが働かず、性能低下やクエリミスにつながりやすいという課題を抱えていました。

加えてIcebergは「partition evolution（パーティション進化）」に対応し、テーブル運用を続けたまま将来のパーティション構成を変更できます^*2。既存データの再書き込みは不要で、変更後に書き込まれる新しいデータから新しいパーティション構成が適用される仕組みです^*2。データ量の増加に応じて粒度を調整したい場合に、テーブル停止や再配置を避けられる点が実務上の利点です。

スナップショットとタイムトラベルによる再現性

Icebergでは挿入・更新・削除・マージといった書き込み操作のたびに、対象データファイルへの参照を持つ不変（イミュータブル）のスナップショットが新たに作成されます。公式サイトは「Time-travel enables reproducible queries that use exactly the same table snapshot」と説明しており、過去の特定時点と全く同じテーブル状態でクエリを再現できる点をタイムトラベルの価値として位置づけています^*1。

Spark・Trino・Flink・Presto等のエンジンは、スナップショットIDまたはタイムスタンプを指定して「その時点のテーブル」に対するクエリを実行できます。誤った更新処理を取り消す場合は、対象のスナップショットIDやタイムスタンプを指定してテーブルを以前の状態に戻すロールバック操作も提供されています。

スナップショットは無期限に保持されるわけではありません。メタデータ管理の一環としてexpireSnapshots操作を実行すると古いスナップショットが期限切れとなり、それ以降はタイムトラベルの対象から外れます。運用では、監査要件と保持コストのバランスを見て期限切れの方針を設計する必要があります。

ACIDトランザクションと同時実行制御

Icebergはテーブルへのコミットを、現在のテーブルメタデータファイルへのパスをアトミックに切り替える操作として実装しており、これがACID^*3（Atomicity・Consistency・Isolation・Durability、データ操作の一貫性を保証する4つの特性）のうちアトミック性とシリアライザブル分離レベルの基盤になっています^*4。複数の書き込みが同時に発生した場合は、楽観的並行性制御（optimistic concurrency control）によって処理されます^*4。

カタログへのアトミックな更新が競合によって失敗した場合、Icebergは最新のテーブル状態を取得したうえで書き込みを再試行し、シリアライザブル分離（同時実行される処理が順番に実行されたかのように見える、最も厳格な分離レベル）を確保する仕組みです^*4。テーブルはSerializableとSnapshot Isolationという2つの分離レベルをサポートし、いずれも読み取り側がコミット済みのデータのみを参照できる一貫した視点を提供します^*4。

従来のHive形式のテーブルでは、ファイルの追加・削除を複数プロセスが同時に行うと整合性の担保が難しく、運用側でジョブの排他制御を組む必要がありました。Icebergはこの排他制御をテーブルフォーマットの機能として提供する形に変えています。

対応エンジンとカタログ構成の選び方

Icebergは特定の処理エンジンに依存しない設計であり、Spark・Trino・Flink・Presto・Hive・Impalaなど複数のエンジンが同じテーブルを同時に支障なく扱える点が公式サイトでも明示されています^*1。分析用途はTrino、ストリーム処理はFlink、バッチ処理はSparkといった形で、処理特性に応じてエンジンを使い分けられる構成が取れます。

テーブルの現在の状態（最新のメタデータファイルの位置）を管理する役割を担うのがカタログです。代表的な選択肢として、ベンダー中立で標準化されたHTTPベースのプロトコルを定義するREST Catalog、AWSのマネージドサービスとして運用負荷を抑えられるAWS Glue Data Catalog、従来型のHive Metastoreなどが挙げられます。

REST Catalogは新規構築における選択肢として紹介される一方、既存でGlueやAthena、EMR、RedshiftといったAWS分析サービスを利用している場合はGlue Data Catalogとの統合が容易だとされています。カタログ選定は、既存のクラウド基盤・エンジン構成との親和性を軸に検討する必要があります。

Delta Lake・Hudiとの違いと選定軸

オープンなテーブルフォーマットには、Iceberg以外にDelta LakeとApache Hudiがあります。それぞれ設計思想が異なるため、単純な機能一覧の比較ではなく用途に応じた選定が必要です。

Delta Lakeは、Parquetファイルとトランザクションログ（_delta_logディレクトリ）を用いてACIDトランザクションとスケーラブルなメタデータ管理を提供する形式です^*5。ストリーミングとバッチの両方をひとつのテーブルで扱える点が特徴として説明されています^*5。

Apache Hudiは、Copy-On-Write（更新ごとにファイルを新規作成）とMerge-On-Read（更新をログファイルに記録し後でコンパクション）という2つのテーブルタイプを持ち、高頻度の更新・削除を伴うインクリメンタルなパイプラインに向けた設計が特徴です^*6。

いずれの形式もACIDトランザクションを備えるオープンなテーブルフォーマットという点は共通しています。既存の分析エンジン構成（TrinoやSparkの利用状況）、更新パターン（分析中心か高頻度更新中心か）、カタログの運用方針を踏まえて選定する必要があります。

外注と内製の判断軸・必要スキルと工数

Icebergを内製で導入するには、テーブルフォーマットの仕様理解に加え、カタログ（REST/Glue/Hive Metastore）の選定・構築、パーティション設計、対応エンジン（Spark/Trino/Flink等）側の設定、既存Hive形式テーブルからの移行計画といった複数領域の知識が必要になります。単一の担当者がこれらを網羅するのは難易度が高く、複数名での体制構築が実務上の前提になります。

パーティション設計や列ID管理の考え方を誤ると、スキーマ進化やパーティション進化が想定どおりに機能せず、後からテーブルを再構築する事態につながりかねません。テーブルフォーマットの選定を誤った場合の手戻りは、データ移行そのものを再実行するコストを伴うため、設計段階での検証が欠かせません。

専門パートナーに依頼する場合は、カタログ選定・パーティション設計・既存基盤からの移行方針を含めた設計フェーズを外部の知見で先に固められる点が内製との差分になります。一方で内製を選ぶ場合は、Spark/Trinoなど対応エンジンの運用経験者を確保し、段階的に検証環境で仕様を検証する進め方が現実的です。どちらを選ぶにせよ、パーティション設計とカタログ構成は後戻りしにくい意思決定であるため、初期段階での検証工程を軽視しないことが大切です。

まとめ：テーブルフォーマット選定と外注判断の3つの軸

本稿ではApache Icebergというテーブルフォーマット固有の仕組みを、スキーマ進化・パーティション進化・スナップショット・ACID・対応エンジンの観点から整理しました。要点は3つに集約できます。第一に、Icebergは列IDと隠蔽パーティショニングによって、既存データを再書き込みせずにスキーマとパーティション構成を変更できる設計です。第二に、スナップショットに基づくタイムトラベルとロールバックが、クエリの再現性と誤操作からの復旧を支えます。第三に、カタログ選定と対応エンジンの組み合わせは既存基盤との親和性で決まるため、外注・内製いずれの場合も設計フェーズの検証を丁寧に行う必要があります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Apache Iceberg「Apache Iceberg™」公式サイト（https://iceberg.apache.org/）
2. *2　出典：Apache Iceberg「Evolution」公式ドキュメント（https://iceberg.apache.org/docs/latest/evolution/）
3. *3　出典：ACID（Atomicity, Consistency, Isolation, Durability）はデータベーストランザクションの一貫性を保証する4特性の総称です。
4. *4　出典：Apache Iceberg「Reliability」公式ドキュメント（https://iceberg.apache.org/docs/latest/reliability/）
5. *5　出典：Delta Lake公式ドキュメント（https://docs.delta.io/）
6. *6　出典：Apache Hudi「Overview」公式ドキュメント（https://hudi.apache.org/docs/overview/）

Tweet