Snowflake Data Clean Rooms：マルチプロバイダークリーンルーム

このトピックでは、複数のプロバイダーのクリーンルームのクラスタリングを横断して分析を実行する例を示します。各クリーンルームのセキュリティ保証を維持しながら、クエリがどのようにクリーンルーム間のデータにアクセスできるかを示しています。また、マルチプロバイダーのクリーンルームで一般的なユースケースである、分析の実行に使用するテンプレートをコンシューマーが定義する方法も示しています。

マルチプロバイダー分析では、各クリーンルームのデータが完全に安全な方法で使用されます。Snowflake Data Clean Rooms は、各クリーンルームのセキュリティポリシーの遵守を保証すると同時に、データに対して実行されるすべてのSQLが、各クリーンルームの参加者が期待するものであるよう徹底します。

多くの場合、マルチプロバイダー分析を実行するコンシューマーは、プロバイダーによって定義されたテンプレートを使用するのではなく、分析用のテンプレートを定義できるようにしたいと考えています。これによりコンシューマーは、複数の関係者からのデータを分析する際に、どのように洞察を得るかをコントロールすることができます。コンシューマー定義のテンプレートについての詳細は、[開発者 API を使用してコンシューマー定義のテンプレートを追加する]（../developer-consumer-templates.rst）をご参照ください。

注釈

マルチプロバイダークリーンルーム分析は、リージョン間で共有されているクリーンルームでは許可されません。

マルチプロバイダー分析例には、以下のステップが含まれます。

  1. プロバイダー：

    a.クリーンルームを2つ作り、2つの異なるプロバイダーをシミュレートします。

    b.同じコンシューマーとクリーンルームを共有します。

  2. コンシューマー：

    a.両方のプロバイダークリーンルームをインストールします。

    b.クリーンルームにコンシューマー定義のテンプレートを追加するリクエストを送信します。

  3. プロバイダー：

    a.コンシューマー定義のテンプレートの追加に関するコンシューマーのリクエストを承認します。

    b.コンシューマー定義のテンプレートの列ポリシーを設定します。

  4. コンシューマー：

    a.マルチプロバイダーの分析リクエストを提出します。

  5. プロバイダー：

    a.マルチプロバイダー分析用のクリーンルームを有効にします。

    b.コンシューマーからの複数プロバイダー分析リクエストを承認します。

  6. コンシューマー

    a.クリーンルームクラスター全体で分析を実行します。

前提条件

この例を完了するには、2つの別々のSnowflakeアカウントが必要です。プロバイダーのコマンドを実行するために最初のアカウントを使用し、コンシューマーのコマンドを実行するために2番目のアカウントに切り替えます。

プロバイダー：クリーンルームを作成および共有する

プロバイダーアカウントのSnowflakeワークシートを使用して、このセクションのコマンドを実行します。

環境の設定

開発者APIsを使用する前に、SAMOOHA_APP_ROLEロールを引き受け、APIsの実行に使用するウェアハウスを指定する必要があります。SAMOOHA_APP_ROLEロールを持ってない場合は、アカウント管理者にお問い合わせください。

以下のコマンドを実行して環境を設定します。

USE ROLE samooha_app_role;
USE WAREHOUSE app_wh;
Copy

クリーンルームの作成

クリーンルームの名称を作成します。既存のクリーンルーム名との衝突を避けるため、新しいクリーンルーム名を入力してください。クリーンルームの名前に使用できるのは 英数字 のみです。クリーンルーム名には、スペースとアンダースコア以外の特殊文字は使用できません。

まず、以下のコマンドを実行し、各クリーンルームのクリーン・ルーム名を設定します。

SET cleanroom_name_1 = 'Samooha Cleanroom Multiprovider Clean Room 1';
SET cleanroom_name_2 = 'Samooha Cleanroom Multiprovider Clean Room 2';
Copy

上記で設定したクリーンルーム名が既にデフォルトのクリーンルームとして存在する場合、この処理は失敗します。

この手順の実行には約45秒かかります。

provider.cleanroom_init の2番目の引数は、クリーンルームのディストリビューションです。これはINTERNALまたはEXTERNALのいずれかです。テスト目的で、同じ組織内のアカウントにクリーンルームを共有する場合、INTERNALを使用して、アプリケーションパッケージがコラボレーターにリリースされる前に実施されなければならない自動セキュリティスキャンをバイパスすることができます。ただし、このクリーンルームを別の組織のアカウントと共有する場合は、EXTERNALクリーンルーム配布を使用する必要があります。

CALL samooha_by_snowflake_local_db.provider.cleanroom_init($cleanroom_name_1, 'INTERNAL');
CALL samooha_by_snowflake_local_db.provider.cleanroom_init($cleanroom_name_2, 'INTERNAL');
Copy

