1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@y0shidahr

【2026年版】Snowflakeの機能が多すぎるので主要機能を整理してみた

1
Posted at

この記事を書いた理由

前回の記事（Snowflakeの資格勉強を始めたらアーキテクチャが独特すぎて面白かった話）で、Snowflakeのアーキテクチャについて書きました。

その後、勉強を進めてみると「え、こんな機能もあるの？」の連続で、頭の中がごちゃごちゃしてきたので、主要な機能を整理してみます。

特にSnowPro Coreの試験で出そうなものを中心にまとめています。

データ保護系の機能

Time Travel（前回も触れたけど大事なので改めて）

過去のデータにアクセスできる機能。3つの指定方法があります。

-- 1. タイムスタンプ指定
SELECT * FROM orders AT (TIMESTAMP => '2026-03-20 09:00:00'::timestamp);

-- 2. オフセット指定（秒数）
SELECT * FROM orders AT (OFFSET => -300);  -- 5分前

-- 3. クエリID指定（特定のクエリ実行前の状態に戻る）
SELECT * FROM orders BEFORE (STATEMENT => '01abc-def-ghijk');

3番目の「クエリID指定」は地味に便利で、「さっきのUPDATEで壊しちゃったデータを戻したい」ってときに使えます。

-- 間違えてデータを消してしまった場合の復旧
INSERT INTO orders
SELECT * FROM orders BEFORE (STATEMENT => '01abc-def-ghijk')
WHERE id NOT IN (SELECT id FROM orders);

参考: Snowflake公式 - Time Travel

Fail-safe

Time Travelの期間が過ぎた後、さらに7日間だけSnowflakeがデータを保持してくれるセーフティネットです。

注意点：

  • ユーザーが自分でアクセスすることはできない
  • Snowflakeのサポートに連絡して復旧してもらう形
  • 追加のストレージ費用がかかる
  • Transientテーブル・Temporary テーブルにはFail-safeなし

ここが試験で引っかけポイントになります。「Fail-safeのデータにユーザーが直接アクセスできるか？」→ できません。

参考: Snowflake公式 - Fail-safe

テーブルタイプの違い（これが意外と重要）

Permanent Transient Temporary
Time Travel 最大90日 最大1日 最大1日
Fail-safe 7日間 なし なし
スコープ DB全体 DB全体 セッション内のみ
ストレージ費用 高い 中 低い 
-- Transientテーブル（ETLの中間テーブルなどに）
CREATE TRANSIENT TABLE staging_data (
    id INT,
    raw_json VARIANT
);

-- Temporaryテーブル（セッション内の一時作業用）
CREATE TEMPORARY TABLE tmp_calc AS
SELECT customer_id, SUM(amount) AS total
FROM orders
GROUP BY customer_id;

Transientは「データ保護は最低限でいいからストレージ節約したい」ケース、Temporaryは「このセッションでしか使わない」ケースで使います。

データロード系

ステージ（Stage）

Snowflakeにデータを読み込むときの「置き場所」です。3種類あります。

Internal Stage（Snowflake内部）
  ├── User Stage（@~）  ← ユーザー個人用
  ├── Table Stage（@%テーブル名）  ← テーブルに紐づく
  └── Named Stage（@ステージ名）  ← 明示的に作成

External Stage
  └── S3 / Azure Blob / GCS を参照

-- Named Internal Stageの作成
CREATE STAGE my_stage
  FILE_FORMAT = (TYPE = 'CSV' FIELD_DELIMITER = ',' SKIP_HEADER = 1);

-- ファイルのアップロード（SnowSQL CLIから）
PUT file:///tmp/data.csv @my_stage;

-- External Stageの作成
CREATE STAGE my_s3_stage
  URL = 's3://my-bucket/data/'
  STORAGE_INTEGRATION = my_integration;

個人的にハマったのは@~（ユーザーステージ）と@%テーブル名（テーブルステージ）の違いです。最初は「何が違うの？」って思いましたが、テーブルステージはそのテーブルへのCOPY INTOでしか使えない制約があります。

参考: Snowflake公式 - ステージの概要

COPY INTO

ステージからテーブルにデータをロードするコマンドです。

-- 基本のCOPY INTO
COPY INTO my_table
FROM @my_stage/data/
FILE_FORMAT = (TYPE = 'CSV')
ON_ERROR = 'CONTINUE';          -- エラー行をスキップして続行

-- パターンマッチでファイルを絞り込み
COPY INTO my_table
FROM @my_stage
PATTERN = '.*2026-03.*\.csv'    -- 2026年3月のファイルだけ
FILE_FORMAT = (TYPE = 'CSV');

