第5章 データコラボレーション(Data Collaboration, 10%)
🎯 この節の学習目標
ゼロコピークローン(zero-copy cloning)は、データベース・スキーマ・テーブルなどの「コピー」を、データを物理的に複製せずに作成する機能です。5-1で学んだとおり、Snowflake のデータはイミュータブルなマイクロパーティションとして保存されています。クローンの作成は、同じマイクロパーティション群を指す新しいメタデータを作るだけの操作です。
-- テーブルをクローンする
CREATE TABLE sales_dev.public.orders CLONE sales.public.orders;
-- スキーマ・データベース単位でも同じ構文でクローンできる
CREATE SCHEMA sales_dev.public CLONE sales.public;
CREATE DATABASE sales_dev CLONE sales;
この仕組みから、次の性質が導かれます。
図:ゼロコピークローンの仕組み。物理データを共有し、変更された差分だけが新規ストレージになる
クローンはあらゆるオブジェクトに使えるわけではありません。試験では「何がクローンできて何ができないか」がよく問われます。
| クローン可能 | クローン不可 |
|---|---|
| データベース、スキーマ、テーブル(permanent / transient)、ストリーム、シーケンス、ビュー等を含むスキーマ階層、外部名前付きステージ、ファイルフォーマット、タスク(クローン直後は停止状態) | 外部テーブル、内部名前付きステージ(単体でのクローン)。ただし内部名前付きステージは、DB/スキーマのクローン時に INCLUDE INTERNAL STAGES を指定すれば含められる |
注意すべき細かいルールが3つあります。
クローンは 5-1 で学んだ Time Travel と組み合わせられます。AT / BEFORE 句付きの CLONE により、「過去のある時点のテーブル」を新しいテーブルとして即時に作り出せます。誤操作からの復旧手段として最も実用的なパターンです。
💡 具体例:誤更新前の状態を別テーブルとして復元する
-- 1時間前の状態のテーブルをクローンとして作成する
CREATE TABLE orders_restored CLONE orders
AT(OFFSET => -3600);
-- 誤ったUPDATE文(クエリIDで指定)の直前の状態をクローンする
CREATE TABLE orders_before_update CLONE orders
BEFORE(STATEMENT => '01b2c3d4-0000-1234-0000-000000000001');
-- 内容を確認したうえで、入れ替える
ALTER TABLE orders RENAME TO orders_broken;
ALTER TABLE orders_before_update RENAME TO orders;
元のテーブルを直接上書きせず、まず過去時点のクローンを作って内容を検証してから入れ替えるのが安全な手順です。指定した時点がソーステーブルの Time Travel 保持期間より前の場合、クローンはエラーになります。
クローンにおける権限の扱いには、明確な非対称があります。
| 対象 | 権限の引き継ぎ |
|---|---|
| クローンされたオブジェクト自体(例:CLONEで作ったテーブル) | ソースの権限を引き継がない。所有者はクローンを実行したロールになり、必要な権限は改めてGRANTする |
| クローンに含まれる子オブジェクト(例:DBクローン時の配下のスキーマ・テーブル) | ソースの子オブジェクトの権限を引き継ぐ |
また、クローンを実行するロールには、ソーステーブルに対する SELECT 権限(ステージ等では USAGE)と、作成先スキーマの CREATE TABLE 権限が必要です。
テーブルタイプについては、temporary テーブルを permanent テーブルとしてクローンすることはできません(temporary / transient としてのクローンは可能)。permanent テーブルを transient としてクローンすることはできます。
📝 試験のポイント
「データベースをクローンしたのに、クローン先のDB自体への権限が付いていない」のは仕様どおりです。クローンしたオブジェクト自体は権限を引き継がず、その中の子オブジェクトは引き継ぐ、という対比で覚えましょう。あわせて「外部テーブルはクローン不可」「内部名前付きステージは既定では含まれないが、INCLUDE INTERNAL STAGES 指定で含められる」「temporary → permanent のクローンは不可」も選択肢の定番です。
| ユースケース | 使い方 |
|---|---|
| 開発・テスト環境の即時複製 | 本番DBをクローンし、本番と同じデータで開発・テストする。ストレージの二重コストなしに、本番に影響を与えず自由に変更できる |
| バックアップポイントの作成 | 大規模なデータ変更やリリースの直前にクローンを取り、問題があればクローンから戻す |
| 過去時点の復元 | Time Travelと組み合わせ、誤操作前の状態を別テーブルとして即時に復元する |
従来のデータ基盤では「本番同等のテスト環境」を作るためにデータの物理コピーと長い待ち時間、二重のストレージ費用が必要でした。ゼロコピークローンはこれを数秒・追加コストほぼゼロに変える、Snowflake の代表的な差別化機能の1つです。
✅ この節のまとめ
問1. 10TBの本番テーブルをCREATE TABLE ... CLONEでクローンした。作成直後のストレージ課金の説明として正しいものはどれか。
正解:C
クローンはソースと同じマイクロパーティションを参照するメタデータ操作のため、作成時点では追加ストレージがほぼ発生しません。その後どちらかの側でデータが変更されると、変更分の新しいマイクロパーティションが作られ、その差分だけが課金対象になります。AとBは物理コピーが発生するという誤解です。Dは前半は正しいものの、変更後の差分は課金されるため誤りです。
問2. データベースを既定の設定(オプション指定なし)でクローンしたとき、クローンに含まれないものを2つ選べ。
正解:BとC
外部テーブルはクローンできないオブジェクトであり、データベースやスキーマをクローンした際も子オブジェクトとしてスキップされます。内部名前付きステージも既定(未指定)ではクローンに含まれませんが、こちらはCLONE文に INCLUDE INTERNAL STAGES を指定すれば含めることができます(ディレクトリテーブルが有効ならファイルもコピーされます)。Aのpermanentテーブルはクローンの中心的な対象です。Dのストリームもクローン可能なオブジェクトに含まれます。なお、テーブル自体はクローンされてもテーブルステージ内のファイルはコピーされない点もあわせて覚えておきましょう。
問3. クローンにおける権限の引き継ぎについて、正しい説明はどれか。
正解:B
クローンで作成されたオブジェクト自体(たとえばクローンしたデータベースそのもの)はソースの権限を引き継がず、所有者は実行したロールになります。一方、そのクローンに含まれる子オブジェクト(配下のスキーマやテーブル)はソースの対応するオブジェクトの権限を引き継ぎます。A・C・Dはいずれもこの非対称なルールと矛盾します。
問4. Time Travelとクローンの併用に関する説明として正しいものはどれか。
正解:A
CLONE文にAT / BEFORE句を付けることで、Time Travel保持期間内の任意の時点の状態を新しいオブジェクトとして即時に作成でき、誤操作からの復旧に最も実用的な手段になります。Bは過去時点のクローンが可能である点と矛盾します。Cは誤りで、保持期間より前の時点を指定するとエラーになります。Dはそもそもtemporary → permanentのクローンができないため誤りです。