第3章 データロード・アンロードと接続 / 想定学習時間:30〜40分 / 最終確認:2026年8月

3-3. SnowpipeとSnowpipe Streaming(自動取り込み・課金・使い分け)

🎯 この節の学習目標

1. Snowpipe とは:サーバーレスの継続的ロード

3-2 の COPY INTO は「まとまったデータを、ウェアハウスを使って一括ロードする」方式でした。これに対して Snowpipe は、ステージに到着したファイルを、ほぼ到着順に自動でロードし続ける仕組みです。特徴は次の2点に集約されます。

Snowpipe の実体は PIPE(パイプ)というオブジェクトで、その定義の中身は COPY INTO 文です。

-- パイプの作成:定義の本体は COPY INTO 文そのもの
CREATE PIPE my_pipe
  AUTO_INGEST = TRUE
  AS
  COPY INTO sales
    FROM @my_ext_stage
    FILE_FORMAT = (FORMAT_NAME = 'my_csv_format');

-- パイプの状態確認
SELECT SYSTEM$PIPE_STATUS('my_pipe');

2. 起動方法:AUTO_INGEST と REST API

Snowpipe に「新しいファイルが来た」と知らせる方法は2つあります。

方式仕組み典型的な構成
AUTO_INGEST = TRUE
(クラウドイベント通知)
外部ステージのクラウドストレージが発行するイベント通知(S3 イベント通知など)を受け取り、自動でロードを開始するS3 / Azure Blob / GCS 上の外部ステージにファイルが置かれると自動的にロードされる構成
REST API 呼び出しアプリケーションが Snowpipe の REST エンドポイントを呼び出し、ロードすべきファイル名を明示的に通知するファイル生成側のアプリが自らロードをキックする構成。内部ステージでも使える
ファイル到着クラウドストレージ(外部ステージ)に新しいファイルが書き込まれる
イベント通知(AUTO_INGEST)または REST API 呼び出し
Snowpipe(PIPE オブジェクト)定義された COPY INTO を、Snowflake 管理のサーバーレスコンピュートで実行
マイクロバッチで継続的にロード(通常は分のオーダー)
テーブル履歴は COPY_HISTORY / PIPE_USAGE_HISTORY で確認(重複ロード防止メタデータの保持はパイプに14日)

図:Snowpipe による自動取り込みの流れ。ファイル到着がイベント通知経由でロードのトリガーになる

📝 試験のポイント

「S3 に置かれたファイルを自動でロードし続けたい。ウェアハウスの管理はしたくない」という要件には Snowpipe(AUTO_INGEST = TRUE)が答えです。トリガーの2方式(クラウドのイベント通知 / REST API)はどちらも出題されるので、セットで覚えましょう。

3. 課金モデルとファイルサイズの注意点

Snowpipe はユーザーのウェアハウスを使わないため、課金も COPY INTO とは異なります。

この「ファイルあたりのオーバーヘッド」があるため、極端に小さいファイルを大量に流し込むと、データ量の割に割高で非効率になります。推奨されるファイルサイズは 3-1 と同じく圧縮済み 100〜250MB 程度です。とはいえ実際のストリーミング用途では、レイテンシ(すぐロードしたい)とコスト(まとめてから置きたい)のトレードオフになるため、「1分程度を目安にファイルをまとめて置く」といったバランス調整が推奨されています。

💡 具体例:利用状況とステータスの確認

-- パイプごとのクレジット消費とロード量を確認する
SELECT pipe_name, credits_used, bytes_inserted, files_inserted
FROM TABLE(INFORMATION_SCHEMA.PIPE_USAGE_HISTORY(
  DATE_RANGE_START => DATEADD(day, -7, CURRENT_DATE())
));

-- パイプの実行状態(RUNNING など)や滞留ファイル数を確認する
SELECT SYSTEM$PIPE_STATUS('my_pipe');

コストの追跡は PIPE_USAGE_HISTORY、動作状態の確認は SYSTEM$PIPE_STATUS と役割を分けて覚えておきましょう。

4. ロード履歴:重複防止メタデータと履歴の確認先

Snowpipe も COPY INTO と同様に、同じファイルの重複ロードを防ぐためのメタデータを保持しますが、保持期間が異なります。この「14日と64日」は、あくまで重複ロード防止用メタデータの保持期間である点に注意してください。

バルクロード(COPY INTO)Snowpipe
重複ロード防止メタデータの保持期間64日(テーブルのメタデータに保持)14日(パイプのメタデータに保持)

この日数の違いは頻繁に比較で問われます。「バルクは64日、Snowpipe は14日」と対で暗記しておきましょう。

一方、監査やロード結果の履歴確認は重複防止メタデータとは別の話で、確認先が分かれます。

