第3章 データロード・アンロードと接続(Loading, Unloading & Connectivity, 18%)
🎯 この節の学習目標
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');
Snowpipe に「新しいファイルが来た」と知らせる方法は2つあります。
| 方式 | 仕組み | 典型的な構成 |
|---|---|---|
| AUTO_INGEST = TRUE (クラウドイベント通知) | 外部ステージのクラウドストレージが発行するイベント通知(S3 イベント通知など)を受け取り、自動でロードを開始する | S3 / Azure Blob / GCS 上の外部ステージにファイルが置かれると自動的にロードされる構成 |
| REST API 呼び出し | アプリケーションが Snowpipe の REST エンドポイントを呼び出し、ロードすべきファイル名を明示的に通知する | ファイル生成側のアプリが自らロードをキックする構成。内部ステージでも使える |
図:Snowpipe による自動取り込みの流れ。ファイル到着がイベント通知経由でロードのトリガーになる
📝 試験のポイント
「S3 に置かれたファイルを自動でロードし続けたい。ウェアハウスの管理はしたくない」という要件には Snowpipe(AUTO_INGEST = TRUE)が答えです。トリガーの2方式(クラウドのイベント通知 / REST API)はどちらも出題されるので、セットで覚えましょう。
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 と役割を分けて覚えておきましょう。
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 によるロードも収録される。長期の監査・傾向分析向き(反映に遅延あり) |
Snowpipe が「ファイル」を単位とするのに対し、Snowpipe Streaming はファイルを経由せず、行(row)単位でデータを直接テーブルに書き込む仕組みです。
ここまでの3つのロード方式を1つの表に整理します。この比較は本章の要となる知識です。
| バルクロード(COPY INTO) | Snowpipe | Snowpipe Streaming | |
|---|---|---|---|
| トリガー | ユーザー(またはタスク)が手動・スケジュールで実行 | ファイル到着(イベント通知)または REST API | アプリケーションが SDK のチャネル経由で行を送信 |
| 単位 | ファイル(一括) | ファイル(マイクロバッチ) | 行(ファイルを経由しない) |
| レイテンシ | 実行タイミング次第(バッチ) | 通常は分のオーダー | 秒レベル |
| コンピュート・課金 | ユーザー管理の仮想ウェアハウスの稼働時間 | サーバーレス+ファイルあたりのオーバーヘッド | サーバーレス(行の取り込み量ベース) |
| 重複防止メタデータの保持 | 64日 | 14日 | チャネルのオフセットで管理 |
| 向く場面 | 定期バッチ、大量データの初期ロード | ファイルが随時到着する継続的ロード | IoT・イベントデータなど行単位の連続ストリーム |
✅ この節のまとめ
問1. S3 バケットに随時到着するファイルを、ウェアハウスを管理せずに自動でロードし続けたい。最も適切な方法はどれか。
正解:B
「随時到着」「自動」「ウェアハウス管理不要」という要件は、AUTO_INGEST = TRUE の Snowpipe がそのまま満たします。Aはウェアハウスの常時稼働コストと手動運用が発生し、要件に反します。Cの PUT はローカルからのアップロードコマンドで、S3 からの自動ロードとは無関係です。Dは1回きりの強制再ロードにすぎず、継続的な取り込みにはなりません。
問2. Snowpipe の課金に関する説明として正しいものはどれか。
正解:C
Snowpipe はサーバーレスコンピュートの使用量と、ファイルあたりのオーバーヘッドで課金されます。この構造があるため、極端に小さいファイルを大量に流すと割高になります。Aは COPY INTO の課金の考え方で、Snowpipe はユーザーのウェアハウスを使いません。Bのように無料ではなく、Dのような固定料金制でもありません。
問3. ロード履歴(重複ロード防止用メタデータ)の保持期間の組み合わせとして正しいものはどれか。
正解:B
バルクロードのロードメタデータはテーブルに64日、Snowpipe のロード履歴はパイプに14日保持されます。Aは数字が逆です。CとDは保持期間の違いを無視しており誤りです。この「64日と14日」の対比はそのまま問われることが多いので、確実に覚えておきましょう。
問4. Snowpipe Streaming の説明として正しいものはどれか(2つ選べ)。
正解:B・C
Snowpipe Streaming は SDK のチャネル経由で行単位に書き込み、ファイルの作成・ステージングを挟まないため秒レベルのレイテンシを実現します。Aは(通常の)Snowpipe の説明で、Streaming はファイルを単位としません。Dは誤りで、Snowpipe Streaming はサーバーレスであり、ユーザー管理のウェアハウスを必要としません。