Apache IcebergとSnowflakeを用いた本番向けデータレイクハウス構築ハンズオンガイド

Posted at 2026-10-30

Apache IcebergとSnowflakeを用いた本番向けデータレイクハウス構築ハンズオンガイド

はじめに

こんにちは、NKKTech Global 技術チームです。

従来のSnowflake導入では、データはSnowflake内部のプロプライエタリなストレージ形式に格納されていました。これにより優れた性能が得られる反面、以下のジレンマが存在していました。

「Snowflake外のツール（Apache Spark, Flink, DuckDB, Trino等）から直接データを読めない」
「ペタバイト規模のデータをすべてSnowflake内に保持するとストレージ課金がかさむ」
「将来的なマルチクラウド移行やベンダー変更の自由度（データ主権）が失われる」

Apache Iceberg をデータストレージの基盤に据えることで、データの実体（Parquetファイルおよびメタデータ）は自社のAWS S3に保持したまま、Snowflakeの超高速な分散エンジン、堅牢なRBAC、データガバナンス機能を100%享受することが可能になります。

本記事では、S3バケットの準備からSnowflake External Volumeの設定、Icebergテーブルの作成、タイムトラベル検証までをステップ・バイ・ステップで解説します。

1. オープンレイクハウスの全体アーキテクチャ

データの実体は自社AWSアカウントのS3にオープン形式（Parquet + Iceberg Metadata）で保存され、Snowflakeを含む複数のエンジンから直接アクセス可能な構造をとります。

2. AWS側の事前準備（S3 & IAMロール設定）

Snowflakeが自社S3バケットへ安全に読み書きできるよう、IAMロールを設定します。

① S3バケットの作成

AWS東京リージョンにバケットを作成します。

バケット名例: nkktech-iceberg-lakehouse-prod

② IAMポリシーとロールの作成

Snowflake専用の一時信頼ポリシーを持つIAMロールを作成します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:GetObjectVersion",
        "s3:DeleteObject",
        "s3:DeleteObjectVersion"
      ],
      "Resource": "arn:aws:s3:::nkktech-iceberg-lakehouse-prod/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation"
      ],
      "Resource": "arn:aws:s3:::nkktech-iceberg-lakehouse-prod"
    }
  ]
}

3. Snowflake External Volume（外部ボリューム）の作成

Snowflake側で、S3バケットとIAMロールを接続する EXTERNAL VOLUME を定義します。

-- 管理者ロールで実行
USE ROLE ACCOUNTADMIN;

-- 1. 外部ボリュームの作成
CREATE OR REPLACE EXTERNAL VOLUME ext_vol_iceberg_s3
   STORAGE_LOCATIONS =
      (
         (
            NAME = 'my-s3-ap-northeast-1'
            STORAGE_PROVIDER = 'S3'
            STORAGE_BASE_URL = 's3://nkktech-iceberg-lakehouse-prod/'
            STORAGE_AWS_ROLE_ARN = 'arn:aws:iam::123456789012:role/snowflake-iceberg-access-role'
         )
      );

-- 2. Snowflake側のIAMユーザー情報を確認
DESC EXTERNAL VOLUME ext_vol_iceberg_s3;

重要: DESC EXTERNAL VOLUME の実行結果に出力される STORAGE_AWS_IAM_USER_ARN と STORAGE_AWS_EXTERNAL_ID をコピーし、先ほど作成したAWS IAMロールの**「信頼関係（Trust Relationship）」**に貼り付けて認証を完了させます。

4. SnowflakeマネージドなIcebergテーブルの作成と操作

今回は最も運用がシンプルで、Snowflakeから直接INSERT/UPDATE（書き込み）が可能なSnowflakeマネージドカタログ方式を採用します。

① データベース・スキーマ・Icebergテーブルの作成

-- データベースとスキーマの作成
CREATE DATABASE IF NOT EXISTS lakehouse_db;
CREATE SCHEMA IF NOT EXISTS lakehouse_db.gold;

USE SCHEMA lakehouse_db.gold;

-- Icebergテーブルの作成 (コンピュートウェアハウスを指定)
CREATE OR REPLACE ICEBERG TABLE customer_transactions (
    transaction_id STRING,
    customer_id STRING,
    amount DOUBLE,
    currency STRING,
    transaction_date DATE
)
    EXTERNAL_VOLUME = 'ext_vol_iceberg_s3'
    CATALOG = 'SNOWFLAKE'
    BASE_LOCATION = 'customer_transactions/';

② データの挿入（DMLの実行）

通常のSnowflakeテーブルと全く同じ感覚でSQLを実行できます。内部ではS3上にParquetファイルとIcebergメタデータが自動生成されます。

