❄️

COPYコマンドと何が違う？ Snowflake「Snowpipe」自動取り込み入門

2025/11/19に公開

 😱 S3にファイルが来たか、まだ手動で確認していませんか？Snowflake を使い始めた皆さん。

こんな運用をしていませんか？
「毎朝9時に、S3 の uploads/ フォルダにファイルが置かれているか確認する」

「ファイルが来ていたら、Snowsight を開いて COPY コマンドを手動で実行…」

「あるいは、1時間に1回 TASK を設定して、COPY コマンドを定期実行している」
これらは、Snowflake の伝統的な「バッチロード」の方法ですよね。
でも、こんな風に思ったことはありませんか？

「ファイルが TASK の実行直後に S3 に置かれたら、次の実行まで59分も待つことになる…」

「そもそも、ファイルが来たかどうかを人間や TASK が見に行くのではなく、Snowflake 側に自動で検知してほしい！」
その悩み、「Snowpipe (スノーパイプ)」 が解決してくれます。
この記事は、「COPY コマンドは知っているけれど、Snowpipe はよくわからない」という初心者の方に向けて、その仕組み、COPY との決定的な違い、そしてコストの考え方までをまとめました。
また、今回の記事の発端は、以下のイベントに参加した際に喜田さんのLTセッションで Preview機能 だが 内部ステージでもAuto-ingestでSnowpipeを利用できる ことを知ったからでした。

なので、この検証を自身でもしたく、その前段として  Snowpipe について記事にしました！

https://techplay.jp/event/987536
↓喜田さんのLTセッションの資料抜粋

Snowflake DataSuperheroes 喜田さん：https://x.com/kkkida_twtr

 ❓ 1. Snowpipe とは？一言でいうと、Snowpipe は

「ステージ（外部 / 内部）上の新しいファイルを検知して、自動でロードするサーバレスな仕組み」

です。
COPY コマンドとの違いを、荷物の配送に例えてみましょう。

 アナロジー：「ダンプカー」 vs 「スマート・コンベアベルト」COPY コマンド（バッチロード）
これは「ダンプカー」です。
あなた（または TASK）が「1時間に1回」と決めたスケジュールで、ダンプカー（＝仮想ウェアハウス）を起動します。
倉庫（S3など）に行って、そこにある荷物（ファイル）をまとめて積み込み、Snowflake に運びます。

弱点: スケジュール実行なので、レイテンシ（遅延）が大きいです。荷物が少量でもダンプカー（ウェアハウス）を動かすので、非効率になることがあります。
Snowpipe（マイクロバッチ・ストリーミング）
これは「スマート・コンベアベルト」です。
倉庫（S3など）に荷物（ファイル）が1つ置かれた瞬間、倉庫側が「荷物が来たよ！」と通知を送ります。
その通知を受け取ったコンベアベルト（Snowpipe）が自動で動き出し、その荷物1つをすぐに Snowflake に運びます。

強み: イベント駆動なので、レイテンシ（遅延）が小さい（通常は数十秒〜数分程度でロードが完了するニアリアルタイム）です。ウェアハウスを常時起動させておく必要がありません。

 ⚖️ 2.【最重要】COPY コマンドと Snowpipe の比較この2つは、技術的な仕組みとコストが全く異なります。


比較軸

COPY コマンド (バッチ)

Snowpipe (マイクロバッチ)


実行トリガー

手動 または スケジュール ( TASK )

イベント駆動 ( AUTO_INGEST = TRUE など )

レイテンシ

大きい (例: 1時間ごと、1日ごと)

小さい (例: 数十秒〜数分 (ニアリアルタイム))

コンピューティング

ユーザー管理 (仮想ウェアハウス)

Snowflake 管理 (サーバレス)

コスト（WH）
仮想ウェアハウスの稼働クレジット
仮想ウェアハウスを使用しない


コスト（Snowpipe）
(かからない)
Snowpipe サーバーレス compute コスト

