❄️

Snowflakeで始めるData Lake - Apache Icebergの基本と活用法 -

に公開

Snowflakeで始めるData Lake - Apache Icebergの基本と活用法 -

はじめに

近年、企業が扱うデータ量は爆発的に増加しており、これらのデータを効率的に管理・活用するためのデータレイク構築の重要性が高まっています。しかし、従来のデータレイクでは、トランザクションの一貫性担保の難しさや、スキーマ変更への追従、特定ベンダーへのロックインといった課題がありました。

これらの課題を解決するオープンソースのテーブルフォーマットとして注目されているのが Apache Iceberg です。そして、クラウドデータプラットフォームである Snowflake もIcebergをサポートし、より柔軟で高性能なデータレイクの実現を可能にしています。

本記事では、Apache Icebergの基本的な概念から、Snowflake上でIcebergテーブルを活用する方法、そしてそれがもたらすビジネス価値について解説します。

Apache Icebergとは?

Apache Icebergは、膨大な量のデータを管理するために設計されたオープンソースのテーブルフォーマットです。元々はNetflixによって開発され、現在ではApache Software Foundationのトップレベルプロジェクトとなっています。

Icebergの主な特徴は以下の通りです。

  • トランザクションの一貫性 (ACID特性): データレイク上のテーブルに対しても、データベースのような信頼性の高いトランザクション処理を実現します。
  • スキーマ進化への対応: テーブルのスキーマ(列の追加、削除、型変更など)を安全かつ容易に変更できます。古いスキーマのデータと新しいスキーマのデータを共存させることも可能です。
  • タイムトラベルとバージョンロールバック: 過去の特定時点のテーブル状態にアクセスしたり、誤った更新を以前のバージョンに戻したりすることができます。
  • 豊富なエコシステム: Spark, Flink, Presto, Trino, Hiveなど、多くのデータ処理エンジンでサポートされています。
  • SQL互換性: 既存のSQLスキルセットを活かしてデータ操作が可能です。
  • パフォーマンス: 大規模データセットに対しても効率的なクエリパフォーマンスを実現するための工夫がされています(パーティションプルーニング、ファイルプルーニングなど)。

これらの特徴により、Icebergはベンダーロックインを防ぎ、よりオープンで柔軟なデータレイクアーキテクチャの構築を支援します。

この階層構造により、Icebergは効率的なファイルプルーニング(不要なデータファイルをスキャン対象から除外すること)やアトミックなメタデータ操作を実現し、タイムトラベルのような機能も可能にしています。

Snowflakeにおけるテーブル選択肢

Snowflakeでデータを利用する際には、主に3つのテーブルタイプがあります。それぞれの特徴を理解し、ユースケースに応じて最適なものを選択することが重要です。

特徴 標準テーブル (Standard Table) 外部テーブル (External Table) Icebergテーブル (Iceberg Table)
データの実体 Snowflake内にロード・保存 (マイクロパーティション) お客様管理のオブジェクトストレージ (S3, GCS, Azureなど) お客様管理のオブジェクトストレージ (S3, GCS, Azureなど)
データ形式 Snowflakeネイティブフォーマット CSV, JSON, Parquet, ORC, Avroなど Apache Icebergフォーマット
読み書き 読み書き可能 読み取り専用 読み書き可能 (Snowflakeがコンピュートとして動作)
パフォーマンス 非常に高速 (マイクロパーティションによる最適化) 遅い (特にファイル数が多い場合、パーティションプルーニングが限定的) 高速 (IcebergのメタデータとSnowflakeの最適化により)
トランザクション ACID準拠 不可 ACID準拠 (Icebergの機能)
スキーマ管理 Snowflakeで管理 ファイル定義に依存 (スキーマ進化に制約) Icebergで管理 (スキーマ進化をサポート)
タイムトラベル Snowflakeの機能として提供 不可 Icebergの機能として提供 (Snowflakeからも利用可能)
主な用途 BI、アドホック分析、DWHの中核データ データレイク上のデータを一時的に参照、ETLのソース オープンなデータレイクハウス構築、他エンジンとのデータ共有
メタデータ管理 Snowflakeが管理 Snowflakeがファイルリストをキャッシュ (限定的) Icebergカタログで管理 (Snowflake Horizon Catalog または外部カタログ)

外部テーブル vs Icebergテーブル

