第5章 データコラボレーション(Data Collaboration, 10%)
🎯 この節の学習目標
Secure Data Sharingは、Snowflakeアカウント間でデータベースのオブジェクトをデータをコピー・転送することなく共有する仕組みです。従来のデータ共有はファイルの書き出し・転送・取り込みという「データのコピーの連鎖」であり、鮮度の低下・二重管理・セキュリティリスクを伴いました。Snowflakeではデータの実体はプロバイダ(提供側)のストレージに置かれたままで、コンシューマ(利用側)はクラウドサービス層のメタデータを通じて同じデータを直接参照します。
この仕組みから、次の重要な性質が導かれます。
共有の単位となるオブジェクトがシェア(share)です。プロバイダは次の流れでダイレクトシェア(direct share)を設定します。
💡 具体例:シェアの作成から共有まで
-- 1. シェアを作成する
CREATE SHARE sales_share;
-- 2. 共有するオブジェクトへの権限をシェアに付与する
GRANT USAGE ON DATABASE sales TO SHARE sales_share;
GRANT USAGE ON SCHEMA sales.public TO SHARE sales_share;
GRANT SELECT ON VIEW sales.public.orders_secure_v TO SHARE sales_share;
-- 3. コンシューマアカウントをシェアに追加する
ALTER SHARE sales_share ADD ACCOUNTS = xy12345;シェアに付与できるのはUSAGE(DB・スキーマ)やSELECT(テーブル・セキュアビュー)などの読み取り系権限です。1つのシェアには複数のコンシューマアカウントを追加できます。
コンシューマ側は、受け取ったシェアからデータベースを作成して利用します。
-- コンシューマ側:シェアからデータベースを作成する(1シェアにつき1つ)
CREATE DATABASE sales_from_partner FROM SHARE provider_org.provider_account.sales_share;
-- あとは通常のデータベースと同じようにクエリできる(読み取りのみ)
SELECT * FROM sales_from_partner.public.orders_secure_v;図:Secure Data Sharingの全体像。データは常にプロバイダ側にあり、共有はメタデータ操作だけで成立する
シェアから作成したデータベースは、通常のデータベースといくつかの点で異なります。
| 制約 | 内容 |
|---|---|
| 読み取り専用 | 共有データベースへのINSERT / UPDATE / DELETEや、オブジェクトの作成・変更はできない |
| 再共有不可 | コンシューマが共有されたデータをさらに別のアカウントへ共有することはできない |
| Time Travel不可 | 共有データベースに対してAT / BEFORE句によるTime Travelクエリはできない |
| クローン不可 | 共有データベースやその配下のオブジェクトをクローンすることはできない |
| 複数DBにまたがるシェア | 1つのシェアに複数のデータベースのオブジェクトを含める場合、参照先のDBにもUSAGE権限(REFERENCE_USAGE)をシェアへ付与する必要がある(セキュアビューが別DBのテーブルを参照する場合など) |
テーブルをそのままシェアに載せることもできますが、ベストプラクティスはセキュアビュー(secure view)やセキュアUDFを介して共有することです。理由は2つあります。
-- 共有用のセキュアビュー:コンシューマに見せたい行・列だけに絞る
CREATE SECURE VIEW sales.public.orders_secure_v AS
SELECT order_id, order_date, amount
FROM sales.private.orders
WHERE region = 'APAC';📝 試験のポイント
「外部アカウントへの共有にはどのビューを使うべきか」と問われたらセキュアビューが答えです。通常のビューはシェアに含められず、セキュアビュー・セキュアマテリアライズドビュー・セキュアUDFが共有の対象になります。あわせて「コンシューマは読み取り専用・再共有不可・Time Travel不可」「ストレージ費用なし・コンピュート費用は自己負担」という組み合わせも定番論点です。
共有したい相手がSnowflakeアカウントを持っていない場合のために、リーダーアカウント(reader account)という仕組みがあります。
| 項目 | 内容 |
|---|---|
| 作成者 | プロバイダが自分のアカウント配下に作成し、管理する |
| できること | プロバイダから共有されたデータのクエリ(読み取りのみ)。データのロードや自前のデータ作成はできない |
| コスト負担 | リーダーアカウントで消費されるコンピュート費用もプロバイダが負担する(使いすぎを防ぐためリソースモニターの設定が推奨される) |
取引先にデータを提供したいがお互いにファイル連携は避けたい、というときに、相手にSnowflake契約を求めることなく共有の仕組みに乗せられるのがリーダーアカウントの価値です。
ダイレクトシェアが直接使えるのは、プロバイダとコンシューマが同一リージョン・同一クラウドにいる場合です。リージョンやクラウドプロバイダが異なる相手と共有するには、次のいずれかを使います。
いずれの場合も内部的にはリージョン間のデータ複製が発生するため、「同一リージョンならコピーなし、クロスリージョンでは複製が必要になる」と整理しておきましょう。詳細は5-4(リスティング)と5-5(レプリケーション)で扱います。
✅ この節のまとめ
問1. Secure Data Sharingのコスト負担について、正しい説明はどれか(リーダーアカウントは使わない前提とする)。
正解:B
データの実体はプロバイダのストレージに置かれたままコピーされないため、コンシューマにストレージ課金は発生しません。一方、共有データをクエリする仮想ウェアハウスはコンシューマ自身のものを使うため、コンピュート費用はコンシューマ負担です。Aはストレージ費用が発生する点が誤りです。Cはリーダーアカウントを使う場合の説明であり、通常の共有では当てはまりません。Dはデータがコピーされるという前提自体が誤りです。
問2. コンシューマがシェアから作成したデータベースに対してできる操作はどれか。
正解:A
シェアから作成したデータベースは読み取り専用であり、SELECTによる参照が基本的な(そして唯一の)データ操作です。BのINSERTを含む書き込み系の操作はできません。Cの再共有は禁止されており、共有を受けたデータを第三者へ渡すことはできません。DのTime Travelも共有データベースでは使えません。
問3. 外部アカウントへの共有でセキュアビューの利用が推奨される理由として適切なものを2つ選べ。
正解:AとC
セキュアビューは定義を権限のないユーザーから隠し(A)、通常のビューで起こり得るオプティマイザの挙動を悪用したデータ推測を防ぎながら、必要な行・列だけを公開できます(C)。Bは逆で、セキュアビューは一部の最適化が無効になるため通常のビューよりむしろ遅くなる可能性があります。Dのコスト負担は共有方法にかかわらず変わらず、セキュアビューとは無関係です。
問4. Snowflakeアカウントを持たない取引先にデータを共有したい。適切な方法はどれか。
正解:B
リーダーアカウントは、Snowflakeアカウントを持たない相手向けにプロバイダが作成・管理するアカウントで、共有データのクエリだけができます。Snowflake契約のない相手のため、消費されるコンピュート費用もプロバイダが負担します。AはSecure Data Sharingの利点(コピーレス・常に最新)を放棄する方法です。Cは認証情報の共有というセキュリティ上の重大な問題があります。Dは費用負担の説明が誤りで、リーダーアカウントの費用はプロバイダに課金されます。