主な用途
夜間バッチ、大規模な初期ロード
ログデータのストリーミング、IoT、分析ダッシュボードの即時反映

COPY は「自分（ユーザー）のウェアハウス」のクレジットを消費します。

Snowpipe は「自分（ユーザー）のウェアハウス」を使わず、代わりに Snowflake が管理するサーバレスリソースを使い、その分だけが課金されます。

 ⚙️ 3. Snowpipe はどう動いているのか？ (Auto-Ingest)Snowpipe が「ファイルが来た！」と知る仕組みが一番のキモです。

ここでは代表例として S3 (AWS) を例に解説します。（GCS / Azure Blob でも同様の仕組みがサポートされています）

ファイル到着
ユーザーが S3 バケット（例: my-bucket/new-files/）に log_001.csv をアップロードします。


イベント通知 (S3 -> SQS)
S3 が「new-files フォルダに新しいファイルが CREATE された」というイベントを発行します。
このイベントは、AWS の SQS（Simple Queue Service）というキュー（メッセージの待合室）に送られます。


Snowflake の検知 (Snowpipe Service)
Snowflake 側では、Snowpipe サービスが SQS キューを監視しています。
新しいメッセージを検知すると、そのメッセージに対応する PIPE オブジェクトを特定します。


ロード実行
Snowpipe サービスは、Snowflake のサーバレスリソースを使って PIPE に定義された COPY コマンドを実行し、データをテーブルに取り込みます。

この「S3 → SQS → Pipe」という一連の流れが、Snowpipe 自動取り込み (Auto-Ingest) の正体です。

 🛠️ 4. Snowpipe の設定（概念とSQL例）実際に Snowpipe を設定するには、Snowflake 側で以下のオブジェクトを作成します。

（※ AWS側のIAMロール設定は完了している前提です）

 ステップ1：Storage Integration (IAM連携)「Snowflake が、あなたの S3 バケットを読んでも安全ですよ」という信頼関係を（IAM ロールを使って）結ぶためのオブジェクトです。
CREATE STORAGE INTEGRATION S3_INT
  TYPE = EXTERNAL_STAGE
  STORAGE_PROVIDER = S3
  ENABLED = TRUE
  STORAGE_AWS_ROLE_ARN = 'arn:aws:iam::...'
  STORAGE_ALLOWED_LOCATIONS = ('s3://my-bucket/new-files/');

 ステップ2：Stage (S3 の場所)COPY コマンドでもお馴染みのステージです。

ここで「ストレージの場所（S3_INT）」を定義します。
CREATE STAGE MY_STAGE
  URL = 's3://my-bucket/new-files/'
  STORAGE_INTEGRATION = S3_INT;

 ステップ3：Pipe (COPY コマンドの定義)これが Snowpipe の本体です。AUTO_INGEST = TRUE を指定することで、イベント駆動モードになります。
-- 「MY_PIPE」という名前の Pipe を作成する
CREATE OR REPLACE PIPE MY_DB.MY_SCHEMA.MY_PIPE
  -- ★ この True が自動取り込みのスイッチ
  AUTO_INGEST = TRUE
  AS
    -- ★ 実行する COPY コマンドの定義
    COPY INTO MY_TABLE
    FROM @MY_STAGE
    FILE_FORMAT = (TYPE = 'CSV' FIELD_OPTIONALLY_ENCLOSED_BY = '"')
    ON_ERROR = 'SKIP_FILE';

 ステップ4：AWS側との紐付け (NOTIFICATION_CHANNEL)Pipe を作成したら、Snowflake が発行した「SQS キューの宛先」を確認し、AWS S3 側に設定する必要があります。
-- Pipe の情報を確認
DESC PIPE MY_DB.MY_SCHEMA.MY_PIPE;
-- 結果の「NOTIFICATION_CHANNEL」列にある値（arn:aws:sqs:...）をコピーします
最後の仕上げ（AWS側）:

S3 バケットの「イベント通知」設定で、コピーした NOTIFICATION_CHANNEL (SQS ARN) を通知先に指定します。
これで、S3 にファイルが置かれるたびに、MY_PIPE が自動で動くようになります。

 ✌️ 5. Snowpipe の「もう一つ」の顔 (REST API)実は、Snowpipe にはもう一つの使い方があります。

それが「Snowpipe REST API」です。
これは、S3 のイベント通知（自動）を使うのではなく、

「自社のアプリケーション側から、能動的に Snowpipe を呼び出す」方法です。
自社アプリが S3 に log_002.csv をアップロード完了。
自社アプリが、Snowflake の insertFiles という REST API エンドポイントを叩く。
(リクエスト本文: 「log_002.csv をロードしてください」)

Snowpipe が起動し、PIPE に定義された COPY コマンドで log_002.csv をロードする。
S3 のイベント通知設定（SQSなど）が複雑で難しい場合や、アプリケーション側で厳密にロードのタイミングを制御したい場合に利用されます。

 🏠 6. 補足：Snowpipe × 内部ステージここまでの説明では S3 などの「外部ステージ」を前提に Snowpipe を説明してきましたが、実は Snowpipe は 内部ステージ とも組み合わせることができます。

 パターン1：REST API + 内部ステージ（GA）Snowpipe の REST API (insertFiles など) では、stageLocation に 内部ステージ (ユーザステージ / テーブルステージ / 名前付き内部ステージ) を指定できます。
アプリケーションから PUT コマンドなどで内部ステージにファイルをアップロード
アプリケーション側から Snowpipe REST API で「このファイルをロードして」とリクエスト
Snowpipe が、Pipe に定義された COPY INTO を使ってテーブルにロード
という流れで、外部ステージを介さずに内部ステージだけで Snowpipe を使うことも可能です。

 パターン2：Auto-ingest + 内部ステージ（プレビュー）2025 年時点では、AWS 上のアカウントを対象に、internal stage（named internal stage / table stage。user stage は対象外）に対して AUTO_INGEST = TRUE を利用できる Snowpipe のプレビュー機能が提供されています。
これにより、これまで外部ステージ（S3 / GCS / Azure）に限定されていた「イベント駆動の自動取り込み」を、内部ステージに対しても利用できるようになりつつあります。
ここの内容が冒頭の喜田さんのLTで話があった部分となります！
!詳細な要件や対応クラウドについては、必ず最新のリリースノートとドキュメントを確認してください。

 💸 7. Snowpipe のコストと「罠」Snowpipe は非常に便利ですが、コストについて重大な注意点があります。

 課金モデル（2025年時点）Snowpipe の料金モデルは、アカウントのエディションやタイミングによって 2 パターンあります。

従来モデル: Snowpipe が内部で使用したサーバレスコンピュート（時間） ＋ 管理オーバーヘッドに基づいて課金されます。

新モデル: ロードしたデータ量（GB）に対して固定のクレジット単価で課金されます。
2025 年 8 月 1 日以降、Business Critical / VPS エディションでは（この記事執筆時点の公式ドキュメントによると）新しい「GB 課金」モデルが順次適用されており、Standard / Enterprise も今後移行予定です。

 罠：1000個の「1KB」ファイル vs 1個の「1MB」ファイルどちらの課金モデルであっても、Snowpipe の課金は「ファイルが細かすぎると高額になる」という特性を持っています。
もし、IoT センサーから1秒に1回、1KB のような「極小ファイル」が大量に S3 に送られてくるとどうなるでしょう？

COPY の場合: 1時間に1回、まとめて 3600 ファイルをロード。ウェアハウスが数秒動くだけ。

Snowpipe の場合: 3600回起動します。
従来のコンピュート（時間）課金モデルでは、ファイルごとのオーバーヘッド（キュー管理・メタデータ処理）が余計なコンピュート時間を消費します。