セキュリティスキャンの状態を表示するには、以下のコマンドを実行します。

CALL samooha_by_snowflake_local_db.provider.view_cleanroom_scan_status($cleanroom_name_1);
CALL samooha_by_snowflake_local_db.provider.view_cleanroom_scan_status($cleanroom_name_2);
Copy

クリーンルームを作成したら、コラボレーターと共有する前にリリースディレクティブを設定する必要があります。ただし、ディストリビューションがEXTERNALに設定されている場合は、リリースディレクティブを設定する前に、セキュリティスキャンが完了するのを待つ必要があります。スキャンの実行中に残りのステップを実行し続け、 provider.create_cleanroom_listing ステップの前にここに戻ることができます。

リリースディレクティブを設定するには、次のようにします。

CALL samooha_by_snowflake_local_db.provider.set_default_release_directive($cleanroom_name_1, 'V1_0', '0');
CALL samooha_by_snowflake_local_db.provider.set_default_release_directive($cleanroom_name_2, 'V1_0', '0');
Copy

データセットの結合ポリシーを設定する

結合ポリシーとして使用する列を決定するには、データセットを見てPII列を決定します。例えば、あるテーブルの上から10行を見るには、以下のクエリを実行します。

SELECT * FROM SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS LIMIT 10;
Copy

次に、クリーンルーム内でテンプレートを実行する際に、コンシューマーが結合できる列を指定します。emailなどのID列に対して以下のコマンドを実行します。結合ポリシーを2回目に設定すると、前に設定した参加ポリシーは新しいものに完全に置き換えられます。