ON_ERROR オプションは試験でよく出ます。

ON_ERROR 挙動
ABORT_STATEMENT（デフォルト） エラーが1つでもあれば全体を中止
CONTINUE エラー行をスキップして続行
SKIP_FILE エラーがあるファイルだけスキップ
SKIP_FILE_n n個以上エラーがあるファイルをスキップ
SKIP_FILE_n% n%以上エラーがあるファイルをスキップ

参考: Snowflake公式 - COPY INTO

Snowpipe（自動ロード）

S3にファイルが追加されたら自動でSnowflakeにロードしてくれるサービスです。DatabricksのAuto Loaderに相当する機能。

-- Snowpipeの作成
CREATE PIPE my_pipe
  AUTO_INGEST = TRUE
AS
COPY INTO my_table
FROM @my_s3_stage
FILE_FORMAT = (TYPE = 'JSON');

AUTO_INGEST = TRUE にしておくと、S3のイベント通知（SQS）と連携して、ファイルが追加されたら自動的にロードしてくれます。

ポイント：

  • サーバーレスで動く（ウェアハウス不要）
  • 内部的にはキューに入って順次処理される
  • ニアリアルタイム（数分程度のラグ）

参考: Snowflake公式 - Snowpipe

データ変換・パイプライン系

Streams & Tasks（CDCパイプライン）

Snowflakeで変更データキャプチャ（CDC）を実現する機能です。

  • Stream: テーブルの変更（INSERT/UPDATE/DELETE）を追跡するオブジェクト
  • Task: スケジュール実行できるSQLジョブ
-- Streamの作成（ordersテーブルの変更を追跡）
CREATE STREAM orders_stream ON TABLE orders;

-- 変更データの確認
SELECT * FROM orders_stream;
-- METADATA$ACTION（INSERT/DELETE）、METADATA$ISUPDATE、METADATA$ROW_ID が付く

-- Taskの作成（5分ごとにStreamのデータを処理）
CREATE TASK process_orders
  WAREHOUSE = analytics_wh
  SCHEDULE = '5 MINUTE'
WHEN
  SYSTEM$STREAM_HAS_DATA('orders_stream')
AS
  INSERT INTO orders_history
  SELECT *, CURRENT_TIMESTAMP() AS processed_at
  FROM orders_stream
  WHERE METADATA$ACTION = 'INSERT';

-- Taskの有効化（作成しただけでは動かない！）
ALTER TASK process_orders RESUME;

ALTER TASK ... RESUME を忘れるとTaskが動かないのは初見殺しです。作成直後は SUSPENDED 状態なので、明示的に有効化する必要があります。

あと、Streamの METADATA$ACTION がUPDATEのときは、DELETE + INSERT の2行として記録されます。METADATA$ISUPDATE が TRUE の行を見てUPDATE相当かどうかを判断します。

参考: Snowflake公式 - Streams
参考: Snowflake公式 - Tasks

Clustering Keys（パフォーマンスチューニング）

Snowflakeは自動でマイクロパーティションを作りますが、特定の列でクエリが多い場合は Clustering Key を指定すると性能が上がります。

-- Clustering Keyの設定
ALTER TABLE orders CLUSTER BY (order_date, customer_id);

-- クラスタリングの状態確認
SELECT SYSTEM$CLUSTERING_INFORMATION('orders', '(order_date, customer_id)');

DatabricksのLiquid Clustering（旧Z-ORDER）に相当する機能ですが、アプローチが違います。

Snowflake (Clustering Key) Databricks (Liquid Clustering)
設定方法 ALTER TABLE ... CLUSTER BY CREATE TABLE ... CLUSTER BY
再クラスタリング 自動（Automatic Clustering） OPTIMIZE コマンド
追加コスト あり（サーバーレスで実行） なし（OPTIMIZEのコンピュート代のみ）

SnowflakeのAutomatic Clusteringは勝手にやってくれるので楽ですが、追加コストがかかります。大きなテーブルでは費用に注意。

参考: Snowflake公式 - Clustering Keys

半構造化データ

VARIANT型とFLATTEN

Snowflakeの面白い特徴の1つが、JSONデータをそのまま格納できること。

-- VARIANT型でJSON格納
CREATE TABLE events (
    event_id INT,
    event_data VARIANT
);

INSERT INTO events
SELECT 1, PARSE_JSON('{
    "user": "tanaka",
    "actions": ["login", "view", "purchase"],
    "details": {
        "browser": "Chrome",
        "os": "macOS"
    }
}');

