Snowflake Data Clean Rooms におけるクロスクラウドの自動複製の管理¶
クロスクラウド自動複製について¶
デフォルトのclean room環境では、clean roomは同じクラウドリージョン内のアカウントとしか共有できません。つまり、プロバイダーとコンシューマーは同じクラウドリージョンにいなければなりません。
自分のアカウントと異なるリージョンのアカウントを持つコラボレーターと共同作業を行う場合は、このページで説明する方法に従って、自分のclean room環境およびclean roomの クロスクラウド自動複製 を有効にする必要があります。
自分のクラウドリージョンを定義するには、 SELECT CURRENT_REGION();
を実行します
注釈
クロスクラウド自動複製は*LAF*と呼ばれることがあります。これは、listings auto-fulfillment(リストの自動フルフィルメント) の略です。
クロスクラウド自動複製を有効にする¶
API または UIのいずれかを使用して、クロスクラウド自動複製を有効にすることができます。ただし、クロスリージョンコラボレーションの制限 に注意してください。
前提条件¶
アカウントのクロスクラウド自動フルフィルメントを有効にするには、まず組織管理者が SYSTEM$ENABLE_GLOBAL_DATA_SHARING_FOR_ACCOUNT を呼び出して、アカウント上でそれを有効にする必要があります。これはプロバイダーとコンシューマーの両方のためです。
詳細は 自動フルフィルメント および 自動フルフィルメント権限の管理 をご参照ください。
UI でクロスクラウド自動フルフィルメントを有効にする¶
クリーンルーム管理者は、以下のステップに従って、新規および既存のすべてのクリーンルームに対して、アカウントレベルでのクロスクラウド自動フルフィルメントを有効にします。
管理者アカウントで クリーンルームにサインインします UI。
Admin > Snowflake Admin を閲覧します。
Cross-Cloud Auto-Fulfillment を切り替えます。
:emph:`UI でクリーンルームを作成または結合する ` 場合、プロバイダーまたはコンシューマーは追加の手順を必要としません。ただし、後から :emph:`API でクリーンルームを作成または結合する ` 場合は、プロバイダーおよびコンシューマー向けの API 指示に従う必要があります。
API でクロスクラウド自動フルフィルメントを有効にする¶
すでに UI でクロスクラウド自動フルフィルメントを有効にしている場合でも、API でクリーンルームを作成またはインストールするには、こちらの手順に従ってください。
アカウント管理者¶
API を使用してアカウントのクロスクラウド自動フルフィルメントを有効にするには、プロバイダーアカウントとコンシューマーアカウントの両方の管理者が、ACCOUNTADMIN ロールを使用して次のコード例を実行する必要があります。これをアカウントごとに1回だけ実行する必要があります。
USE ROLE ACCOUNTADMIN;
-- Optionally check first to see if cross-cloud is enabled on the account.
CALL samooha_by_snowflake_local_db.library.is_laf_enabled_on_account();
-- If not, enable it.
CALL samooha_by_snowflake_local_db.library.enable_laf_on_account();
プロバイダーとコンシューマー¶
アカウントでクロスクラウド自動フルフィルメントを有効にした後、クリーンルームの作成またはインストール時にクロスクラウド自動フルフィルメントを有効にする方法は次のとおりです。
**プロバイダー**は
provider.create_or_update_cleanroom_listing
を呼び出すことで、通常の方法でクリーンルームを公開します。**コンシューマー**は
consumer.install_cleanroom
を呼び出すことで、クリーンルームをインストールします。コンシューマーがプロバイダーとは異なるクラウドリージョンにある場合、consumer.install_cleanroom
は失敗し、クロスクラウド自動フルフィルメントの複製がインストール中であるというメッセージが表示されます。**コンシューマー**は成功が返されるまで、
consumer.install_cleanroom
を呼び出し続けます。インストールには数分かかります。
この時点で、コンシューマーは基本的なクリーンルームの機能を備えています。コンシューマーがクライアントテンプレートリクエスト、プロバイダーが実行する分析、およびプロバイダーのアクティベーションに対するサポートを希望する場合は、以下の追加ステップに従ってください。
**プロバイダー**は
provider.mount_request_logs_for_all_consumers
を呼び出し、コンシューマーからプロバイダーへの通信を可能にします。
完全な設定コード例:
プロバイダー: プロバイダーは、標準的な方法でclean roomを作成、共有、公開します。
USE WAREHOUSE APP_WH; USE ROLE SAMOOHA_APP_ROLE; SET cleanroom_name = 'LAF example'; SET consumer_locator = '<CONSUMER_LOCATOR>'; SET consumer_account_name = '<CONSUMER_DATA_SHARING_ACCOUNT_ID>'; CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.provider.cleanroom_init($cleanroom_name); CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.provider.set_default_release_directive( $cleanroom_name, 'V1_0', '0'); CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.provider.add_consumers( $cleanroom_name, $consumer_locator, $consumer_account_name); CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.provider.create_or_update_cleanroom_listing($cleanroom_name);
**コンシューマー:**コンシューマーはクリーンルームをインストールします。
USE WAREHOUSE APP_WH; USE ROLE samooha_app_role; SET cleanroom_name = 'LAF example'; SET provider_locator = '<PROVIDER_LOCATOR>'; -- Initial call starts the process and returns a cross-cloud/region replication failure. -- Continue to call this procedure until it returns a success message. CALL SAMOOHA_BY_SNOWFLAKE_LOCAL_DB.consumer.install_cleanroom( $cleanroom_name, $provider_locator); -- Continue with standard clean room configuration and use. -- Consumer can run analyses, but requests to submit a template aren't -- supported until the provider calls ``provider.mount_request_logs_for_all_consumers``. ...
**プロバイダー:**コンシューマーがクリーンルームをインストールした後、プロバイダーとコンシューマー間のリクエストベースのアクションを有効にする場合、プロバイダーはリクエスト共有をマウントする必要があります。リクエストベースのアクションには、分析実行のプロバイダーリクエストと、クリーンルームにテンプレートを追加するコンシューマーリクエストが含まれます。
-- Call mount_request_logs_for_all_consumers until it reports success. provider.mount_request_logs_for_all_consumers($cleanroom_name);
プロバイダー/コンシューマー機能がすべて利用可能になりました。
クロスリージョンアカウントのリフレッシュ頻度¶
異なるクラウドリージョン上にある場合のプロバイダーとコンシューマー間のリクエストおよびデータは、複製頻度設定の対象となります。
プロバイダーからコンシューマーへのリクエストおよびデータ
プロバイダーからコンシューマーへのすべてのデータとリクエストは、アカウントのリフレッシュレート(デフォルトでは24時間ごと)でリフレッシュされます。これには、クリーンルームの作成または更新、プロバイダーデータの変更、許可のリクエスト(プロバイダーが実行する分析など)、リクエストの承認(コンシューマーテンプレートなど)が含まれます。
プロバイダーからコンシューマーへのリクエスト頻度は、アカウントの複製リフレッシュスケジュール によって制御されます。
コンシューマーからプロバイダーへのリクエストおよびデータ
次のテーブルは、コンシューマーからプロバイダーへのデータとリクエストのリフレッシュ頻度を示しています。
データ |
リフレッシュレート |
---|---|
次のようなリクエスト、承認、および変更。
|
|
プロバイダーのアクティベーションデータ。 |
|
以下のようなプロバイダークリーンルームデータ。
|
|
コンシューマーからプロバイダーへのリクエストとデータの リフレッシュ頻度を変更する ことができます。
クロスリージョンコラボレーションに関連するコスト¶
コラボレーターが別のリージョンにいる場合、追加費用が発生します。これらのコストがどのように発生するかについて詳しくは、 自動フルフィルメントコスト をご覧ください。
クロスリージョンコラボレーションの制限¶
クロスリージョンのコラボレーションには、以下のような制約があります:
クリーンルーム UI を使用する場合、コラボレーターは 同じ UI ホスティングリージョン を共有する必要があります。たとえば、1つのアカウントの UI ホストリージョンが「Amazon Web Services:US 東部(バージニア北部)、および別のアカウントの UI ホストリージョンが「Amazon Web Services: アジア太平洋地域(ムンバイ)」である場合、これらのアカウントは UI でコラボレーションできません。ただし、このページに記載されているように、アカウントとクリーンルームの両方がクロスクラウド自動フルフィルメントに設定されている場合は、:emph:``API を使用すればコラボレーションが可能です。
プロバイダーは、クリーンルーム内で差分プライバシーを使用することはできません。
クリーンルーム内では、外部テーブルとIcebergテーブルをリンクすることはできません。
コンシューマーが複数プロバイダーの分析を実行することはできません。
コラボレーターが、マスキングポリシーや行アクセスポリシーを使用することはできません。