Snowflake Data Clean Rooms: 다중 공급자 클린룸

이 항목에서는 여러 공급자의 클린룸 클러스터에서 분석을 실행하는 예제를 제공합니다. 이는 각 클린룸의 보안을 보장하는 동시에 쿼리가 여러 클린룸의 데이터에 어떻게 액세스할 수 있는지 보여줍니다. 또한 컨슈머가 분석을 실행하는 데 사용되는 템플릿을 정의하는 방법을 보여주며, 이는 여러 공급자가 있는 클린룸의 일반적인 사용 사례입니다.

다중 공급자 분석에서는 각 클린룸의 데이터가 완전한 보안 방식으로 사용됩니다. Snowflake Data Clean Rooms는 모든 개별 클린룸 보안 정책을 준수하는 동시에 데이터에 대한 모든 SQL 실행이 각 클린룸 참여자가 기대하는 것과 정확히 일치하는 방식으로 실행된다는 증명합니다.

많은 경우, 다중 공급자 분석을 실행하는 컨슈머는 공급자가 정의한 템플릿을 사용하는 대신 분석에 대한 템플릿을 직접 정의할 수 있기를 원합니다. 이를 통해 컨슈머는 여러 당사자의 데이터를 분석할 때 인사이트을 얻는 방법을 제어할 수 있습니다. 컨슈머 정의 템플릿에 대한 자세한 내용은 개발자 API를 사용하여 컨슈머 정의 템플릿 추가하기 섹션을 참조하십시오.

참고

여러 리전에서 공유되는 클린룸에서는 여러 공급자의 클린룸 분석이 허용되지 않습니다.

다중 공급자 분석 예에는 다음 단계가 포함됩니다.

  1. 공급자:

    a. 두 개의 다른 공급자를 시뮬레이션하는 두 개의 클린룸을 만듭니다.

    b. 동일한 컨슈머와 클린룸을 공유합니다.

  2. 컨슈머:

    a. 두 공급자 모두 클린룸을 설치합니다.

    b. 클린룸에 컨슈머가 정의한 템플릿을 추가하기 위한 요청을 보냅니다.

  3. 공급자:

    a. 컨슈머가 정의한 템플릿을 추가하라는 컨슈머의 요청을 승인합니다.

    b. 컨슈머 정의 템플릿에 대한 열 정책을 설정합니다.

  4. 컨슈머:

    a. 다중 공급자 분석 요청을 제기합니다.

  5. 공급자:

    a. 다중 공급자 분석을 위해 클린룸을 활성화합니다.

    b. 컨슈머로부터 다중 공급자 분석 요청을 승인합니다.

  6. 컨슈머

    a. 클린룸 클러스터 전체에서 분석을 실행합니다.

전제 조건

이 예제를 완료하려면 두 개의 별도 Snowflake 계정이 필요합니다. 첫 번째 계정을 사용하여 공급자의 명령을 실행한 다음 두 번째 계정으로 전환하여 컨슈머의 명령을 실행합니다.

공급자: 클린룸을 만들고 공유합니다.

이 섹션의 명령을 실행하려면 공급자 계정에서 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 의 두 번째 인자는 클린룸의 분포입니다. 이는 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

다음으로, 클린룸 내에서 템플릿을 실행할 때 컨슈머가 조인할 수 있는 열을 지정합니다. 이메일과 같은 ID 열에 대해 다음 명령을 실행합니다. 참여 정책을 두 번째로 설정하면 이전에 설정한 참여 정책이 새 정책으로 완전히 대체됩니다.

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

컨슈머: 클린룸에 컨슈머 정의 템플릿 추가 요청 보내기

다중 공급자 분석을 실행하는 컨슈머는 여러 당사자의 데이터에서 가치를 추출하는 방법을 가장 잘 알고 있는 경우가 많습니다. 컨슈머는 클린룸 공급자에게 클린룸에 컨슈머 정의 템플릿을 포함하도록 요청하여 컨슈머가 분석을 실행하는 데 사용할 수 있도록 할 수 있습니다. 클린룸에 컨슈머 정의 템플릿을 추가하는 방법에 대한 자세한 내용은 컨슈머 정의 템플릿 추가하기 섹션을 참조하십시오.

참고

다중 공급자 클린룸에서의 분석은 현재 클린룸뿐만 아니라 다른 클린룸의 모든 테이블을 템플릿의 source_tables 인자로 렌더링하는 방식으로 작동합니다. 그러나 보안 유효성 검사 및 요청 승인 시 각 클린룸은 해당 클린룸과 관련된 테이블만 받습니다. 따라서 템플릿은 특정 수의 source_table 인자를 가정하지 않고 일반적으로 작성해야 하나 이상의 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 명령을 실행하여 요청을 승인합니다. 이 프로세스에 대한 자세한 내용은 컨슈머 정의 템플릿 추가하기 섹션을 참조하십시오.

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 열을 추론하여 이 작업을 차단하지만, 샌드박스 환경에서는 이 추론을 사용할 수 없습니다. 예를 들어, 컨슈머가 상태, 연령대, 리전 코드, 활성 일수 등을 기준으로 집계하고 그룹화할 수 있는 열에만 사용해야 합니다.

컨슈머 분석 요청에 대한 검사를 수행하기 위해 “column_policy” 및 “join_policy”가 SQL Jinja 템플릿에서 모든 열 이름을 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

일반적인 오류

실행한 분석의 결과로 승인되지 않음: 승인되지 않은 열이 사용됨 오류가 발생하는 경우, 공급자가 설정한 조인 정책 및 열 정책을 확인하십시오.

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

요청 승인은 다음 두 가지 방법 중 하나로 이루어질 수 있습니다.

  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를 사용하여 실행할 수 있습니다. 이 실행은 하나의 클린룸이 무작위로 선택되어 흐름을 실행하는 방식으로 이루어지며, 두 클린룸이 모두 요청을 승인하면 다중 공급자 분석을 진행할 수 있습니다.

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
언어: 한국어