INSERT INTO customer_transactions (transaction_id, customer_id, amount, currency, transaction_date)
VALUES 
('TX_1001', 'CUST_A', 15000.0, 'JPY', '2026-10-25'),
('TX_1002', 'CUST_B', 32000.5, 'JPY', '2026-10-26'),
('TX_1003', 'CUST_A', 8400.0,  'JPY', '2026-10-27');

-- クエリの実行
SELECT customer_id, SUM(amount) AS total_spent
FROM customer_transactions
GROUP BY customer_id;

この時点で自社のS3バケットを覗くと、customer_transactions/data/ 配下に標準のSnappy圧縮Parquetファイルが配置され、metadata/ 配下にスナップショットファイルが作成されていることが確認できます。

5. Icebergの真価：タイムトラベルとスキーマ進化

Icebergはオブジェクトストレージ上のファイル群に対して、RDBMSと同等のACIDトランザクションとメタデータ管理機能を提供します。

① タイムトラベル（過去時点のデータ復元）

誤ってデータを削除・更新してしまった場合でも、スナップショットIDや日時を指定して過去のデータを即座に参照できます。

-- データを誤って更新
UPDATE customer_transactions SET amount = 0 WHERE customer_id = 'CUST_A';

-- 10分前の正常な状態をピンポイントで参照
SELECT * FROM customer_transactions
AT(OFFSET => -60*10);

② スキーマ進化（Schema Evolution）

従来のHive形式では破綻しがちだった「カラム名の変更」や「カラム追加」が、既存のParquetファイルを一切再書き込みすることなく、メタデータの更新だけで一瞬で完了します。

-- カラムの追加（既存データにはNULLが入る）
ALTER ICEBERG TABLE customer_transactions ADD COLUMN device_type STRING;

-- カラム名の安全なリネーム
ALTER ICEBERG TABLE customer_transactions RENAME COLUMN currency TO transaction_currency;

6. 脱ロックインの実証：DuckDB / PythonからS3を直接読む

Snowflakeのインスタンスをすべて停止した状態でも、オープンフォーマットであるため外部ツールからS3のParquetデータを直接クエリ可能です。

import duckdb

# DuckDBでS3の認証情報を設定
con = duckdb.connect()
con.execute("""
    INSTALL httpfs;
    LOAD httpfs;
    SET s3_region='ap-northeast-1';
""")

# Snowflakeを一切介さず、S3上のParquetファイルを直接スキャン！
df = con.execute("""
    SELECT customer_id, AVG(amount) 
    FROM read_parquet('s3://nkktech-iceberg-lakehouse-prod/customer_transactions/data/*.parquet')
    GROUP BY customer_id
""").df()

print(df)

このポータビリティこそが、Apache Icebergが世界中のエンタープライズで標準採用される最大の理由です。

7. 本番運用のベストプラクティス

ファイルコンパクション（自動最適化）の実行:
頻繁なINSERTやストリーミング取り込みを行うと、S3上に小さなParquetファイル（Small Files問題）が乱立し、読み取り性能が劣化します。定期的にSnowflakeのコンパクション機能をスケジュール実行します。
```
ALTER ICEBERG TABLE customer_transactions RECLUSTER;
```
S3 Intelligent-Tiering の活用:
Icebergの過去スナップショットや古いデータファイルに対してS3 Intelligent-Tieringを適用することで、アクセス頻度が落ちたデータを自動で低コスト層へ移動させ、ストレージ費用をさらに削減します。
カタログ選定（Snowflake vs Polaris / Glue）:
- Snowflake中心で分析を行う場合：Snowflakeカタログが最も手離れが良く高性能。
- Spark/Flink/EMRなど多様なエンジンから同時に書き込む場合：オープンソースの Apache Polaris または AWS Glue を外部カタログとして指定する構成を推奨します。

まとめ：データウェアハウスは「オープン」の時代へ

SnowflakeとApache Icebergの融合は、データアーキテクチャの歴史における決定的な転換点です。

自社のS3にデータを保持することで、クラウドベンダーの囲い込み（ロックイン）を排除。
Snowflakeの強靭な実行エンジンにより、オープン形式でありながら専用DWH並みの爆速レスポンスを実現。
ストレージコストとコンピュートコストを完全分離し、長期的なデータ基盤のTCO（総所有コスト）を最小化。

NKKTech Globalでは、レガシーDWHからApache Iceberg基盤への移行設計、マルチクラウドレイクハウスの構築、パフォーマンス最適化を包括的に支援しています。

お問い合わせ先

Apache Icebergを活用した次世代データ基盤の構築、Snowflakeの設計・コスト最適化、エンタープライズレイクハウス導入に関するご相談は、下記よりお気軽にお問い合わせください。

Webサイト: https://nkktech.com/
メール: contact@nkk.com.vn
LinkedIn: https://www.linkedin.com/company/nkktech

著者：NKKTech Global 技術チーム
私たちは、オープンスタンダードと最先端のクラウドエンジニアリングで、お客様のデータ主権と持続可能なDXを支援します。

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