Apache Iceberg– なぜ今、Icebergなのか？

## はじめに
本記事では、Apache Icebergがどのようなサービスなのか、そして導入することでどのようなメリットが得られるのかを、データ基盤初心者の方にも分かりやすく解説します。これを読めば、今後データ基盤を新たに作る場合や、既存の基盤にApache Icebergを導入する際の全体像がイメージできるはずです。

## 話さないこと
Apache Icebergの具体的なアーキテクチャや技術的仕組み

## Apache Icebergって何？
Apache Icebergとは、

**データレイクに置かれたファイルをテーブルのように扱う技術のオープンソースプロジェクトです。**

何をいっているか分からないかもしれないので、まずは大規模データの処理基盤の全体像を見てみましょう。

### データ基盤を構成するコンポーネントの全体像

![LTV向け再設計フロー (4).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/252596/68a735f8-c348-d90d-75dd-bae19e9a2bba.jpeg)


データ基盤の構築には、主に以下の3つの要素が関わっています。

**分散ストレージ技術**
HDFSやS3といった信頼性が高くスケーラブルなストレージ基盤で、大量のデータを安価に保持するために不可欠なレイヤーです。

BigQueryやSnowflakeなどのモダンスタックの場合でも内部ではこちらのストレージ技術を使っています。

**計算エンジン**

保存されたデータに対して高速なクエリを実行する仕組みです。

伝統的な技術ならApache SparkやSQLエンジンであるtrino、それらをクラウドマネージドサービス化したAWS GlueやAthenaであったり、分散ストレージとall in oneで提供されるBigQueryやSnoflakeといったモダンなDWHが馴染み深いでしょう。
Snowflakeなどで外部テーブル化する場合は、計算エンジンとしての側面でのみSnowflakeを使用していることになります。

**テーブル化技術**

ストレージに格納されたデータを論理的に整理し、表形式で扱いやすくする仕組みです。

これがApache Icebergの役割にあたるレイヤーです。
分散ストレージ上のparquetなどの形式のファイルデータをテーブルとして扱えるようにし、用途に応じて多様な計算エンジン（Spark、Prestoなど）と連携して使えるようにします。

SnowflakeやBigQueryなどのモダンなDWHは、この部分を独自の技術で隠蔽しており、我々ユーザーは裏側のストレージやテーブル化の管理を丸投げできるようになっているのでモダンなデータスタックを業務に取り込んでいる場合は、あまり意識しないかもしれません。

## Apache Icebergの登場によるメリット
技術的には、
- データ構造を変更せずにスキーマの柔軟な変更が可能になりビジネス要件に追随しやすい
- トランザクションのサポートによる整合性や信頼性の保証
- ストレージデータに対するスケーラビリティの確保
などいろいろありますが、それらの技術的に深ぼった話は第２回に任せるとして、
組織のデータ基盤の運用という視点において最大のメリットを1点記述します。

それは**OSSテーブルフォーマットによる計算エンジンとの疎結合化**です。

SnowflakeやBigQueryのようなモダンDWHは、これらの要素をall in oneで提供しており、テーブルフォーマットについては独自技術を使っていました。

Icebergはテーブル管理の部分をOSSとして利用できるため、特定のDWHベンダーに縛られずに必要に応じて最適な計算エンジンとストレージを自由に選べる点が特徴です。


### 理解を深めるアナロジー
ここでは、BIの領域で起きた変化をアナロジーとして、Apache Icebergがもたらすデータエンジニアリングのトレンド変化について掘り下げます。

Apache Icebergの掲げるテーブルフォーマットと計算エンジンの疎結合化を俯瞰すると、以前トレンドになったBIツールからのセマンティックレイヤーの疎結合化が挙げられます。

セマンティックレイヤーとは、DWHのテーブルをビジネスユーザーにとって理解できる指標に変換する部分です。

下の画像のように、テーブルの列ごとに集計軸と指標に分類をし、例えば注文データについて日時で注文個数を可視化したいといった分析要件に対して 集計軸を「Created Date」、指標を「Count」とUIから選択することで、テーブルの構造について知らなくても実現できるようになるメリットがあります。

![スクリーンショット 2025-02-04 10.51.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/252596/99a8c8dd-d229-ef06-b997-80f44de1a7ac.png)


**従来のall in one BIツールへの依存**

以前は、TableauなどのBIツールがデータのビジュアライズからメトリクス定義のセマンティックレイヤーまで、一手に引き受けるケースが多く見られました。

しかし、組織が大きくなり扱うデータ量や分析目的が増えるにつれ、「各BIツールで用語やメトリクスの定義がバラバラになる」「一貫性が担保しにくい」といった問題が顕在化してきました。

