開発者 API を使用してコンシューマー定義のテンプレートを追加する

従来の Snowflake Data Clean Rooms のフローでは、プロバイダーは開発者 API を使ってカスタムテンプレートを作成し、プロバイダーがコンシューマーと共有するクリーンルームに追加します。コンシューマーはそのテンプレートを使ってクリーンルームで分析を実行します。

場合によっては、クリーンルームで実行可能な分析の種類を制御するために、コンシューマーは独自のカスタムテンプレートを作成できるようにしたいと考えています。このシナリオでは、プロバイダーはクリーンルームを作成し共有しますが、コンシューマーはそのクリーンルーム内でテンプレートを定義します。プロバイダーのクリーンルームであるため、プロバイダーはこのコンシューマー定義のテンプレートがクリーンルームに追加されることを明示的に許可しなければなりません。

プロバイダーのクリーンルームにコンシューマー定義のテンプレートを追加する機能は、コンシューマーが同時に複数のプロバイダーからのデータに対して分析を実行するマルチプロバイダーのクリーンルームで必要とされることがよくあります。このような環境では、コンシューマーは複数の関係者から送られてくるデータからインサイトを抽出する方法を知る最良の立場にあり、開発者 API を使用して、カスタムテンプレートを作成することができる。マルチプロバイダー環境におけるコンシューマー定義のテンプレートでは、テンプレートを使用する前に、各プロバイダーがテンプレートを承認する必要があります。マルチプロバイダークリーンルームの使用方法を示す拡張例については、 Snowflake Data Clean Rooms：マルチプロバイダークリーンルーム をご参照ください。

コンシューマー定義テンプレートの基本ワークフロー

開発者 API を使用して、プロバイダーのクリーンルームにコンシューマー定義のテンプレートを追加するプロセスには、コンシューマーとプロバイダーの両方による協調的なアクションが含まれます。この基本ワークフローは:

コンシューマー:

クリーンルームのプロバイダーにカスタムテンプレートの追加 リクエストを送信 します。このリクエストには、Jinjaテンプレート言語で書かれたテンプレートの定義が含まれています。

プロバイダー:

  1. クリーンルームにテンプレートを追加したいコンシューマーからの 新しいリクエストを確認 します。

  2. テンプレートの定義を確認した後、 リクエストの承認または拒否 を行います。

コンシューマー:

リクエストが承認されたかどうかを確認します。コンシューマーは、いつでも リクエストのステータスを確認 することができます。

プロバイダーにリクエストを送信する

コンシューマーは、 consumer.create_template_request コマンドを実行し、クリーンルームのプロバイダーにリクエストを送信すします。このリクエストにはテンプレートの名前とテンプレートを定義するJinjaコードが含まれます。

例えば、プロバイダーがコンシューマーとクリーンルーム dcr_cleanroom を共有したとします。コンシューマーは、 my_overlap_analysis というテンプレートをクリーンルームに追加したいと思っています。クリーンルームのプロバイダーにリクエストを送信するために、コンシューマーは以下のコマンドを実行します。

CALL samooha_by_snowflake_local_db.consumer.create_template_request('dcr_cleanroom',
  'my_analysis',
  $$
  SELECT
      identifier({{ dimensions[0] | column_policy }})
  FROM
      identifier({{ my_table[0] }}) c
    INNER JOIN
      identifier({{ source_table[0] }}) p
        ON
          c.identifier({{ consumer_id  }}) = identifier({{ provider_id | join_policy }})
       {% if where_clause %} where {{ where_clause | sqlsafe | join_and_column_policy }} {% endif %};
  $$);
Copy

第3引数はテンプレートを定義するJinjaコードです。

consumer.create_template_request コマンドの参照ドキュメントについては、 Snowflakeデータクリーンルーム：コンシューマーAPIリファレンスガイド のコンシューマー定義のテンプレートのセクションをご参照ください。

コンシューマーからの新しいリクエストを確認する

コンシューマーからの新しいリクエストを確認するために、プロバイダーは provider.list_template_requests コマンドを実行し、その結果を解析してステータスが PENDING のリクエストを特定します。PENDING ステータスは、コンシューマーがプロバイダーがアクションを起こしていない新しいリクエストを送信したことを示します。 provider.list_template_requests への応答にはテンプレートのJinjaコードが含まれ、プロバイダーはリクエストを承認するか拒否するかを決めることができます。

例えば、プロバイダーのクリーンルームの名前が dcr_cleanroom だとします。コンシューマーがテンプレートを追加する新しいリクエストを送信したかどうかを確認するために、プロバイダーは以下のコマンドを実行します。

CALL samooha_by_snowflake_local_db.provider.list_template_requests('dcr_cleanroom');

