目次を表示する

Snowflake 入門 2026 ─ DWHから AI Data Cloud までの全体像

Snowflake独自のコア概念

第3章: Snowflake独自のコア概念

6つのコア概念とNo Data Copy原理

第2章で 3層分離アーキテクチャを見た。本章では、その上に乗っている Snowflake 独自のコア概念を扱う。バックエンドエンジニアが「これは便利」と即理解する目玉機能ばかりだ。

順番に見ていく：

  1. Time Travel
  2. Zero-Copy Cloning
  3. Fail-safe
  4. Streams（CDC）& Tasks（スケジューラ）
  5. Stages（外部データ取り込み）
  6. Micro-partition と Automatic Clustering

最後に、これらが全部「データのコピーを作らない」哲学から派生していることを示す。

Time Travel ─ 過去の任意時点に戻れる

Snowflake では過去任意時点のテーブルを読める。AT | BEFORE 句を使う。

-- 1時間前のテーブルを読む
SELECT * FROM orders AT(OFFSET => -3600);

-- 特定タイムスタンプ時点のテーブルを読む
SELECT * FROM orders AT(TIMESTAMP => '2026-04-30 10:00:00'::TIMESTAMP);

-- 特定クエリIDの直前の状態を読む
SELECT * FROM orders BEFORE(STATEMENT => '01a2b3c4-...');

保持期間

EditionDATA_RETENTION_TIME_IN_DAYS の最大値
Standard1日
Enterprise+90日

設定は ALTER TABLE … SET DATA_RETENTION_TIME_IN_DAYS = N で。「念のため最大90日」と全テーブルに設定するのは典型的アンチパターン（第8章）。ストレージが膨張する。

何に使えるか

  • 誤更新の即時復旧：UPDATE を間違えた → DROP した → 過去時点から CREATE TABLE … CLONE … AT(...) で復元
  • dbt run の差分検証：dbt run の前後でデータがどう変わったかを SELECT で比較
  • 監査・コンプライアンス：「2026-04-30 23:59 時点のデータ状態を見せて」が即時にできる
  • Zero-Copy Cloning と組合せ：「3日前の状態の dev DB を作って試験する」が一瞬で可能

復元の典型操作

-- 誤って消したテーブルを復元（DROPから DATA_RETENTION_TIME_IN_DAYS 以内）
UNDROP TABLE orders;

-- 1時間前の状態でテーブルを再作成
CREATE OR REPLACE TABLE orders_restored CLONE orders AT(OFFSET => -3600);

-- もしくは元のテーブルを過去時点で上書き（破壊的、慎重に）
CREATE OR REPLACE TABLE orders CLONE orders AT(OFFSET => -3600);

Zero-Copy Cloning ─ 即時・実質無料の複製

CLONE で、テーブル・スキーマ・データベース全体をメタデータだけのコピーとして複製できる。ストレージは元と共有する。

-- テーブルのクローン
CREATE TABLE orders_dev CLONE orders;

-- スキーマ全体のクローン
CREATE SCHEMA analytics_dev CLONE analytics;

-- データベース全体のクローン
CREATE DATABASE prod_snapshot CLONE prod;

-- 過去時点でクローン（Time Travel と組合せ）
CREATE TABLE orders_yesterday CLONE orders AT(OFFSET => -86400);

なぜ「無料」になるのか

Snowflake は micro-partition を不変な単位として扱う。CLONE は「同じ micro-partition を指すメタデータを別のテーブルとして登録するだけ」だから、実体データはコピーされない。

クローン後にどちらかでデータを変更すると、変更分だけ新しい micro-partition が作られて、その分だけ追加ストレージが発生する（Copy-on-Write）。だから：

  • クローン直後 → ストレージ追加コスト ゼロ
  • 一部を更新 → 更新された micro-partition の容量だけ追加

何に使えるか

  • dev / staging / prod の即時複製：本番と同じ規模のテストデータが秒で手に入る
  • A/Bテスト用の派生テーブル
  • マイグレーション前の安全なスナップショット
  • dbt の Slim CI：本番のクローンに対して PR 差分だけ実行して検証