例えばマーケティングチームはBigQueryのテーブルをスプレッドシートから参照して独自の関数などを適用して加工していたり、経営企画チームはTableau、プロダクトチームはLookerで独自の集計軸と指標を定義していた場合に、同じ言葉を指してるのにチームごとにニュアンスが違ったり見ている数字が異なったりしており、信頼の高いデータ活用を阻んでしまいます。

**dbt semantic layerの登場とBIの業務発展**
そこで登場したのが、dbt semantic layerやCubeなどの「セマンティックレイヤーを独立させる」動きです。
従来のBIツールに依存していたデータ定義・メトリクス管理を、一段上のレイヤーで一元管理することで、複数のBIツール間で整合性を保ったままデータ活用を行いやすくしています。
これによって、組織内で使われる用語や定義が共通化され、データの信頼性とスケーラビリティが大きく向上しました。

![スクリーンショット 2025-02-03 17.14.41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/252596/ff83883f-da01-1ae7-4f4e-13ddad7d4911.png)



## Apache Icebergで起こり得るデータエンジニアリングの業務トレンド
dbt semantic layerがBIレイヤーの管理と定義を切り離したように、Apache IcebergはモダンDWHが提供するテーブル管理機能をさらに自由度高く使えるようにするという点で共通点があります。

### Iceberg導入「前」の状態
**単一のストレージとエンジンの密結合**
BigQueryやSnowflakeなどのモダンDWHであれば、ストレージから計算エンジンまでを一括提供してくれる便利さがあります。ただし、ほとんどの場合「社内で統一したDWHを使う」ことが前提となり、チーム単位で別のツールやエンジンを自由に選ぶという発想があまりありませんでした。

**ワークフローの縦割り**
あるチームはBI用にBigQueryを、別のチームはR&D用にSnowflakeを使う……といった使い分けが発生しても、それぞれが別々のストレージを抱えていたり、データを重複管理していたりするケースが多々ありました。またどちらかのDWHに統合するとなった際に、データ移行などの工数も発生し、結果、データの一貫性やガバナンスが保ちにくく、運用が複雑になるリスクがあります。

### Iceberg導入「後」の状態
一方、Apache Icebergが登場すると、下の図のように、BI用途やR&D用途、アプリケーション用途それぞれのデータワークフローにおいて、異なる計算エンジンを活用しながらも、**共通の分散ストレージ上でIcebergを介してデータを管理している**様子がわかります。

![LTV向け再設計フロー (5).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/252596/c41ed46b-896a-732f-591c-4751d50f3509.jpeg)

**共通のストレージでデータを一元管理**

すべてのデータは、Icebergがテーブル管理を行う“共通の分散ストレージ”に置かれます。
これにより、R&DチームがSnowflakeを使うケースでも、BIチームがBigQueryを使うケースでも、データソースそのものは同じなので、一貫性とガバナンスを維持しやすくなります。

これはデータソースに限らず、dbtなどでデータ変換して運用してる途中のテーブルや特定部門向けのマート層のテーブルなどについても全てApache Icebergを通したテーブル化を行えば、同様のメリットが得られます。

**必要に応じた計算エンジンの選択**

たとえば、BIチームはBigQueryやSemantic Layer経由で分析を行い、BIツールやスプレッドシート、MLモデルなどにデータを活用します。
一方、R&DチームはSnowflakeやリバースETLを使って実験的な分析や事業システムへのデータ連携を行うことが可能です。
どのチームも自分たちのユースケースに最適なエンジンを選択できるという大きな自由度が手に入ります。



## まとめ
Apache Icebergは、現代のデータ活用時代において、大量のデータを効率的かつ柔軟に管理するための非常に有望なツールです。

分散ストレージ技術、テーブル管理、計算エンジンという3つの技術的枠組みの中で、Icebergはテーブル管理の部分を独立したコンポーネントとして提供し、SnowflakeやBigQueryのようなモダンDWHが持つ利便性をさらに拡張する形で活用できます。

さらに、BI業務でセマンティックレイヤーを切り離して複数ツール間の整合性を保ちながら柔軟性を高めるトレンドと同様に、データエンジニアリングの世界でも、Icebergを活用することでベンダーロックインを回避しながら高度なデータ管理体制を実現できる可能性が広がっています。



一方で、自由度が高まることで複雑化する運用やガバナンスの課題にも取り組む必要があります。そこにこそ、今後のデータエンジニアリングにおける新たな価値やトレンドがあるとも言えるでしょう。

企業全体のデータ活用基盤をどう最適化していくか、その中心にApache Icebergを据えることで、これまでにない柔軟性と拡張性を得られる可能性があるのではないでしょうか。

最後まで読んでいただきありがとうございました。Apache Icebergの技術的なアーキテクチャとそれに伴う具体的な業務活用でのメリットなどを、実際のデモなどを通して次回のテーマで扱いたいと思います。