はじめに
データ基盤の界隈において、現在もっとも熱いトピックの1つが 「Apache Iceberg」 だと思います。 ネットでいろいろと調べてみると 「ベンダーロックインからの解放」「オープンなテーブルフォーマット」といった、素敵なバズワードが並んでいるのをよく見かけます。
しかし、実務でデータ基盤を支える身としては、どうしても拭いきれない疑問がありました。
「…実際どうなの？」
思想が素晴らしいのは分かります。ですが、新しい技術を導入するということは、「新しい運用を抱え込む」ことと同義です。「脱ロックイン」という理想のために、運用が破綻しては本末転倒です。 そこで、私が抱いていた「CSVやParquetをS3に置くだけではダメなのか？」という素朴な、しかし本質的な疑問に決着をつけるべく、AWSとSnowflakeを組み合わせた検証を行いました。
そもそも、Apache Icebergとは何なのか？
みなさん、こんにちは。インテージテクノスフィアの若宮です。
話をする前段として、Apache Icebergとは何なのかを簡単に説明します。 一言で言えば、Icebergは「オブジェクトストレージ（S3等）に置かれたファイルを、あたかもSQLデータベースのテーブルであるかのように振る舞わせる規格」です。
Icebergを理解する上で、まず整理すべきは「ファイル」と「テーブル」の決定的な差です。 従来、S3にParquetやCSVを置いて外部テーブルとして参照する場合、ACIDトランザクション、スキーマ進化のような「データベースでは当たり前のこと」ができませんでした。 Icebergは、実体データの上に「メタデータ」という管理層を設けることで、それらの機能を実現します。
それによって、特定のDWHに依存せず、メタデータを介してあらゆるエンジンから同じ「状態」を共有することが可能になります。 データを特定の基盤に取り込むと重複が発生したり、管理も手間も増えてきます。直接Snowflake・Databricks・Athenaなど複数のエンジンから同じデータを参照できる状態は、モダンデータ基盤の1つの理想形とも言えるでしょう。
一方で、概念としてのメリットを理解することと、実務で価値を発揮するかどうかは別問題です。 現在世間では多くのシステムがCSVやParquetのようなファイルを使って、問題なく長年運用されています。
それら従来作ってきたものを改修してでも、導入する必要があるのか？ 運用の変更に見合うだけのリターンはあるのか？
そういった疑問を持ちながら「手触り」を確かめることが、今回の検証の目的の1つです。
今回の検証概要：Snowflakeを「1ゲスト」として扱う
今回は検証の範囲として「S3上のIcebergテーブルをSnowflakeから覗きに行く」 という構成を実際に手を動かして検証してみることにしました。 イメージとしては以下の通りです。
データ実体：Amazon S3
メタデータ：AWS Glue
テーブル作成：Amazon Athena
クエリエンジンの1つ：Snowflake
Snowflakeはデータの所有者ではなく、あくまで利用者の一人。 この構成によって、Icebergが持つとされる基盤からの独立性がどこまで現実的なのかを確認します。
実装の記録
今回の検証では、
「S3上に存在するIcebergテーブルをSnowflakeから参照できる状態を構築する」
ことをゴールとしました。
構成を分解すると、作業は大きく5つのフェーズに分かれます。
① AWS側にIcebergの土台を用意する
まずは、Icebergテーブルを配置するためのストレージと権限基盤を整備します。
実施内容
- S3にテーブルバケットを作成
- Lake FormationでS3 Tablesカタログの利用権限を付与
- 外部エンジンからアクセス可能な設定を有効化
ここで押さえておきたい重要なポイントがあります。
👉 Icebergの実体はS3上のファイルである
👉 Glueはメタデータを管理するカタログとして機能する
つまりこの時点で、
- データ → S3
- テーブル情報 → AWS Glue カタログ
という役割分担が成立します。
② AthenaでIcebergテーブルを作成する
次に、Athenaを利用してIcebergテーブルを作成します。 ここでのAthenaは分析用途というより、Icebergテーブルを定義するためのエンジンとして使用しています。
実施内容： SQLによるNamespaceとIceberg Tableの作成。
作成されたテーブルの情報はGlue Catalogに登録され、実データはS3に保存されます。
ここまでで、いわば 「AWSネイティブで完結したIceberg環境」 が整います。
③ SnowflakeがAWSへ接続するための権限を構成する
続いて、Snowflakeが外部のIcebergテーブルへアクセスするためのIAM設定を行います。 流れ自体は一般的な外部サービス連携と同様です。
実施内容
- S3 / Glue / Lake Formationへアクセス可能なIAMポリシーを作成
- Snowflake用のIAMロールを作成
- 作成したロールに対してLake Formation側でカタログ参照権限を付与
ここで重要なのは次の点です。
Snowflakeはデータを保持しない。読み取りに行くだけである。
④ SnowflakeとGlue Catalogを統合する（Catalog Integration）
続いてSnowflake側の設定です。
CATALOG INTEGRATION を作成し、GlueのREST Catalogと接続します。
この統合により、SnowflakeはGlueに登録されたIcebergテーブルを認識できるようになります。
以下は実際に作成したCatalog Integrationの例です。
CREATE OR REPLACE CATALOG INTEGRATION test_catalog_integration CATALOG_SOURCE = ICEBERG_REST TABLE_FORMAT = ICEBERG CATALOG_NAMESPACE = 'test_namespace' REST_CONFIG = ( CATALOG_URI = 'https://glue.ap-northeast-1.amazonaws.com/iceberg' CATALOG_API_TYPE = AWS_GLUE CATALOG_NAME = 'XXXXXXXX:s3tablescatalog/XXXXX-test-bucket' ACCESS_DELEGATION_MODE = VENDED_CREDENTIALS ) REST_AUTHENTICATION = ( TYPE = SIGV4 SIGV4_IAM_ROLE = 'arn:aws:iam::XXXXXXXXX:role/test-role' SIGV4_SIGNING_REGION = 'ap-northeast-1' ) ENABLED = TRUE;
この設定で重要になるのは次の2点です。
- GlueをIcebergのカタログとして指定していること
- IAMロールを利用してAWSリソースへのアクセスを委任していること
外部Icebergでは、この「カタログ指定」と「認証方式」が接続の中核になります。
検証の中で特に便利だったのが、統合設定の疎通を確認できる次の関数です。
''' SELECT SYSTEM$VERIFY_CATALOG_INTEGRATION('test_catalog_integration'); '''
結果が TRUE であれば、SnowflakeからGlue Catalogへの接続が正しく構成されています。
⑤ SnowflakeからIcebergテーブルを参照する
統合が完了すれば、最後にSnowflake上へIcebergテーブルを作成します。
''' use role sysadmin; create or replace ICEBERG TABLE daily_sales CATALOG = 'test_catalog_integration' --カタログ統合 CATALOG_NAMESPACE = 'test_namespace' --名前空間 CATALOG_TABLE_NAME = 'sales' --テーブル名 AUTO_REFRESH = FALSE ; '''
ここで誤解しやすいポイントがあります。
作成されるのはデータではなく「参照」です。
Snowflake内部にデータが保存されるわけではありません。実際の構造は次の通りです。
- テーブル情報 → Glue Catalog
- データ → S3
- Snowflake → それらを参照してクエリを実行
動作確認は通常の SELECT 文で問題なく実行できました。
試してみての気づき
大きな感想・気づきとしては2つです。
1. 作成する技術難易度は普通に各基盤・DBにテーブルを作るのと大して変わらない。
正直今回作成してみて、Icebergだから作り方・作業内容が異なる点は多々ありましたが、技術的に新しいこととしての大幅な難易度の増加は無いのかなと思いました。 ただ、手間としてはCSVやParquetのようなデータを置いて取り込むだけという構成に比べればカタログ整備が手間としてはかかるので、トータルの開発コストはCSVなどの運用のほうが利点はあるだろうと思います。 それゆえに、「どんな状況でもIceberg最高！！！」という感覚ではなく、一定のケースにおいては選択するという存在なのだろうという印象です。
2. Icebergで結果として”できること”はあまり変わらない。けど…！
これはIcebergって意味ないじゃん！という結論を言いたいわけではありません。 今回触ってみた内容と同じ結果をSnowflakeで見たければ、CSVなどをSnowflakeに取り込むことで、同じようなデータをSnowflakeで見ることもできます。 ゆえにIcebergではなくとも、やり方次第で同じ機能要件を確立することはできるのかなと思いました。
ただ、Icebergは従来のCSV/Parquetを使って基盤に取り込む構成と比べて、CSVでは運用が厳しい“スケール感の大きい運用”に対して有用なものだと感覚的に理解しました。
従来のCSV運用の課題感とIcebergによる対応
CSV/ParquetをS3に置く運用はとにかくシンプルで、多くのシステムがこれで長年回っています。
ただし、システムが成長すると次の2つの課題が顕在化すると思っています。
①データ参照側の課題
運用が長くなると、しばしば次の状態に陥ります。
- 「このテーブルの正しいスキーマはどれ？」
- 「どのファイルが最新？」
- 「列の意味や型がツールごとにズレている」
結果として、BIが壊れたり、SQLが壊れたり、確認作業が増えます。
CSV運用は“データはあるが、正解が曖昧”になりがちです。
② データ書き込み側の課題
書き込み側が1つならCSVなどでも全然良いですが、次のように増えると苦しくなります。
- Athenaが一部を書き込み
- Databricksが別処理を書き込み
- Snowflakeも場合により書き込み
このとき、「誰がどこまで書いてよいか」が曖昧な更新順序や衝突を人の運用で吸収することになります。
Icebergは端的に言えば、①②の解決できる存在としてこれから重宝されるものなのだと思います。
具体的には、①に関しては、Icebergを導入すれば、今回の検証で使用したようにCatalogが“テーブルの共通ルール”になります。 もう少しかみ砕いて言うならば
「このテーブルの正しい姿（データ型などの定義）は何？」
という問いに対し、全員がGlue Catalogを見る状態になります。
そのため、“みんなが同じ設計書を見ている状態”をつくることで、CSV運用では曖昧になりがちな部分を、集約できます。
②に関しては、書き込み側が複数いるとき、CSVのみであれば、誰がどこまで書いてよいか曖昧になってしまいますが、 Icebergなら 「Icebergテーブルという1つの共通データを更新する形」になるため、いわゆるACIDトランザクションなどの制御をして、複数エンジンに秩序を保って更新させることも可能です。
問いへの答え
ここまで長く話をしてきましたが「CSVやParquetをS3に置くだけではダメなのか？」という問いに対しての個人的な回答としては
多くの場合、CSV/Parquetだけで十分成立する。
というのが正直なところです。特に次の条件なら、Iceberg導入の必然性は高くないと思っています。
- 利用エンジンが実質1つ（例：ほぼSnowflakeだけ）
- 近い将来の基盤拡張・移行が見えていない
この場合、下手なことを考えず、S3に置いてDWHに取り込む運用が最もシンプルになると思います。
では、反対に「どんなときにIcebergを導入する価値があるのか」という疑問に対する回答としては
- 複数エンジンを対等に使う
- 将来、他の基盤やクエリエンジンを導入検討する可能性が高い。
このときIcebergは、
参照側には「正解の一本化（カタログ）」を、書く側には「秩序ある更新（テーブルとしての仕組み）」を与える という、代えがたい意味を持つのだと思います。
まとめ
シンプルなデータ活用基盤として既にきれいにまとまっている状況で、あえて手を出すものではなく、
システムが成長して、読むエンジンが増え、定義の正解が揺れ始める懸念がある場合や、書くエンジンが増え、更新の秩序が必要になる場合に
Icebergは「便利」ではなく「設計の前提」として効いてくるものなのだろうというのが私の結論です。
長々とお付き合いいただきありがとうございました。