これは PostgreSQL や Redshift では物理コピーが必要な操作で、TB級だと夜間ジョブで数時間かかる。Snowflake では一瞬で終わる。

Fail-safe ─ Time Travel の後ろにある最後の砦

Time Travel 期間が終わったあとも、追加で7日間、Snowflake 側でデータが保持される。これが Fail-safe。

項目内容
保持期間Time Travel 後 追加7日間
アクセスユーザーは直接アクセス不可、Snowflakeサポート経由で復旧依頼
対象通常テーブルのみ（Transient / Temporary テーブルにはなし）
課金ストレージ課金対象

つまり、Standard Edition で何もしなければ「Time Travel 1日 + Fail-safe 7日 = 最大8日間は復旧可能」だ。Enterprise+ で DATA_RETENTION_TIME_IN_DAYS = 90 にすると「90日 + 7日 = 97日」。

注意：Fail-safe はストレージ課金される。大きなテーブルで保持期間を最大にすると、実体ストレージの数倍のコストが発生する。第7章のコスト管理で扱う。

Streams ─ テーブルの CDC

Stream はテーブルへの DML（INSERT/UPDATE/DELETE）を行レベルで追跡する CDC オブジェクト。

-- streams を作る
CREATE STREAM orders_stream ON TABLE orders;

-- 変更分を取得（メタデータカラム METADATA$ACTION で INSERT/DELETE が分かる）
SELECT *
FROM orders_stream
WHERE METADATA$ACTION = 'INSERT';

重要な性質

  • Stream は消費されると進む：INSERT INTO ... SELECT FROM stream のような操作で読み取ると、そこまでのオフセットが消費済みになる
  • 種類が3つ：Standard（INSERT/UPDATE/DELETE）/ Append-only（INSERTのみ）/ Insert-only（外部テーブル用）
  • STALE_AFTER を超えて消費しないと stale 状態になり、再作成が必要

Streams 単独では消費が手動だから、Tasks と組み合わせて自動化する。

Tasks ─ Snowflake 内蔵スケジューラ

Task は SQL や stored procedure をスケジュール / オンデマンドで実行する。Task Graph（DAG） で依存関係も組める。

CREATE TASK refresh_mart
  WAREHOUSE = mart_wh
  SCHEDULE = 'USING CRON 0 2 * * * UTC'  -- 毎日2:00 UTC
AS
  CALL update_mart_procedure();

-- Streams + Tasks の組合せ：「変更があるときだけ実行」
CREATE TASK process_orders_stream
  WAREHOUSE = etl_wh
  SCHEDULE = '5 MINUTE'
  WHEN SYSTEM$STREAM_HAS_DATA('orders_stream')
AS
  MERGE INTO orders_mart USING orders_stream ON ...;

WHEN SYSTEM$STREAM_HAS_DATA(...) を使うと「変更があるときだけ」走るから、変更がないときの credit を消費しない。

Streams + Tasks vs Dynamic Tables

2024年に Dynamic Tables が GA したことで、ETL の組み方が変わった。

-- 従来：Streams + Tasks で増分パイプライン
-- (上のコード)

-- 2024〜：Dynamic Tables で同じことを宣言的に書ける
CREATE OR REPLACE DYNAMIC TABLE orders_mart
  TARGET_LAG = '5 minutes'
  WAREHOUSE = mart_wh
AS
  SELECT customer_id, COUNT(*) AS order_count, SUM(amount) AS total
  FROM orders
  GROUP BY customer_id;

TARGET_LAG = '5 minutes' と書くだけで、Snowflake が自動で差分リフレッシュする。第6章で深掘りする。

新規開発では Dynamic Tables を優先、sub-minute latency や外部API呼び出し・複雑分岐が必要な場合のみ Streams + Tasks を残す、というのが2026年時点の指針。

Stages ─ 外部データ取り込みのエンドポイント

Stage は「Snowflake にロードするデータの置き場」。2種類ある。

種類説明用途
Internal StageSnowflake 管理の領域一時的なファイルアップロード、PUT コマンドで送り込む
External StageS3 / Blob / GCS の URL を指す既存のデータレイクからロード
-- External Stage を作る
CREATE STAGE my_s3_stage
  URL = 's3://my-bucket/data/'
  STORAGE_INTEGRATION = my_s3_integration
  FILE_FORMAT = (TYPE = 'PARQUET');