CALL samooha_by_snowflake_local_db.provider.set_join_policy($cleanroom_name_1, ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:HASHED_EMAIL']);
CALL samooha_by_snowflake_local_db.provider.set_join_policy($cleanroom_name_2, ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:HASHED_EMAIL']);
Copy

クリーンルームに追加された結合ポリシーを表示したい場合は、次のコマンドを実行します。

CALL samooha_by_snowflake_local_db.provider.view_join_policy($cleanroom_name_1);
CALL samooha_by_snowflake_local_db.provider.view_join_policy($cleanroom_name_2);
Copy

コンシューマーと共有する

最後に、Snowflakeアカウントロケーターとアカウント名を追加して、各クリーンルームにコンシューマーを追加します。Snowflakeアカウント名は<ORGANIZATION>.<ACCOUNT_NAME>の形式である必要があります。

複数のコンシューマーアカウントをカンマ区切りの文字列として provider.add_consumers 関数に渡すことも、 provider.add_consumers を複数回実行することもできます。

注釈

以下のコマンドを実行する前に、 provider.set_default_release_directive を使用してリリースディレクティブを設定していることを確認してください。次を使用した最新のバージョンとパッチが表示されます。

show versions in application package samooha_cleanroom_<ID>;
Copy

クリーンルームをコンシューマーと共有するには、以下のコマンドを実行します。

CALL samooha_by_snowflake_local_db.provider.add_consumers($cleanroom_name_1, '<CONSUMER_ACCOUNT_LOCATOR>', '<CONSUMER_ACCOUNT_NAME>');
CALL samooha_By_snowflake_local_db.provider.create_cleanroom_listing($cleanroom_name_1, '<CONSUMER_ACCOUNT_NAME>');

CALL samooha_by_snowflake_local_db.provider.add_consumers($cleanroom_name_2, '<CONSUMER_ACCOUNT_LOCATOR>', '<CONSUMER_ACCOUNT_NAME>');
CALL samooha_By_snowflake_local_db.provider.create_cleanroom_listing($cleanroom_name_2, '<CONSUMER_ACCOUNT_NAME>');
Copy

クリーンルームに追加されたコンシューマーを表示したい場合は、以下のコマンドを実行します。

CALL samooha_by_snowflake_local_db.provider.view_consumers($cleanroom_name_1);
CALL samooha_by_snowflake_local_db.provider.view_consumers($cleanroom_name_2);
Copy

以下のコマンドを実行すると、最近作成されたクリーンルームを表示できます。

CALL samooha_by_snowflake_local_db.provider.view_cleanrooms();
Copy

以下のコマンドを実行することで、最近作成されたクリーンルームに関する詳細情報を得ることができます。

CALL samooha_by_snowflake_local_db.provider.describe_cleanroom($cleanroom_name_1);
CALL samooha_by_snowflake_local_db.provider.describe_cleanroom($cleanroom_name_2);
Copy

作成されたクリーンルームは削除することもできます。次のコマンドはクリーンルームを完全に削除するため、以前クリーンルームにアクセスできたコンシューマーはもうクリーンルームを使用することができなくなります。

CALL samooha_by_snowflake_local_db.provider.drop_cleanroom($cleanroom_name_1);
CALL samooha_by_snowflake_local_db.provider.drop_cleanroom($cleanroom_name_2);
Copy

プロバイダーフローの最初の部分はこれで終了です。コンシューマーアカウントに切り替えて、クリーンルームを設置するコンシューマーフローを続行します。

クリーンルームでマルチプロバイダーコンピューティングを有効にするには、プロバイダー側に切り替える必要があります。

コンシューマー: クリーンルームのインストール

コンシューマーアカウントのSnowflakeワークシートを使用して、このセクションのコマンドを実行します。

コンシューマーとしては、複数のクリーンルームを共有することができます。マルチプロバイダー分析を実行する前に、それぞれのプロバイダーをアカウントにインストールし、分析に使用するデータセットをリンクする必要があります。

環境の設定

開発者APIsを使用する前に、SAMOOHA_APP_ROLEロールを引き受け、APIsの実行に使用するウェアハウスを指定する必要があります。SAMOOHA_APP_ROLEロールを持ってない場合は、アカウント管理者にお問い合わせください。

以下のコマンドを実行して環境を設定します。

USE ROLE samooha_app_role;
USE WAREHOUSE app_wh;
Copy

クリーンルームのインストール

クリーンルームをインストールする前に、プロバイダーが共有した各クリーンルームの名前を割り当てます。

set cleanroom_name_1 = 'Samooha Cleanroom Multiprovider Clean Room 1';
set cleanroom_name_2 = 'Samooha Cleanroom Multiprovider Clean Room 2';
Copy

以下のコマンドは、コンシューマーアカウントにクリーンルームをインストールします。

CALL samooha_by_snowflake_local_db.consumer.install_cleanroom($cleanroom_name_1, '<PROVIDER_ACCOUNT_LOCATOR>');

CALL samooha_by_snowflake_local_db.consumer.install_cleanroom($cleanroom_name_2, '<PROVIDER_ACCOUNT_LOCATOR>');
Copy

クリーンルームが設置された後、プロバイダーはクリーンルームの使用を可能にする前に、プロバイダー側でクリーンルームの設定を完了する必要があります。以下の関数でクリーンルームのステータスを確認できます。有効化されると、以下のRun Analysisコマンドを実行できるようになります。クリーンルームが有効になるまで、通常約1分かかります。

CALL samooha_by_snowflake_local_db.consumer.is_enabled($cleanroom_name_1);
CALL samooha_by_snowflake_local_db.consumer.is_enabled($cleanroom_name_2);
Copy

クリーンルーム共有がインストールされると、利用可能なクリーンルームのリストは、以下のコマンドを使用して表示することができます。

CALL samooha_by_snowflake_local_db.consumer.view_cleanrooms();
Copy

データセットのリンク

データセットをクリーンルームにリンクし、プロバイダーのデータでセキュアな計算を実行します。

CALL samooha_by_snowflake_local_db.consumer.link_datasets($cleanroom_name_1, ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS']);

CALL samooha_by_snowflake_local_db.consumer.link_datasets($cleanroom_name_2, ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS']);
Copy

注釈

テーブルが存在するにもかかわらず、この手順がうまくいかない場合は、テーブルを含むデータベースが登録されていない可能性があります。データベースを登録するには、ACCOUNTADMINロールを持つユーザーとして以下のコマンドを実行します。

USE ROLE accountadmin;
CALL samooha_by_snowflake_local_db.provider.register_db('<DATABASE_NAME>');
USE ROLE samooha_app_role;
Copy

クリーンルームに追加したデータセットを表示したい場合は、以下のプロシージャを呼び出します。

CALL samooha_by_snowflake_local_db.consumer.view_consumer_datasets($cleanroom_name_1);
CALL samooha_by_snowflake_local_db.consumer.view_consumer_datasets($cleanroom_name_2);
Copy

コンシューマー: クリーンルームにコンシューマー定義のテンプレートを追加するリクエストを送信する

マルチプロバイダー分析を実行するコンシューマーは、複数の関係者からのデータから価値を引き出す方法を知っている最良の立場にあることがよくあります。コンシューマーは、クリーンルームプロバイダーに対して、コンシューマー定義のテンプレートをクリーンルームに含めるようにリクエストを送信することができ、コンシューマーはそれを使って分析を実行することができます。クリーンルームへのコンシューマー定義のテンプレートの追加についての詳細は、[コンシューマー定義のテンプレートの追加]（../developer-consumer-templates.rst）をご参照ください。

注釈

マルチプロバイダーのクリーンルームでの分析は、現在のクリーンルームからだけでなく、他のクリーンルームからのすべてのテーブルをテンプレートの source_tables 引数にレンダリングすることによって動作します。しかし、セキュリティ検証やリクエスト承認時には、各クリーンルームは関連するテーブルのみを受け取ります。そのため、テンプレートは、 source_table の引数の特定の数を想定することなく、汎用的に記述されるべきです。これにより、1つまたは複数の source_table 入力にまたがって拡張することができます。Jinjaのfor-loopを使って実装できます。

この例では、コンシューマーは以下のリクエストを送信します。各リクエストには、テンプレートを定義するJinjaコードが含まれています。

CALL samooha_by_snowflake_local_db.consumer.create_template_request($cleanroom_name_1, 'multiprovider_overlap_analysis', $$
WITH union_data AS (
    select identifier({{ hem_col[0] | join_policy }}) as join_col, identifier({{ dimensions[0] | column_policy }}) as group_col 
    {% for dim in dimensions[1:] %}
        , identifier({{ dim }}) as group_col_{{ loop.index }}
    {% endfor %}
    from identifier({{ source_table[0] }}) p1
    {% for src in source_table[1:] %}
        inner join (
        select identifier({{ hem_col[loop.index] | join_policy }}), identifier({{ dimensions[loop.index] | column_policy  }})  from identifier({{ src }}) p{{ loop.index + 1}} )  p{{ loop.index + 1}} 
        on identifier({{ hem_col[0] }}) = identifier({{ hem_col[loop.index] }})
    {% endfor %}
)
select count(distinct join_col), group_col
{% for dim in dimensions[1:] %}
        , group_col_{{ loop.index }}
{% endfor %}
from union_data u
inner join identifier({{ my_table[0] }}) c
on u.join_col = c.{{ consumer_join_col | sqlsafe }}
group by group_col
{% for dim in dimensions[1:] %}
        , group_col_{{ loop.index }}
{% endfor %}
$$);

CALL samooha_by_snowflake_local_db.consumer.create_template_request($cleanroom_name_2, 'multiprovider_overlap_analysis', $$
WITH union_data AS (
    select identifier({{ hem_col[0] | join_policy }}) as join_col, identifier({{ dimensions[0] | column_policy }}) as group_col 
    {% for dim in dimensions[1:] %}
        , identifier({{ dim }}) as group_col_{{ loop.index }}
    {% endfor %}
    from identifier({{ source_table[0] }}) p1
    {% for src in source_table[1:] %}
        inner join (
        select identifier({{ hem_col[loop.index] | join_policy }}), identifier({{ dimensions[loop.index] | column_policy  }})  from identifier({{ src }}) p{{ loop.index + 1}} )  p{{ loop.index + 1}} 
        on identifier({{ hem_col[0] }}) = identifier({{ hem_col[loop.index] }})
    {% endfor %}
)
select count(distinct join_col), group_col
{% for dim in dimensions[1:] %}
        , group_col_{{ loop.index }}
{% endfor %}
from union_data u
inner join identifier({{ my_table[0] }}) c
on u.join_col = c.{{ consumer_join_col | sqlsafe }}
group by group_col
{% for dim in dimensions[1:] %}
        , group_col_{{ loop.index }}
{% endfor %}
$$);
Copy

プロバイダー: コンシューマーのテンプレート追加リクエストを承認する

プロバイダーは、クリーンルームにコンシューマー定義のテンプレートを含めるというコンシューマーのリクエストを承認しなければなりません。

プロバイダーは、 provider.list_template_requests コマンドを使用して、新しいリクエストの UUID の取得を含む、リクエストの一覧を表示します。次にプロバイダーは、 provider.approve_template_request コマンドを実行してリクエストを承認します。このプロセスの詳細については、[コンシューマー定義のテンプレートの追加]（../developer-consumer-templates.rst）をご参照ください。

CALL samooha_snowflake_local_db.provider.list_template_requests($cleanroom_name_1);
CALL samooha_by_snowflake_local_db.provider.approve_template_request($cleanroom_name_1, <REQUEST_UUID>);


CALL samooha_snowflake_local_db.provider.list_template_requests($cleanroom_name_2);
CALL samooha_by_snowflake_local_db.provider.approve_template_request($cleanroom_name_2, <REQUEST_UUID>);
Copy

各テーブルに列ポリシーを設定する

テーブルとテンプレートの組み合わせごとに、コンシューマーが分析で使用できる列、例えばグループ化や集計が可能な列を設定します。これにより、同じテーブルでも基本テンプレートによって異なる列選択ができる柔軟性が生まれます。テーブルに列ポリシーを設定するのは、テンプレートを追加してからにする必要があります。

列ポリシーは 置換のみ であることに注意してください。したがって、この関数が再度呼び出された場合、以前に設定された列ポリシーは新しいものに完全に置き換えられます。

列ポリシーは、メールアドレス、 HEM、 RampID のようなID列では使用しないでください。これは、コンシューマーがこれらの列でグループ化できないようにするためです。実稼働環境では、SnowflakeはPII列を推測し、この操作をブロックしますが、サンドボックス環境でこの推測は利用できません。Status、Age Band、Region Code、Days Activeなどのように、コンシューマーに集計やグループ化させる列にのみ使用してください。

"column_policy"と"join_policy"がコンシューマー分析リクエストのチェックを実行するために、SQL Jinjaテンプレートでは、すべての列名MUSTが dimensions または measure_columns として参照されます。カスタムSQL Jinjaテンプレートでチェックする列を参照するには、必ずこれらのタグを使用してください。

テンプレートとテーブルの組み合わせに対して列ポリシーを設定するには、以下のコマンドを実行します。

CALL samooha_by_snowflake_local_db.provider.set_column_policy($cleanroom_name_1, [ 'multiprovider_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:STATUS']);

CALL samooha_by_snowflake_local_db.provider.set_column_policy($cleanroom_name_2, [
'multiprovider_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:REGION_CODE']);
Copy

コンシューマー: マルチプロバイダークリーンルーム分析リクエストを提出する

次のステップは、インストールしたクリーンルーム一式にマルチプロバイダー分析をリクエストすることです。この一連のクリーンルームをクリーンルームクラスタリングと呼びます。このプロセスでは、各プロバイダーに対して、このマルチプロバイダー分析が承認され、実行されるかどうかを尋ねるリクエストを書き込みます。これらのリクエストはプロバイダーによって、自動または手動のフローを使用して非同期に処理されます。自動承認フローを利用すれば、リクエスト処理は2分程度で完了し、各クリーンルームで承認（クリーンルームのセキュリティポリシーに適合しているかチェックした後）されれば、フローを実行することができます。

マルチプロバイダークリーンルームリクエストフローでは、プロバイダーテーブルを source_table 配列引数で指定する必要があります。各テーブルは、それが存在するクリーンルーム名で始まる必要があります。全体的なフォームは<CLEANROOM_NAME>.<DB>.<SCHEMA>.<TABLE>となります。コンシューマーテーブルは、 my_table 配列引数で提供することができます。

CALL samooha_by_snowflake_local_db.consumer.prepare_multiprovider_flow(
    [$cleanroom_name_1, $cleanroom_name_2],
    'prod_aggregate_data',
    object_construct(
        'source_table', [
            concat($cleanroom_name_1, '.SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS'), 
            concat($cleanroom_name_2, '.SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS')
        ],
        'my_table', ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS']),
        'hem_col', ['p1.HASHED_EMAIL', 'p2.HASHED_EMAIL'],
        'dimensions', ['p1.STATUS', 'p2.STATUS'],
        'consumer_join_col', 'HASHED_EMAIL'
    )
);
Copy

このAPIは、各クリーンルームのプロバイダーにマルチプロバイダー分析リクエストを提出する前に、まず各クリーンルームのセキュリティポリシーでリクエストを検証します。これらのチェックに失敗した場合、このAPIは発生したエラーメッセージを返します。

prepare_multiprovider_flowに対する入力の決定方法

分析を実行するには、run_analysis関数にいくつかのパラメータを渡す必要があります。このセクションでは、どのようなパラメータを渡すかを決定する方法を説明します。

テンプレート名

まず、以下のコマンドを実行することで、サポートされている分析テンプレートを確認することができます。

CALL samooha_by_snowflake_local_db.consumer.view_added_templates($cleanroom_name);
Copy

テンプレートを使って分析を実行する前に、どのような引数を指定し、どのような型が期待されるかを知っておく必要があります。カスタムテンプレートの場合は、以下のコマンドを実行します。

CALL samooha_by_snowflake_local_db.consumer.view_template_definition($cleanroom_name, 'prod_custom_template');
Copy

これは、SQL Jinjaのさまざまなパラメータを大量に返します。SQL Jinjaテンプレートを解析し、run_analysisで指定する必要がある引数をリストに抽出するには、以下のコマンドを実行します。

CALL samooha_by_snowflake_local_db.consumer.get_arguments_from_template($cleanroom_name, 'prod_custom_template');
Copy

データセット名

プロバイダーによってクリーンルームに追加されたデータセット名を表示したい場合は、次のコマンドを実行します。プロバイダーによってクリーンルームに追加されたデータセットのデータを表示することはできません。

CALL samooha_by_snowflake_local_db.consumer.view_provider_datasets($cleanroom_name);
Copy

以下のコマンドを実行すれば、クリーンルームにリンクしたテーブルを確認することもできます。

CALL samooha_by_snowflake_local_db.consumer.view_consumer_datasets($cleanroom_name);
Copy

列のディメンションと測定。

分析を実行する際、特定の列でフィルタリング、グループ化、集計を行いたい場合があります。プロバイダーによってクリーンルームに追加された列ポリシーを表示したい場合は、次のコマンドを実行します。

CALL samooha_by_snowflake_local_db.consumer.view_provider_column_policy($cleanroom_name);
Copy

よくあるエラー

実行分析の結果、 Not approved: unauthorized columns used というエラーが表示される場合は、プロバイダーが設定した結合ポリシーと列ポリシーを表示してみてください。

CALL samooha_by_snowflake_local_db.consumer.view_provider_join_policy($cleanroom_name);
CALL samooha_by_snowflake_local_db.consumer.view_provider_column_policy($cleanroom_name);
Copy

また、プライバシーの予算を使い果たしたため、これ以上クエリを実行できなくなる可能性もあります。残りのプライバシー予算は以下のコマンドで表示できます。予算は毎日リセットされますが、クリーンルームのプロバイダーが手動でリセットすることもできます。

CALL samooha_by_snowflake_local_db.consumer.view_remaining_privacy_budget($cleanroom_name);
Copy

差分プライバシーがクリーンルームで有効になっているかどうかは、次のAPIで確認できます。

CALL samooha_by_snowflake_local_db.consumer.is_dp_enabled($cleanroom_name);
Copy

プロバイダー：マルチプロバイダーの分析およびリクエストの承認を可能にします。

コンシューマーのマルチプロバイダー分析を有効にし、発生したリクエストを処理するために、プロバイダーアカウントに切り替えます。

マルチプロバイダー分析のためにクリーンルームを有効化する

この目的のためにクリーンルームを有効にするまで、コンシューマーはマルチプロバイダ分析を正常に実行できません。コンシューマーのクリーンルームを有効にする際、マルチプロバイダー分析に含めることができるクリーンルームも指定します。他のプロバイダーのクリーンルームを明示的に承認しない限り、コンシューマーがクリーンルームと他のプロバイダーのクリーンルームを含むマルチプロバイダー分析を実行することはできません。

コンシューマーが他のプロバイダーのクリーンルームを使用してマルチプロバイダー分析を実行できるようにするには、以下のコマンドを実行するときに空のリストを指定します。

注釈

これは、 すでに クリーンルームをインストールしているコンシューマーについてのみ呼び出すことができます。

CALL samooha_by_snowflake_local_db.provider.enable_multiprovider_computation($cleanroom_name_1, '<CONSUMER_ACCOUNT_LOCATOR>', [concat('<PROVIDER_ORG_NAME>.<PROVIDER_ACCOUNT_NAME>.', $cleanroom_name_2)]);

CALL samooha_by_snowflake_local_db.provider.enable_multiprovider_computation($cleanroom_name_2, '<CONSUMER_ACCOUNT_LOCATOR>', [concat('<PROVIDER_ORG_NAME>.<PROVIDER_ACCOUNT_NAME>.', $cleanroom_name_1)]);
Copy

マルチプロバイダーの分析リクエストの承認

マルチプロバイダー分析が各クリーンルームで有効になった後、クリーンルームに対して発生したすべてのマルチプロバイダー分析リクエストは、次のAPIを使用して表示することができます。

CALL samooha_by_snowflake_local_db.provider.view_multiprovider_requests($cleanroom_name_1, '<CONSUMER_ACCOUNT_LOCATOR>');

CALL samooha_by_snowflake_local_db.provider.view_multiprovider_requests($cleanroom_name_2, '<CONSUMER_ACCOUNT_LOCATOR>');
Copy

リクエストの承認には2つの方法があります。

  1. 受信するリクエストをリッスンし、必要なときにトリガーするタスクを自動的に使用する。

  2. 受信したマルチプロバイダーの分析リクエストを、ユーザーが明示的に手動で処理する。

デフォルトでは、承認は手動で行われ、タスクはenable_multiprovider_computation APIによって中断された状態で作成されます。このため、ユーザーは受信リクエストを手動で処理する必要があります。これは以下のコマンドを実行することで可能です。

CALL samooha_by_snowflake_local_db.provider.process_multiprovider_request($cleanroom_name_1, '<CONSUMER_ACCOUNT_LOCATOR>', '<REQUEST_ID>');

CALL samooha_by_snowflake_local_db.provider.process_multiprovider_request($cleanroom_name_2, '<CONSUMER_ACCOUNT_LOCATOR>', '<REQUEST_ID>');
Copy

注釈

このAPIは、view_multiprovider_requests APIの出力から特定のリクエストIDを指定することで、リクエストIDレベルで動作させることも、REQUEST_IDを '-1' として渡すことで、すべての受信リクエストを処理することもできます。

このプロセスは、入ってきたリクエストを 承認するのではなく、リクエストの年齢や、リクエストされた共同研究者がenable_multiprovider_computationで設定した承認済みコラボレーターリストに含まれているかどうかなどの要因に基づいて、承認できるかどうかを確認するための処理ロジックにリクエストを通します。

リクエストが処理されると、samooha_cleanroom_${ UUID}.admin.request_log_multiproviderテーブルに書き込まれます。以下のようなクエリで、リクエストのリストと承認されたかどうかを確認できます。

SELECT * FROM samooha_cleanroom_Samooha_Cleanroom_Multiprovider_Clean_Room_1.admin.request_log_multiprovider;
SELECT * FROM samooha_cleanroom_Samooha_Cleanroom_Multiprovider_Clean_Room_2.admin.request_log_multiprovider;
Copy

承認されていない以前のリクエストは、APPROVE=True に上書きすることもできますし、逆に、APPROVE=Falseに設定することで、以下のクエリを使ってアクセスを削除することもできます。<CONDITIONS> の詳細については、下記の セキュリティに関する考慮事項 セクションをご参照ください。

-- Override and approve a request that had previously been rejected
UPDATE samooha_cleanroom_Samooha_Cleanroom_Multiprovider_Clean_Room_1.admin.request_log_multiprovider set APPROVED=True where <CONDITIONS>;
UPDATE samooha_cleanroom_Samooha_Cleanroom_Multiprovider_Clean_Room_2.admin.request_log_multiprovider set APPROVED=True where <CONDITIONS>;

-- Revoke access to a query you had previously approved
UPDATE samooha_cleanroom_Samooha_Cleanroom_Multiprovider_Clean_Room_1.admin.request_log_multiprovider set APPROVED=False where <CONDITIONS>;
UPDATE samooha_cleanroom_Samooha_Cleanroom_Multiprovider_Clean_Room_2.admin.request_log_multiprovider set APPROVED=False where <CONDITIONS>;
Copy

手動承認よりも自動承認フローを優先する場合は、以下のコマンドを実行してマルチプロバイダーの分析タスクを再開する必要があります。

CALL samooha_by_snowflake_local_db.provider.resume_multiprovider_tasks($cleanroom_name_1, '<CONSUMER_ACCOUNT_LOCATOR>');

CALL samooha_by_snowflake_local_db.provider.resume_multiprovider_tasks($cleanroom_name_2, '<CONSUMER_ACCOUNT_LOCATOR>');
Copy

逆に、自動承認フローが現在実行されている場合は、以下のコマンドを実行することでオフにすることができます。

CALL samooha_by_snowflake_local_db.provider.suspend_multiprovider_tasks($cleanroom_name_1, '<CONSUMER_ACCOUNT_LOCATOR>');

CALL samooha_by_snowflake_local_db.provider.suspend_multiprovider_tasks($cleanroom_name_2, '<CONSUMER_ACCOUNT_LOCATOR>');
Copy

セキュリティに関する考慮事項：マルチプロバイダー分析リクエストの管理

マルチプロバイダー分析は、承認されたクエリのハッシュを行アクセスポリシーに追加することで機能します。行アクセスポリシーは通常、samooha_cleanroom_${UUID}.shared_schemaスキーマの下に作成され、行アクセスポリシーの定義は次のようになります。

CREATE OR REPLACE ROW ACCESS POLICY samooha_cleanroom_${UUID}.shared_schema.${firewall_name} AS (foo varchar) RETURNS BOOLEAN ->
    EXISTS  (SELECT request_id FROM samooha_cleanroom_${UUID}.admin.REQUEST_LOG_MULTIPROVIDER w
        WHERE party_account=current_account()
            AND approved=true
            AND sha2(current_statement()) = query_hash
        );
Copy

行アクセスポリシーは、アカウントのsamooha_cleanroom_${UUID}.admin.request_log_multiproviderテーブルで、クリーンルームの特定のコンシューマーの承認されたリクエストを見つけ、そのアカウントで現在実行されているクエリのハッシュが承認されたクエリと一致するかチェックすることで機能します。

マルチプロバイダーフローのデータへのすべてのセキュリティアクセスは、このテーブル (samooha_cleanroom_${UUID}.admin_request_log_multiprovider) に記載されている承認によってゲートされます。データへのアクセスを許可するクエリだけが実行できるように、積極的に管理する必要があります。

単純なクエリは、以前に処理されたリクエストの承認または非承認（つまり、承認を削除）に使用できます。たとえば、次のクエリを実行できます。

-- Override and approve a request that had previously been rejected
UPDATE samooha_cleanroom_Samooha_Cleanroom_Multiprovider_Clean_Room_1.admin.request_log_multiprovider SET APPROVED=True WHERE <CONDITIONS>;
UPDATE samooha_cleanroom_Samooha_Cleanroom_Multiprovider_Clean_Room_2.admin.request_log_multiprovider SET APPROVED=True WHERE <CONDITIONS>;

-- Revoke access to a query you had previously approved
UPDATE samooha_cleanroom_Samooha_Cleanroom_Multiprovider_Clean_Room_1.admin.request_log_multiprovider SET APPROVED=False WHERE <CONDITIONS>;
UPDATE samooha_cleanroom_Samooha_Cleanroom_Multiprovider_Clean_Room_2.admin.request_log_multiprovider SET APPROVED=False WHERE <CONDITIONS>;
Copy

行のアクセスポリシーに見られるように、query_hashに応じてデータへのアクセスが与えられます。しかし、query_hashは、クエリを実行するためにどのクリーンルームがランダムに選択されるかに依存することもあります。そのため、アクセスを取り消す/承認するリクエストを決定するために上記のクエリに渡される<CONDITIONS>、これらのベストプラクティスに従う必要があります。

  1. リクエストを手動で承認する場合、request_idおよび/またはcleanroom_names、requester_accountおよびtemplate_nameのどちらかでフィルタリングして、リクエストについてできるだけ具体的に記述するようにしてください。

  2. クエリに対する以前の承認を取り消す場合、 query_hash がマッチするすべてのリクエストを取り消します。 また 、 requester_account と template_name と cleanroom_names （以下の例をご参照ください）のすべてのリクエストも取り消します。

  3. 新しいリクエストが承認されなくても、以前のリクエストの承認が変更されることはありません。以前のクエリアクセスを取り消したい場合は、samooha_cleanroom_${UUID}.admin.request_log_multiproviderテーブルで、対応するリクエストにAPPROVED=Falseを付ける必要があります。

  4. enable_multiprovider_computationを再度実行して許可されるコラボレーターのセットを変更した場合、以前のリクエストはデフォルトでは取り消されません。samooha_cleanroom_${UUID}.admin.request_log_multiproviderテーブルのAPPROVED=Falseを設定することで、以前のコラボレーションへのアクセスを取り消し、承認を管理する必要があります。

特定のコラボレーションのリクエスト能力を完全に取り消す方法の例。requester_account=ABC123で実行されているコラボレーションがあり、それを取り消したいとします。次のクエリを実行できます。

UPDATE samooha_cleanroom_{UUID}.admin.request_log_multiprovider SET APPROVED=False WHERE requester_account = 'ABC123' AND query_hash = '<HASH>';
UPDATE samooha_cleanroom_{UUID}.admin.request_log_multiprovider SET APPROVED=False WHERE requester_account = 'ABC123' AND template_name = '<TEMPLATE_NAME>' AND request:CLEANROOM_NAMES = [$cleanroom_name1, $cleanroom_name2];
Copy

そのクリーンルームコラボレーションにおけるクエリハッシュとテンプレートの両方のアクセスが取り消されます。

以下は、リクエスターアカウントごとに、何件のクエリが発生したかを確認できるサンプルクエリです。

SELECT requester_account, count(*) FROM samooha_cleanroom_{UUID}.admin.request_log_multiprovider;

-- If there is a requester_account raising too many queries they can be disallowed in bulk
UPDATE samooha_cleanroom_{UUID}.admin.request_log_multiprovider SET APPROVED=False WHERE requester_account = '<ACCOUNT>';
Copy

コンシューマー - リクエストを実行する

prepare_multiprovider_flow API によって発生したリクエストが承認されると、クリーンルームクラスター全体で以下の API を使用して実行できます。この実行は、フローを実行するために1つのクリーンルームがランダムに選択されることによって行われ、両方のクリーンルームがリクエストを承認している限り、マルチプロバイダー分析は進行することが許可されます。

CALL samooha_by_snowflake_local_db.consumer.execute_multiprovider_flow([$cleanroom_name_1, $cleanroom_name_2]);
Copy

prepare_multiprovider_flow プロシージャの後にリクエストが承認されると、 prepare_multiprovider_flow を再度呼び出す必要はなく、 execute_multiprovider_flow を必要なだけ呼び出すことができることにも注意してください。しかし、別の分析を実行したり、別のクリーンルームクラスタリングで分析を実行するには、 prepare_multiprovider_flow を再度呼び出す必要があります。

便利な関数

各プロバイダーへの相互運用性リクエストが書き込まれると、その承認は、クリーンルームに追加され、分析中に実行されるリクエスト固有の顧客テンプレートという形で行われます。これらは必要なインフラストラクチャを設定します。以下のコマンドを実行することで、リクエストの承認プロセスによってリアルタイムで追加されるこれらのテンプレートを表示できます。

CALL samooha_by_snowflake_local_db.consumer.view_added_templates($cleanroom_name_1);
CALL samooha_by_snowflake_local_db.consumer.view_added_templates($cleanroom_name_2);
Copy
言語: 日本語