第3章 データロード・アンロードと接続(Loading, Unloading & Connectivity, 18%)
🎯 この節の学習目標
Snowflake では、ファイルからテーブルへデータをロードするとき(またはその逆のアンロードのとき)、ファイルをいったんステージ(stage)と呼ばれる置き場に置きます。ステージは「ファイルの中継地点」であり、置き場所が Snowflake の内部にあるか外部のクラウドストレージにあるかで、大きく内部ステージと外部ステージの2つに分かれます。
図:ステージの種類とデータロードの流れ。ファイルはいずれかのステージを経由してテーブルにロードされる
内部ステージ(internal stage)は、Snowflake が管理するストレージ上のファイル置き場です。3種類があり、それぞれ記法と性質が異なります。この対応付けは試験で問われやすいので、正確に覚えましょう。
| 種類 | 記法 | 特徴 |
|---|---|---|
| ユーザーステージ | @~ | 各ユーザーに自動的に1つ割り当てられる。作成・削除は不可。そのユーザーだけがアクセスでき、他のユーザーと共有できない。1人のユーザーが複数テーブルにロードするファイルを置く用途に向く |
| テーブルステージ | @%table_name | 各テーブルに自動的に1つ割り当てられる。作成・削除は不可。そのテーブルへのロード専用で、他のテーブルへはロードできない。ファイルフォーマットオブジェクトを紐付けることもできない |
| 名前付き内部ステージ | @stage_name | CREATE STAGE で明示的に作成するデータベースオブジェクト。権限(GRANT)による共有が可能で、複数ユーザー・複数テーブルのロードに使える。最も柔軟で、実務でもこの形が推奨 |
📝 試験のポイント
「@~・@%・@ の記法はそれぞれどのステージか」「削除できないステージはどれか」という形で問われます。@~=ユーザーステージ、@%=テーブルステージ(いずれも自動作成・削除不可)、@=名前付きステージ(作成・権限管理が可能)と整理しましょう。また、テーブルステージにあるファイルはそのテーブル以外へロードできない点、ユーザーステージは他ユーザーと共有できない点が、名前付きステージを推奨する理由としてよく出題されます。
外部ステージ(external stage)は、顧客が管理するクラウドストレージ(Amazon S3 / Azure Blob Storage / Google Cloud Storage)上の場所を参照するステージです。ファイルの実体は Snowflake の外にあり、Snowflake はそこを「指し示す」だけです。
-- storage integration を使った外部ステージの作成(推奨)
CREATE STAGE my_ext_stage
URL = 's3://my-bucket/load/'
STORAGE_INTEGRATION = my_s3_int
FILE_FORMAT = my_csv_format;
外部ステージを作るとき、クラウドストレージへのアクセス資格情報が必要になります。SQL 文に秘密キーを直接書く方法もありますが、推奨されるのは storage integration オブジェクトを使う方法です。storage integration は IAM ロールなどのクラウド側の仕組みで認証を委任するため、資格情報(シークレット)を SQL に書かずに済みます。詳細は 3-6 で扱います。
ステージ上のファイルは、次の4つのコマンドで操作します。
| コマンド | 方向・役割 | 注意点 |
|---|---|---|
| PUT | ローカルマシン → 内部ステージへのアップロード | 既定でgzip 自動圧縮される。Snowsight(Web UI)のワークシートからは実行不可で、SnowSQL などの CLI・ドライバから実行する。外部ステージへの PUT は不可 |
| GET | 内部ステージ → ローカルマシンへのダウンロード | PUT の逆方向。こちらも CLI・ドライバから実行する |
| LIST | ステージ上のファイル一覧を表示 | 内部・外部どちらのステージにも使える(LIST @my_stage;) |
| REMOVE | ステージ上のファイルを削除 | ロード完了後の後片付けに使う(3-2 の PURGE オプションでも代替可) |
💡 具体例:ローカルファイルを名前付きステージ経由でロードする準備
-- 名前付き内部ステージを作成する
CREATE STAGE my_stage
FILE_FORMAT = (TYPE = 'CSV' SKIP_HEADER = 1);
-- SnowSQL(CLI)からローカルファイルをアップロードする
-- 既定で自動的に gzip 圧縮される(AUTO_COMPRESS = TRUE)
PUT file:///data/sales_2026*.csv @my_stage;
-- ステージ上のファイルを確認する
LIST @my_stage;
-- ロード完了後にファイルを削除する
REMOVE @my_stage PATTERN = '.*sales_2026.*';
PUT はワイルドカードで複数ファイルを一括アップロードできます。「PUT は Snowsight のワークシートから実行できない」という制約は、試験でも実務でもつまずきやすいポイントです。
ステージ上のファイルを正しく読み取るには、ファイルの形式(区切り文字、ヘッダーの有無、圧縮方式など)を Snowflake に伝える必要があります。これを担うのがファイルフォーマット(file format)です。Snowflake がロード・アンロードでサポートする形式は次のとおりです。
| 形式 | 分類 | 備考 |
|---|---|---|
| CSV(区切りテキスト) | 構造化 | 最も一般的。区切り文字は任意に指定可能 |
| JSON | 半構造化 | VARIANT 型へのロードが典型(2-4 参照) |
| Avro | 半構造化 | 行指向のバイナリ形式 |
| ORC | 半構造化 | 列指向のバイナリ形式 |
| Parquet | 半構造化 | 列指向のバイナリ形式。アンロード先としても指定可能 |
| XML | 半構造化 | ロードのみサポート |
フォーマット指定は COPY 文の中に直接書くこともできますが、名前付きファイルフォーマットオブジェクトとして作成しておくと、複数のステージや COPY 文から再利用できて管理しやすくなります。
-- 名前付きファイルフォーマットの作成
CREATE FILE FORMAT my_csv_format
TYPE = 'CSV'
FIELD_DELIMITER = ','
SKIP_HEADER = 1
NULL_IF = ('NULL', '');
-- ステージに紐付けておけば COPY 時の指定を省略できる
CREATE STAGE my_stage FILE_FORMAT = my_csv_format;
Snowflake のロードは、複数ファイルを並列に処理することで高速化されます。そのため、1つの巨大なファイルより、適切なサイズに分割された複数ファイルの方が効率的です。推奨は「圧縮済みでおよそ 100〜250MB 程度」のファイルに分割することです。
📝 試験のポイント
「ロードを高速化するにはどうすべきか」という問いに対して、「ファイルを圧縮済み 100〜250MB 程度に分割して並列ロードを活かす」が定番の答えです。「ウェアハウスをとにかく大きくする」だけでは、ファイルが1つしかなければ並列化できない点に注意しましょう(ウェアハウスサイズとファイル数の関係は 3-2 で扱います)。
✅ この節のまとめ
問1. 複数のユーザーが複数のテーブルにデータをロードするためにファイルを共有したい。最も適切なステージはどれか。
正解:C
名前付き内部ステージはデータベースオブジェクトとして作成され、権限(GRANT)によって複数ユーザーで共有でき、任意のテーブルへのロードに使えます。Aのユーザーステージは所有ユーザーしかアクセスできず共有できません。Bのテーブルステージはそのテーブルへのロード専用で、他のテーブルにはロードできません。Dの結果キャッシュはクエリ結果を保持するクラウドサービス層の仕組みで、ファイル置き場ではありません。
問2. PUT コマンドの説明として正しいものはどれか(2つ選べ)。
正解:A・C
PUT はローカル→内部ステージへのアップロードコマンドで、既定(AUTO_COMPRESS = TRUE)で gzip 圧縮が自動適用されます。Bは GET コマンドの説明です。Dは誤りで、PUT は Snowsight のワークシートからは実行できず、SnowSQL などの CLI やドライバから実行します。
問3. テーブルステージ(@%table)の説明として誤っているものはどれか。
正解:B
テーブルステージは対応するテーブルへのロード専用であり、他のテーブルへはロードできません。したがってBが誤りです。A・C・Dはいずれもテーブルステージの正しい性質です。複数テーブルへのロードにファイルを使い回したい場合は、名前付き内部ステージを使います。
問4. 大量データのロードを高速化するためのファイル準備として、最も適切なものはどれか。
正解:B
Snowflake のロードはファイル単位で並列化されるため、圧縮済み100〜250MB程度への分割が推奨です。Aは並列化できず遅くなります。Cは極端に小さいファイルが大量になり、ファイルごとのオーバーヘッドで非効率です。Dも誤りで、圧縮ファイルのロードはサポートされており、転送量削減のためにも圧縮が一般的です(PUT なら自動圧縮されます)。