SELECT * FROM TABLE(RESULT_SCAN(LAST_QUERY_ID())) WHERE status = 'PENDING';
Copy

provider.list_template_requests コマンドの応答には、テンプレートリクエストごとに以下のものが含まれます。

  • リクエストを一意に識別する UUID

  • リクエストを送信したコンシューマーアカウント（アカウントロケーター形式）

  • コンシューマーがリクエスト送信時に指定したテンプレート名

  • テンプレートを定義するJinjaコード

  • PENDING、 APPROVED、 REJECTED のいずれかのリクエストのステータス

provider.list_template_requests コマンドの参照ドキュメントについては、 Snowflakeデータクリーンルーム：プロバイダーAPIリファレンスガイド のコンシューマー定義のテンプレートのセクションをご参照ください。

リクエストの承認または拒否

コンシューマー定義テンプレートの追加リクエストを受信した後、プロバイダーはその要求を承認するか拒否するかを決定します。

リクエストの承認

プロバイダーは、 provider.approve_template_request コマンドを実行し、テンプレートの追加リクエストを承認します。プロバイダーは、リクエスト識別子を引数として渡すことで、どのテンプレートを承認するかを指定します。

例えば、プロバイダーのクリーンルームの名前が dcr_cleanroom であり、コンシューマーのテンプレート追加リクエストには識別子 01b4d41d-0001-b572 が割り当てられていたとします。リクエストを承認し、クリーンルームにテンプレートを追加するために、プロバイダーは以下のコマンドを実行します。

CALL samooha_by_snowflake_local_db.provider.approve_template_request('dcr_cleanroom',
  '01b4d41d-0001-b572');
Copy

リクエストの拒否

プロバイダーは、 provider.reject_template_request コマンドを実行し、テンプレートの追加リクエストを拒否します。プロバイダーはリクエスト識別子を引数として渡すことで、拒否するテンプレートを指定します。

例えば、プロバイダーのクリーンルームの名前が dcr_cleanroom であり、コンシューマーのテンプレート追加リクエストには識別子 01b4d41d-0001-b572 が割り当てられていたとします。Jinjaテンプレートを調査した後、プロバイダーはクリーンルームにセキュリティリスクをもたらすと判断し、説明的な理由とともにリクエストを拒否します。テンプレートの追加リクエストを拒否するために、プロバイダーは以下のコマンドを実行します。

CALL samooha_by_snowflake_local_db.provider.reject_template_request('dcr_cleanroom',
  '01b4d41d-0001-b572',
  'Failed security assessment');
Copy

provider.approve_template_request と provider.reject_template_request コマンドの参考文書については、 Snowflakeデータクリーンルーム：プロバイダーAPIリファレンスガイド のコンシューマー定義のテンプレートのセクションをご参照ください。

コンシューマーとしてのリクエストのステータスの確認

コンシューマーはいつでも、 consumer.list_template_requests コマンドを実行して、テンプレート追加リクエストのステータスを確認することができます。このコマンドは、次の列を返します。

  • リクエストを一意に識別する UUID

  • リクエストが送信されたプロバイダーアカウント（アカウントロケーター形式）

  • コンシューマーがリクエスト送信時に指定したテンプレート名

  • テンプレートを定義するJinjaコード

  • PENDING、 APPROVED、 REJECTED のいずれかのリクエストのステータス

  • リクエストが拒否された場合、プロバイダーのアクションの理由

例えば、コンシューマーが dcr_cleanroom クリーンルームにテンプレートの追加リクエストを送信したとします。リクエストのステータスを確認し、それが承認されたかどうかを判断するために、コンシューマーは以下のコマンドを実行します。

CALL samooha_by_snowflake_local_db.consumer.list_template_requests('dcr_cleanroom');
Copy

consumer.list_template_requests コマンドの参照ドキュメントについては、 Snowflakeデータクリーンルーム：コンシューマーAPIリファレンスガイド のコンシューマー定義のテンプレートのセクションをご参照ください。

コンシューマーからのリクエストのリストアップ

プロバイダーは、 provider.list_template_requests コマンドを実行し、承認または拒否されたリクエストを含むすべてのリクエストを表示します。

例えば、プロバイダーのクリーンルームの名前が dcr_cleanroom だとします。結果に関係なく行われたすべてのリクエストをリストアップするために、プロバイダーは以下のコマンドを実行します。

CALL samooha_by_snowflake_local_db.provider.list_template_requests('dcr_cleanroom');
Copy

provider.list_template_requests コマンドの参照ドキュメントについては、 Snowflakeデータクリーンルーム：プロバイダーAPIリファレンスガイド のコンシューマー定義のテンプレートのセクションをご参照ください。

言語: 日本語