Snowflake の Zero-Copy Cloning を理解する
Snowflake の Zero-Copy Cloning を使うと、ストレージを物理的にコピーせずにテーブルやデータベースを瞬時に複製できます。この記事では仕組み・構文・業務での使いどころ・ハマりやすいポイントまでまとめます。
Zero-Copy Cloning とは
Zero-Copy Cloning は、Snowflake が持つメタデータ操作によるクローン機能です。既存のマイクロパーティション(Snowflake の内部ストレージ単位)へのポインタを複製するだけなので、クローン直後はストレージ使用量が増えません。
クローン後にどちらかのオブジェクトを変更した場合のみ、変更差分のマイクロパーティションが追加で書き込まれます(Copy-on-Write)。
クローンできるオブジェクト
| オブジェクト | クローン可否 |
|---|---|
| テーブル | ✅ |
| 外部テーブル | ❌ |
| スキーマ | ✅(配下のテーブルをまとめてクローン) |
| データベース | ✅(配下のスキーマ・テーブルをまとめてクローン) |
| ステージ | ✅(メタデータのみ。外部ステージのファイルはコピーされない) |
| パイプ・タスク・ストリーム | ✅(ただし状態はリセットされる) |
基本構文
-- テーブルのクローン
CREATE TABLE orders_clone CLONE orders;
-- スキーマのクローン
CREATE SCHEMA analytics_dev CLONE analytics;
-- データベースのクローン
CREATE DATABASE prod_snapshot CLONE prod_db;
Time Travel を組み合わせたクローン
過去の時点のデータをクローンする場合は AT または BEFORE を指定します。
-- 1 時間前の状態をクローン
CREATE TABLE orders_hourago CLONE orders
AT (OFFSET => -3600);
-- 特定のタイムスタンプ時点をクローン
CREATE TABLE orders_snapshot CLONE orders
AT (TIMESTAMP => '2026-04-30 12:00:00'::TIMESTAMP_LTZ);
-- 特定のクエリ ID 実行直前の状態をクローン
CREATE TABLE orders_before_load CLONE orders
BEFORE (STATEMENT => '019b6f43-0000-1234-...');
Time Travel の保持期間(デフォルト 1 日、最大 90 日)の範囲内であれば過去のスナップショットをクローンできます。
コスト感
| 状況 | ストレージコスト |
|---|---|
| クローン直後(変更なし) | 追加コストなし |
| クローン元を更新 | 変更されたマイクロパーティション分だけ追加 |
| クローン先を更新 | 変更されたマイクロパーティション分だけ追加 |
| 両方を削除 | 参照がなくなったパーティションが解放される |
クローンしたオブジェクトは独立したオブジェクトとして請求対象になるため、長期保持するテーブルが増えれば当然コストは上がります。
業務での使いどころ
1. 開発・テスト環境の即時構築
本番データベース全体を開発環境として複製できます。数 TB のデータでも数秒〜数十秒で完了するため、スプリントごとにリセットするといった運用が現実的になります。
-- 毎朝本番 DB を開発環境としてリフレッシュ
CREATE OR REPLACE DATABASE dev_db CLONE prod_db;
2. デプロイ前のバックアップ
大規模な INSERT / UPDATE / DELETE を実行する前にスナップショットを取ることで、ロールバック手段を確保できます。
-- 大規模マイグレーション前にクローン
CREATE TABLE orders_backup_20260502 CLONE orders;
-- マイグレーション失敗時にリストア
CREATE OR REPLACE TABLE orders CLONE orders_backup_20260502;
3. データ品質チェック
パイプラインの変更が本番データを壊さないか事前に検証したいときに有効です。
-- ステージング環境でパイプラインを試す
CREATE TABLE staging.fact_sales CLONE prod.fact_sales;
-- → staging テーブルに対して変換ロジックをテスト
4. レポート用スナップショット
月次・週次の締め日に現状のテーブルをクローンしておくと、集計後もその時点のデータを参照できます。
CREATE TABLE orders_202604 CLONE orders
AT (TIMESTAMP => '2026-04-30 23:59:59'::TIMESTAMP_LTZ);
ハマりやすいポイント
権限はクローンされない
テーブル・スキーマ・データベースに設定されている GRANT はクローンに引き継がれません。クローン後に改めて権限を付与する必要があります。
-- クローン後は権限が空なので再付与が必要
GRANT SELECT ON TABLE orders_clone TO ROLE analyst;
ストリームのオフセットはリセットされる
テーブルをクローンした場合、そのテーブルに紐づくストリームもクローンできますが、CDC オフセットはリセットされます。クローン先で新たにストリームを作り直すほうが安全です。
外部テーブルはクローン不可
S3 などを参照する外部テーブルはクローンできません。スキーマやデータベースをクローンする際に外部テーブルが含まれている場合はエラーになります。
-- 外部テーブルを除外してクローンしたい場合は手動で対応が必要
-- 外部テーブル以外のオブジェクトを個別にクローンする
Time Travel 期間外は参照不可
AT や BEFORE を使ったクローンは Time Travel の保持期間内のデータにしかアクセスできません。Standard Edition はデフォルト 1 日、Enterprise Edition は最大 90 日です。
クローンはストレージを共有するが独立して削除される
クローン元を DROP しても、クローン先のデータは失われません(参照しているマイクロパーティションは保持されます)。逆にクローン先を DROP してもクローン元には影響しません。
まとめ
| ポイント | 内容 |
|---|---|
| コスト | クローン直後はほぼ無料。差分のみ課金 |
| 速度 | テーブルサイズに関係なくほぼ即時 |
| 主な用途 | 開発環境構築・デプロイ前バックアップ・スナップショット |
| 注意点 | 権限・ストリームオフセット・外部テーブルの非対応 |
Zero-Copy Cloning は Snowflake の中でも特に費用対効果の高い機能の一つです。本番データを安全に扱いながら開発スピードを上げたい場面で積極的に活用してください。