-- ロードする
COPY INTO orders
  FROM @my_s3_stage
  PATTERN = '.*orders_2026_05_.*\\.parquet';

COPY INTO はバッチロード、Snowpipe は連続取り込み（Snowpipe Streaming GA 2025-09 で 10GB/秒・10秒未満レイテンシ）。第6章でリアルタイム取り込みとして扱う。

Micro-partition と Automatic Clustering

第2章で「Snowflake は micro-partition を自動分割する」と書いた。本章ではユーザーが介入できる唯一の手段 ─ Clustering Key ─ を補足する。

-- 大規模テーブルに Clustering Key を指定
CREATE TABLE orders (
  order_id NUMBER,
  customer_id NUMBER,
  order_date DATE,
  amount NUMBER
)
CLUSTER BY (order_date, customer_id);

裏で Automatic Clustering（サーバーレス）が継続的に再クラスタリングする。VWH 不要で動くが、サーバーレス credit が課金される。

使い所

  • 1TB 以上のテーブル
  • WHERE / JOIN で頻繁に使うカラム
  • カーディナリティ低 → 高 の順で 3〜4 カラム以下

「全テーブルにとりあえず CLUSTER BY」は典型アンチパターン（第8章）。ROI を必ず確認してから付ける。

全部つながっている ─ コピーを作らない哲学

ここまで6つの概念を見てきた。一見バラバラだが、根は1つだ。

mindmap
  root((コピーを作らない<br/>= 原理3))
    Time Travel
      過去時点を読む
      復元・監査
    Zero-Copy Cloning
      メタデータだけ複製
      dev/staging が秒で
    Fail-safe
      Time Travel の延長線上
    Streams
      変更分だけ追跡
      新しいデータを作らない
    Dynamic Tables
      宣言的差分リフレッシュ
    Iceberg + Open Catalog
      他エンジンとも共有
      コピーなし
    Data Sharing
      組織間でも共有

**「同じデータをコピーせず、視点だけを変える」**という発想が、Time Travel・Cloning・Streams・Dynamic Tables・Iceberg・Data Sharing のすべての根底にある。

これは micro-partition が 不変（immutable） だから成立する。不変だから「過去時点」を保存しても新規ストレージはほぼ要らない（変更差分だけ）し、複製してもメタデータの増加で済む。

第6章で扱う Iceberg + Open Catalog や Data Sharing も、この延長線上にある。他社が「データレプリケーション」「データコピー」で解決している問題を、Snowflake は「メタデータの分岐」で解決している。

本章の要点

#要点
1Time Travel で過去任意時点のテーブルが読める。Standard 1日、Enterprise+ 最大90日
2Zero-Copy Cloning はメタデータだけのコピー。秒・実質無料。dev/staging/PoC の主役
3Fail-safe は Time Travel の後ろ7日間、サポート経由で復旧。ストレージ課金対象
4Streams + Tasks で増分パイプライン。新規開発では Dynamic Tables 優先、sub-minute / 複雑分岐のみ Streams+Tasks
5Stages（Internal / External）で外部データを取り込む。COPY INTO バッチ + Snowpipe Streaming 連続
6Automatic Clustering はユーザーが介入できる唯一の物理設計。1TB超 + 頻繁にフィルタするカラムのみ、3〜4カラム以下
7これらすべてが「コピーを作らない」哲学から派生。micro-partition の不変性がそれを可能にしている

効いている根本原理

本章は 原理3（データのコピーを作らない） が中心だった。Time Travel・Cloning・Fail-safe・Streams・Dynamic Tables・Iceberg はすべて同じ哲学の現出。原理1（3層分離） と 原理2（Consumption-based Pricing） は、これらを安く動かすための物理基盤と経済モデルとして裏で効いている。

ここまでで第1部「Snowflake を理解する」は完了だ。次章では視点を切り替えて、Snowflake と他DWH（BigQuery / Redshift / Databricks / Fabric / DuckDB / ClickHouse）を比較する。