-- ドット記法でアクセス
SELECT
    event_data:user::STRING AS user_name,
    event_data:details.browser::STRING AS browser
FROM events;

-- 配列をFLATTENで展開
SELECT
    event_data:user::STRING AS user_name,
    f.value::STRING AS action
FROM events,
LATERAL FLATTEN(input => event_data:actions) f;

結果：

user_name | action
----------|--------
tanaka    | login
tanaka    | view
tanaka    | purchase

LATERAL FLATTEN はクセがありますが、慣れると便利です。ネストが深いJSONでも FLATTEN を重ねれば展開できます。

参考: Snowflake公式 - 半構造化データのクエリ

セキュリティ・ガバナンス系

RBAC（ロールベースアクセス制御）

Snowflakeのアクセス制御はロールベースです。主要なシステムロールを押さえておく必要があります。

ACCOUNTADMIN（最上位）
  ├── SYSADMIN → DB・スキーマ・テーブルなどの作成
  ├── SECURITYADMIN → ユーザー・ロールの管理
  │     └── USERADMIN → ユーザー作成
  └── PUBLIC（全ユーザーに自動付与）

-- カスタムロールの作成と権限付与
CREATE ROLE data_analyst;
GRANT USAGE ON DATABASE analytics_db TO ROLE data_analyst;
GRANT USAGE ON SCHEMA analytics_db.public TO ROLE data_analyst;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics_db.public TO ROLE data_analyst;

-- ロールをユーザーに付与
GRANT ROLE data_analyst TO USER yamada;

-- ロール階層の設定
GRANT ROLE data_analyst TO ROLE sysadmin;  -- sysadminがdata_analystの権限も持つ

試験で大事なポイント：

  • ACCOUNTADMIN は日常使いしない。必要なときだけ使う
  • SYSADMIN がオブジェクト作成の標準ロール
  • カスタムロールは SYSADMIN に紐づけるのがベストプラクティス（そうしないとACCOUNTADMINでもアクセスできないオブジェクトができる）

参考: Snowflake公式 - アクセス制御の概要

Data Sharing

Snowflakeの中でも特徴的な機能の1つ。データのコピーなしで他のSnowflakeアカウントとデータを共有できます。

-- 共有元（Provider）
CREATE SHARE analytics_share;
GRANT USAGE ON DATABASE analytics_db TO SHARE analytics_share;
GRANT USAGE ON SCHEMA analytics_db.public TO SHARE analytics_share;
GRANT SELECT ON TABLE analytics_db.public.reports TO SHARE analytics_share;

-- 共有先のアカウントを追加
ALTER SHARE analytics_share ADD ACCOUNTS = abc12345;

-- 共有先（Consumer）
CREATE DATABASE shared_analytics FROM SHARE provider_org.analytics_share;
SELECT * FROM shared_analytics.public.reports;

すごいのは、共有先はデータのコピーを持たないこと。ストレージ費用は共有元だけが負担します。共有先はコンピュート費用だけ。

Snowflakeアカウントを持っていない相手にも「Reader Account」を作って共有できます。

参考: Snowflake公式 - Secure Data Sharing

キャッシュの仕組み（パフォーマンス問題で出る）

Snowflakeには3種類のキャッシュがあります。

キャッシュ 場所 保持期間 条件
Result Cache Cloud Services Layer 24時間 同じクエリ＋データ未変更
Metadata Cache Cloud Services Layer — COUNT(*)、MIN/MAX等
Warehouse Cache Compute Layer ウェアハウス稼働中 同じウェアハウスで再利用 
-- Result Cacheの確認（2回目のクエリで試してみる）
SELECT COUNT(*) FROM large_table WHERE region = 'JP';
-- 1回目: 15秒
-- 2回目: 0.1秒（Result Cacheヒット）

-- Result Cacheを無効にしたい場合
ALTER SESSION SET USE_CACHED_RESULT = FALSE;

試験で引っかかるポイント：

  • ウェアハウスがサスペンドされるとWarehouse Cacheは消える
  • Result Cacheはウェアハウスが停止していてもヒットする（Cloud Servicesレイヤーにあるので）
  • COUNT(*) や MIN()/MAX() は Metadata Cacheから即答（ウェアハウス不要、つまり課金なし）

参考: Snowflake公式 - クエリパフォーマンスの最適化

Resource Monitors（コスト管理）

SnowflakeはクレジットベースのSaaSなので、コスト管理が重要です。Resource Monitorでウェアハウスの使用量に上限を設定できます。