特にデータレイクをSnowflakeと連携させる上で、外部テーブルとIcebergテーブルは比較対象となります。

  • パフォーマンス: Icebergテーブルは、そのメタデータ構造により、外部テーブルよりも効率的なファイルプルーニングが可能であり、一般的にクエリパフォーマンスが優れています。
  • 書き込み機能: 外部テーブルは読み取り専用ですが、IcebergテーブルはSnowflakeから直接書き込み(INSERT, UPDATE, DELETE, MERGE)が可能です。
  • スキーマ進化: Icebergテーブルはスキーマ進化をネイティブにサポートしており、データレイクのスキーマ変更に柔軟に対応できます。外部テーブルではスキーマ変更が困難な場合があります。
  • トランザクション: IcebergテーブルはACIDトランザクションを提供し、データの信頼性を高めます。

デモンストレーション: S3上のデータをSnowflakeで扱う

ここでは、Amazon S3上のデータをSnowflakeの外部テーブルとIcebergテーブルでそれぞれ扱う簡単なデモ手順を紹介します。

1. S3バケットとIAMロールの準備 (共通)

まず、データファイルを格納するS3バケットと、SnowflakeがそのバケットにアクセスするためのIAMロールを作成・設定します。詳細はSnowflakeのドキュメントを参照してください。

2. 外部テーブルの場合 (S3)

外部テーブルは、S3などの外部ストレージにあるデータを直接クエリするためのものです。読み取り専用となります。

Step 1: コンテキストの設定

USE ROLE SYSADMIN;
USE WAREHOUSE MY_WH; -- 適切なウェアハウスを指定
USE DATABASE MY_DATABASE; -- 適切なデータベースを指定
USE SCHEMA MY_SCHEMA; -- 適切なスキーマを指定

Step 2: 外部ステージの作成

CREATE OR REPLACE STAGE my_external_stage
  URL = 's3://your-s3-bucket/path/to/data/'
  STORAGE_INTEGRATION = s3_integration_object;

Step 3: 外部テーブルの作成

CREATE OR REPLACE EXTERNAL TABLE my_external_table (
  order_id VARCHAR AS (VALUE:c1::VARCHAR),
  product_name VARCHAR AS (VALUE:c2::VARCHAR),
  quantity INT AS (VALUE:c3::INT),
  order_date DATE AS (VALUE:c4::DATE)
)
WITH LOCATION = @my_external_stage
FILE_FORMAT = (TYPE = PARQUET)
AUTO_REFRESH = FALSE;

Step 4: データの参照

SELECT * FROM my_external_table LIMIT 10;

SELECT product_name, SUM(quantity)
FROM my_external_table
WHERE order_date >= '2024-01-01'
GROUP BY product_name;

Step 5: 書き込み操作の試行

INSERT INTO my_external_table (order_id, product_name, quantity, order_date)
VALUES ('ORD1001', 'New Product', 10, CURRENT_DATE());
-- 外部テーブルは読み取り専用のため、エラーになります

🔹 Icebergテーブルの場合 (S3 + Snowflake管理カタログ)

Icebergテーブルは、S3などの外部ストレージにあるデータを読み書き可能なテーブルとして扱えます。ここでは、Snowflakeが管理するIcebergカタログを使用する例を示します。


Step 1: コンテキストの設定

USE ROLE SYSADMIN;                  -- 適切な権限を持つロール
USE WAREHOUSE MY_WH;                -- 適切なウェアハウスを指定
USE DATABASE MY_ICEBERG_DB;         -- Icebergテーブル用のデータベース
USE SCHEMA MY_ICEBERG_SCHEMA;       -- Icebergテーブル用のスキーマ

Step2 外部ボリュームの作成 (オプションだが推奨)

CREATE OR REPLACE EXTERNAL VOLUME my_s3_external_volume
  STORAGE_PROVIDER = S3
  STORAGE_BASE_URL = 's3://your-iceberg-s3-bucket/'    -- Icebergテーブルのデータを格納するS3バケットのルートパス
  STORAGE_AWS_ROLE_ARN = 'arn:aws:iam::YOUR_AWS_ACCOUNT_ID:role/YOUR_SNOWFLAKE_ACCESS_ROLE';

Step3 Icebergテーブルの作成

CREATE OR REPLACE ICEBERG TABLE my_iceberg_table (
  order_id VARCHAR,
  product_name VARCHAR,
  quantity INT,
  order_date DATE
)
EXTERNAL_VOLUME = 'my_s3_external_volume'    -- 作成した外部ボリューム名
CATALOG = 'SNOWFLAKE'                        -- Snowflakeがカタログを管理
BASE_LOCATION = 'iceberg_data/my_sales_table/';

Step 4: データのロード (INSERT)

INSERT INTO my_iceberg_table (order_id, product_name, quantity, order_date) VALUES
  ('ORD001', 'Laptop', 1, '2024-05-01'),
  ('ORD002', 'Mouse', 2, '2024-05-01'),
  ('ORD003', 'Keyboard', 1, '2024-05-02');