履歴の確認先保持期間特徴
INFORMATION_SCHEMA.COPY_HISTORY(テーブル関数)14日遅延なし。直近のロード結果の確認・トラブルシューティング向き
SNOWFLAKE.ACCOUNT_USAGE.COPY_HISTORY(ビュー)365日COPY INTO によるロードも Snowpipe によるロードも収録される。長期の監査・傾向分析向き(反映に遅延あり)

5. Snowpipe Streaming:ファイルを経由しない行単位の取り込み

Snowpipe が「ファイル」を単位とするのに対し、Snowpipe Streamingファイルを経由せず、行(row)単位でデータを直接テーブルに書き込む仕組みです。

6. 3方式の使い分け(比較表)

ここまでの3つのロード方式を1つの表に整理します。この比較は本章の要となる知識です。

バルクロード(COPY INTO)SnowpipeSnowpipe Streaming
トリガーユーザー(またはタスク)が手動・スケジュールで実行ファイル到着(イベント通知)または REST APIアプリケーションが SDK のチャネル経由で行を送信
単位ファイル(一括)ファイル(マイクロバッチ)行(ファイルを経由しない)
レイテンシ実行タイミング次第(バッチ)通常は分のオーダー秒レベル
コンピュート・課金ユーザー管理の仮想ウェアハウスの稼働時間サーバーレス+ファイルあたりのオーバーヘッドサーバーレス(行の取り込み量ベース)
重複防止メタデータの保持64日14日チャネルのオフセットで管理
向く場面定期バッチ、大量データの初期ロードファイルが随時到着する継続的ロードIoT・イベントデータなど行単位の連続ストリーム

✅ この節のまとめ

練習問題

問1. S3 バケットに随時到着するファイルを、ウェアハウスを管理せずに自動でロードし続けたい。最も適切な方法はどれか。

  1. 大きな仮想ウェアハウスを常時起動し、COPY INTO を手動で繰り返し実行する
  2. AUTO_INGEST = TRUE のパイプを作成し、S3 のイベント通知でロードをトリガーする
  3. PUT コマンドでファイルをユーザーステージに移動し続ける
  4. FORCE = TRUE を指定した COPY INTO を1回だけ実行する
解答と解説を見る

正解:B

「随時到着」「自動」「ウェアハウス管理不要」という要件は、AUTO_INGEST = TRUE の Snowpipe がそのまま満たします。Aはウェアハウスの常時稼働コストと手動運用が発生し、要件に反します。Cの PUT はローカルからのアップロードコマンドで、S3 からの自動ロードとは無関係です。Dは1回きりの強制再ロードにすぎず、継続的な取り込みにはなりません。

問2. Snowpipe の課金に関する説明として正しいものはどれか。

  1. ユーザーが指定した仮想ウェアハウスの稼働時間に基づいて課金される
  2. 完全に無料であり、クレジットを消費しない
  3. サーバーレスコンピュートの使用量に加え、処理ファイル数に応じたオーバーヘッドが課金される
  4. ロードしたファイルのサイズにかかわらず、月額固定料金である
解答と解説を見る

正解:C

Snowpipe はサーバーレスコンピュートの使用量と、ファイルあたりのオーバーヘッドで課金されます。この構造があるため、極端に小さいファイルを大量に流すと割高になります。Aは COPY INTO の課金の考え方で、Snowpipe はユーザーのウェアハウスを使いません。Bのように無料ではなく、Dのような固定料金制でもありません。

問3. ロード履歴(重複ロード防止用メタデータ)の保持期間の組み合わせとして正しいものはどれか。

  1. バルクロード(COPY INTO):14日、Snowpipe:64日
  2. バルクロード(COPY INTO):64日、Snowpipe:14日
  3. どちらも64日
  4. どちらも無期限
解答と解説を見る

正解:B

バルクロードのロードメタデータはテーブルに64日、Snowpipe のロード履歴はパイプに14日保持されます。Aは数字が逆です。CとDは保持期間の違いを無視しており誤りです。この「64日と14日」の対比はそのまま問われることが多いので、確実に覚えておきましょう。

問4. Snowpipe Streaming の説明として正しいものはどれか(2つ選べ)。

  1. ステージ上のファイルをマイクロバッチでロードする仕組みである
  2. SDK のチャネルを通じて、行単位でデータをテーブルに直接書き込む
  3. ファイルを経由しないため、秒レベルの低レイテンシで取り込める
  4. 実行にはユーザーが管理する仮想ウェアハウスの起動が必要である
解答と解説を見る

正解:B・C

Snowpipe Streaming は SDK のチャネル経由で行単位に書き込み、ファイルの作成・ステージングを挟まないため秒レベルのレイテンシを実現します。Aは(通常の)Snowpipe の説明で、Streaming はファイルを単位としません。Dは誤りで、Snowpipe Streaming はサーバーレスであり、ユーザー管理のウェアハウスを必要としません。