新しい「GB課金」モデルでも、内部的には PIPE_USAGE_HISTORY で BYTES_BILLED (課金対象バイト) が管理されており、小さいファイルを大量に送ると、このオーバーヘッド分が加算されやすくなるため、結果的に割高になります。
!Snowpipe のベストプラクティス

Snowpipe は、小さすぎるファイルを大量に処理するのは苦手です。

ごく小さいファイル（<100KB）を大量に送るのは避け、数十MB〜数百MB程度のファイルにまとめて Snowpipe に渡すことが推奨されています。
もしファイルが小さすぎる場合は、S3 側で Lambda や Kinesis Firehose などを使って、ファイルをある程度のサイズ（例: 1分ごと、数十MBごと）にバッチ化（まとめて1つのファイルに）してから S3 に置く、というアーキテクチャが一般的なようです。

 😌 おわりにCOPY と Snowpipe の違い、ご理解いただけたでしょうか？

COPY (ダンプカー): スケジュール実行。自分でウェアハウスを起動。バッチ処理向き（レイテンシ大）。

Snowpipe (コンベアベルト): イベント駆動。サーバレス。ニアリアルタイム処理向き（レイテンシ小）。
Snowpipe は、データが到着した瞬間に（通常は数分以内に）分析を開始できる、非常に強力な機能です。

しかし、「ファイルが細かすぎると高額になる」というコスト特性を理解することが重要です。
まずは、自身のユースケースが「日次バッチ」で十分なのか、「ニアリアルタイム」が必要なのかを判断し、適切なロード方法を選択してみると良いと思います！
次回は実際に検証をした、Auto-ingest + 内部ステージ（プレビュー） の記事予定、、、

 📚 参考出典Snowflake公式: Snowpipe の概要
Snowflake公式: Amazon S3 用の Snowpipe の自動化 (構成手順)
Snowflake公式: CREATE PIPE
Snowflake公式: Snowpipe のコストに関する考慮事項
Snowflake公式: Snowpipe REST API (内部ステージ対応)

比較軸	`COPY` コマンド (バッチ)	`Snowpipe` (マイクロバッチ)
実行トリガー	手動またはスケジュール ( `TASK` )	イベント駆動 ( `AUTO_INGEST = TRUE` など )
レイテンシ	大きい (例: 1時間ごと、1日ごと)	小さい (例: 数十秒〜数分 (ニアリアルタイム))
コンピューティング	ユーザー管理 (仮想ウェアハウス)	Snowflake 管理 (サーバレス)
コスト（WH）	仮想ウェアハウスの稼働クレジット	仮想ウェアハウスを使用しない
コスト（Snowpipe）	(かからない)	Snowpipe サーバーレス compute コスト
主な用途	夜間バッチ、大規模な初期ロード	ログデータのストリーミング、IoT、分析ダッシュボードの即時反映

COPYコマンドと何が違う？ Snowflake「Snowpipe」自動取り込み入門

😱 S3にファイルが来たか、まだ手動で確認していませんか？

❓ 1. Snowpipe とは？

アナロジー：「ダンプカー」 vs 「スマート・コンベアベルト」

⚖️ 2.【最重要】`COPY` コマンドと `Snowpipe` の比較

⚙️ 3. Snowpipe はどう動いているのか？ (Auto-Ingest)

🛠️ 4. Snowpipe の設定（概念とSQL例）

ステップ1：Storage Integration (IAM連携)

ステップ2：Stage (S3 の場所)

ステップ3：Pipe (COPY コマンドの定義)

ステップ4：AWS側との紐付け (NOTIFICATION_CHANNEL)

✌️ 5. Snowpipe の「もう一つ」の顔 (REST API)

🏠 6. 補足：Snowpipe × 内部ステージ

パターン1：REST API + 内部ステージ（GA）

パターン2：Auto-ingest + 内部ステージ（プレビュー）

💸 7. Snowpipe のコストと「罠」

課金モデル（2025年時点）

罠：1000個の「1KB」ファイル vs 1個の「1MB」ファイル

😌 おわりに

📚 参考出典

Discussion