Step 5: データ操作 (SELECT, UPDATE, DELETE, MERGE)

データの取得

SELECT * FROM my_iceberg_table WHERE product_name = 'Laptop';

データの更新

UPDATE my_iceberg_table 
SET quantity = 3 
WHERE order_id = 'ORD002';

データの削除

DELETE FROM my_iceberg_table 
WHERE order_id = 'ORD003';

データのマージ

MERGE INTO my_iceberg_table AS T
USING (
  SELECT 'ORD001' AS id, 'Laptop Pro' AS name, 1 AS qty, '2024-05-05' AS dt
) AS S
ON T.order_id = S.id
WHEN MATCHED THEN
  UPDATE SET T.product_name = S.name, T.quantity = T.quantity + S.qty
WHEN NOT MATCHED THEN
  INSERT (order_id, product_name, quantity, order_date)
  VALUES (S.id, S.name, S.qty, S.dt);

Icebergテーブルのタイムトラベル

Icebergテーブルは、過去の特定の状態にアクセスできる**「タイムトラベル」**機能をサポートしています。
AT または BEFORE 句を使って過去のデータを参照できます。

スナップショットIDを指定して参照

SELECT * FROM my_iceberg_table AT (SNAPSHOT => '1234567890123456780');

タイムスタンプ時点の状態を参照

SELECT * FROM my_iceberg_table BEFORE (TIMESTAMP => '2024-05-03 10:00:00'::TIMESTAMP_LTZ);

行レベルセキュリティの設定

IcebergテーブルでもSnowflakeの強力なガバナンス機能を適用できます。

Step 1: アクセス制御用のロール作成

CREATE ROLE sales_rep_role;
CREATE ROLE sales_manager_role;

GRANT USAGE ON DATABASE MY_ICEBERG_DB TO ROLE sales_rep_role;
GRANT USAGE ON SCHEMA MY_ICEBERG_SCHEMA TO ROLE sales_rep_role;
GRANT SELECT ON TABLE my_iceberg_table TO ROLE sales_rep_role;

Step 2: 行アクセスポリシーの作成

CREATE OR REPLACE ROW ACCESS POLICY sales_data_policy
AS (product_name_column VARCHAR) 
RETURNS BOOLEAN -> 
CASE
  WHEN 'SALES_MANAGER_ROLE' = CURRENT_ROLE() THEN TRUE
  WHEN 'SALES_REP_ROLE' = CURRENT_ROLE() THEN product_name_column IN ('Laptop', 'Mouse')
  ELSE FALSE
END;

Step 3: テーブルへのポリシーの適用

ALTER TABLE my_iceberg_table
ADD ROW ACCESS POLICY sales_data_policy ON (product_name);

Step 4: ロールを切り替えて動作確認

-- セールス担当者のロールで確認
USE ROLE sales_rep_role;
SELECT * FROM my_iceberg_table;

-- マネージャーロールで確認
USE ROLE sales_manager_role;
SELECT * FROM my_iceberg_table;

-- 管理者ロールで全データ確認
USE ROLE SYSADMIN;
SELECT * FROM my_iceberg_table;

このような形でIcebergテーブルは「タイムトラベル」「行レベルセキュリティ」「ACIDトランザクション」をサポートしており、外部テーブルに比べて強力なデータ管理とクエリパフォーマンスを実現します。

オープンレイクハウスアーキテクチャにおけるIcebergの活用

Icebergは、データレイク (Data Lake) とデータウェアハウス (Data Warehouse) の利点を組み合わせた「レイクハウス (Lakehouse)」アーキテクチャを実現する上で中核的な役割を果たします。以下にいくつかの活用パターンを示します。

1. ゴールドレイヤーをIcebergテーブルで使用

説明: データクレンジングや変換処理が完了し、ビジネスユーザーやBIツールが直接アクセスする「ゴールド」レイヤーのデータをIcebergフォーマットでS3などのオブジェクトストレージに格納します。SnowflakeはこのIcebergテーブルを直接クエリし、分析やレポーティングに活用します。

メリット:
オープンフォーマットによるデータの所有権確保とベンダーロックイン回避。
Snowflake以外のエンジン(Spark、Trinoなど)からも同じデータにアクセス可能。
Snowflakeのコンピュートリソースを効率的に利用。

2. 既存データレイクを活かし、シルバーとゴールドをIcebergで構築

説明: 既に大規模なデータレイク(例: S3上のParquetファイル群)が存在する場合、ブロンズレイヤーはそのまま活用し、中間処理を行うシルバーレイヤーや最終的な分析用データであるゴールドレイヤーをIcebergフォーマットで構築します。