-- Resource Monitorの作成
CREATE RESOURCE MONITOR monthly_monitor
  WITH CREDIT_QUOTA = 500          -- 月500クレジットまで
  FREQUENCY = MONTHLY
  START_TIMESTAMP = IMMEDIATELY
  TRIGGERS
    ON 75 PERCENT DO NOTIFY         -- 75%で通知
    ON 90 PERCENT DO NOTIFY         -- 90%で通知
    ON 100 PERCENT DO SUSPEND       -- 100%でウェアハウスを停止
    ON 110 PERCENT DO SUSPEND_IMMEDIATE;  -- 110%で実行中のクエリも強制停止

-- ウェアハウスに紐づけ
ALTER WAREHOUSE analytics_wh SET RESOURCE_MONITOR = monthly_monitor;

SUSPEND と SUSPEND_IMMEDIATE の違い：

  • SUSPEND: 実行中のクエリは完了してからサスペンド
  • SUSPEND_IMMEDIATE: 実行中のクエリも強制的にキャンセル

参考: Snowflake公式 - Resource Monitors

最近のアップデート：Cortex AI

2025〜2026年にかけて、SnowflakeはAI機能を強化しています。

-- テキストの感情分析
SELECT SNOWFLAKE.CORTEX.SENTIMENT('この製品は素晴らしい。とても満足しています。');
-- → 0.85（正の感情）

-- テキストの要約
SELECT SNOWFLAKE.CORTEX.SUMMARIZE(article_text) FROM articles;

-- テキストの翻訳
SELECT SNOWFLAKE.CORTEX.TRANSLATE('Hello, how are you?', 'en', 'ja');
-- → こんにちは、お元気ですか？

-- LLMに直接質問（COMPLETE関数）
SELECT SNOWFLAKE.CORTEX.COMPLETE('mistral-large2', 'Snowflakeのマイクロパーティションとは何ですか？');

SQLの中でLLMを呼べるのは面白い。データウェアハウスの中でAI処理が完結するので、データを外部に出す必要がなくてセキュリティ的にもいい。

SnowPro Coreの試験範囲にはまだ入っていないかもしれませんが、Specialty: Gen AI の試験ではがっつり出るはずです。

参考: Snowflake公式 - Cortex AI

全体の整理図

最後に、Snowflakeの主要機能をざっくり整理するとこんな感じ。

Snowflake 主要機能マップ

データ保護
  ├── Time Travel（過去データ参照・復元）
  ├── Fail-safe（最終手段の復旧）
  └── テーブルタイプ（Permanent / Transient / Temporary）

データロード
  ├── Stage（Internal / External）
  ├── COPY INTO（バッチロード）
  └── Snowpipe（自動ロード）

データ変換
  ├── Streams（変更追跡）
  ├── Tasks（スケジュール実行）
  └── FLATTEN / VARIANT（半構造化データ）

パフォーマンス
  ├── Clustering Keys（再クラスタリング）
  ├── キャッシュ（Result / Metadata / Warehouse）
  └── Virtual Warehouse（コンピュート管理）

セキュリティ
  ├── RBAC（ロールベースアクセス制御）
  ├── Data Masking（Enterprise以上）
  └── Network Policy

データ共有
  ├── Secure Data Sharing
  └── Reader Accounts

コスト管理
  └── Resource Monitors

AI/ML
  ├── Cortex AI（SQL内でLLM）
  └── Snowpark（Python/Java/Scala）

まとめ

Snowflakeは機能が多いですが、整理してみると体系的にまとまっています。SnowPro Coreの勉強では特に以下が重要です。

  1. データ保護: Time Travel / Fail-safe / テーブルタイプの違い
  2. データロード: Stage / COPY INTO / Snowpipe
  3. パフォーマンス: キャッシュ3種類 / Clustering Keys
  4. セキュリティ: RBAC / システムロールの階層
  5. Data Sharing: コピーなし共有の仕組み

公式ドキュメントが日本語で読めるのはSnowflakeの強みです。困ったら公式ドキュメント。

日本語の練習問題で手を動かしたい場合は、NicheeLab（https://nicheelab.com/snowflake-exam）に各機能の問題があるので、インプットの後のアウトプットに使えます。用語の整理にはNicheeLabの用語集（https://nicheelab.com/articles/snowflake/glossary）も参考になりました。

参考リンク

前回の記事: Snowflakeの資格勉強を始めたらアーキテクチャが独特すぎて面白かった話
次回予定: SnowPro Coreを実際に受験した体験記

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?