개발자 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

세 번째 인자는 템플릿을 정의하는 Jinja 코드입니다.

consumer.create_template_request 명령의 참조 설명서는 Snowflake Data Clean Rooms: 컨슈머 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 Data Clean Rooms: 공급자 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 Data Clean Rooms: 공급자 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 Data Clean Rooms: 컨슈머 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 Data Clean Rooms: 공급자 API 참조 가이드 의 컨슈머 정의 템플릿 섹션을 참조하십시오.

언어: 한국어