メリット:
既存のデータレイク資産を有効活用。
段階的にIcebergのメリット(トランザクション、スキーマ進化など)を導入可能。
処理途中のデータに対しても信頼性と管理性を向上。

3. 全てのレイヤーをIceberg形式で管理

説明: 生データに近いブロンズレイヤーから、シルバー、ゴールドに至るまで、全てのレイヤーのデータをIcebergフォーマットで管理します。

メリット:
データレイク全体で一貫したテーブルフォーマットと管理手法を実現。
各レイヤーでIcebergの機能(タイムトラベル、スキーマ進化など)を最大限に活用。
データパイプラインの信頼性と運用性を大幅に向上。

ビジネス環境や既存システムの状況、将来的なデータ活用戦略に応じて、これらのアーキテクチャパターンを参考に、最適なレイクハウスアーキテクチャを設計することが重要です。

Iceberg活用によるビジネス価値の向上

Apache IcebergをSnowflakeと組み合わせて活用することで、企業は以下のようなビジネス価値を享受できます。

データ基盤のコスト最適化と将来性の確保

  • ストレージコストの削減:
    コンピュートとストレージを分離し、比較的安価なオブジェクトストレージ(S3など)をデータの実体置き場として活用できます。
    Icebergの効率的なメタデータ管理とファイルプルーニングは、ストレージ使用量とアクセス効率の最適化にも貢献します。

  • ベンダーロックインの回避:
    オープンなテーブルフォーマットであるIcebergを採用することで、特定のデータ処理エンジンやプラットフォームへの依存を低減し、将来の技術選択における柔軟性を確保できます。
    Snowflakeは、このオープン性を尊重しつつ、強力なエンジンを提供します。

データエンジニアとアナリストの生産性向上

  • 信頼性の高いデータ操作:
    ACIDトランザクションにより、データレイク上でのETL/ELT処理の信頼性が向上し、データ破損リスクを低減します。

  • 柔軟なスキーマ変更:
    スキーマ進化機能により、ビジネス要件の変化に迅速に対応してテーブル構造を変更でき、データパイプラインの改修が容易になります。

  • 迅速なデータ復旧:
    タイムトラベルとバージョンロールバック機能により、誤操作やデータ品質問題が発生した場合でも、迅速に過去の正常な状態にデータを復旧できます。
    これにより、ダウンタイムの削減と開発サイクルの短縮に繋がります。

  • SQLによる直感的な操作:
    Snowflakeを通じて、使い慣れたSQLでIcebergテーブルのデータ定義(DDL)やデータ操作(DML)を行えるため、学習コストを抑えつつ、高度なデータ管理機能を利用できます。

データガバナンス強化とコンプライアンス対応

  • 一元的なアクセスコントロール:
    Snowflakeの行アクセスポリシー、列レベルセキュリティ(マスキングポリシーなど)、タグベースのマスキングといった高度なガバナンス機能を、オープンなIcebergテーブルに対しても適用できます。
    これにより、データセキュリティとコンプライアンス要件を一元的に管理できます。

  • 監査証跡の強化:
    Icebergのメタデータは全ての変更履歴(スナップショット)を保持するため、データの変更履歴の追跡や監査が容易になります。

データ活用の民主化とイノベーション促進

  • 多様な分析ツールとの連携:
    Icebergは多くの分析エンジンでサポートされているため、Snowflakeだけでなく、Spark、Trino、Flinkなど、目的に応じて最適なツールを選択し、同一データセットに対してアクセスできます。
    これにより、データサイロ化を防ぎ、組織全体のデータ活用を促進します。

  • リアルタイム分析への対応:
    Icebergはストリーミング取り込みにも対応しており、Snowpipe Streamingと組み合わせることで、よりリアルタイムに近いデータ分析基盤を構築できます。

ユースケースの例

  • 小売業:
    Icebergを使って顧客の購買履歴や行動ログを一元管理し、Snowflakeで高速に分析することで、パーソナライズされたレコメンデーションの精度を向上させます。

  • 金融機関:
    市場データや取引データをIcebergで管理し、タイムトラベル機能を使って過去の特定時点のポートフォリオ分析やリスク評価を行うことが可能です。

まとめ

Apache Icebergは、現代のデータレイクが抱える多くの課題を解決する強力なオープンソースのテーブルフォーマットです。
SnowflakeがIcebergをネイティブにサポートすることで、ユーザーはオープン性を維持しつつ、Snowflakeの高性能なクエリエンジン、堅牢なデータガバナンス機能、そして使いやすいSQLインターフェースの恩恵を受けることができます。

Discussion