다중 공급자 컨슈머 분석

컨슈머는 한 번의 요청으로 동일 또는 여러 공급자가 소유한 여러 Clean Rooms에서 분석을 실행하고 합산된 결과를 확인할 수 있습니다. 결과는 각 Clean Room의 분석 결과를 합친 것이지, 여러 Clean Room의 공급자 데이터를 합쳐서 분석한 컨슈머 데이터를 합친 것이 아닙니다.

공급자는 요청을 승인하기 전에 쿼리 중인 다른 Clean Rooms와 템플릿을 포함한 요청의 모든 세부 정보를 확인할 수 있습니다. 공급자는 다른 Clean Rooms의 데이터나 다른 Clean Rooms에서 어떤 공급자 테이블이 쿼리되고 있는지조차 볼 수 없습니다. 각 Clean Room의 데이터는 각 Clean Room의 조인, 열 및 기타 정책을 준수하여 안전하게 액세스하고 처리합니다.

모든 Clean Rooms에서 활성화가 활성화된 경우 다중 공급자 분석 결과를 활성화할 수 있습니다.

요구 사항

  • 템플릿: 다중 공급자 분석은 모든 Snowflake 제공 또는 사용자 지정 템플릿에서 실행할 수 있습니다.

  • 환경: 다중 공급자 분석은 Clean Room API 를 사용해야만 구현할 수 있습니다. Clean Rooms UI 에서는 실행할 수 없습니다.

  • 청구: 컨슈머는 여러 공급자의 쿼리에 대해 비용을 지불합니다.

  • 기타 요구 사항: - 다중 공급자 분석의 모든 Clean Rooms에는 공급자 참여 정책이 있어야 합니다. Clean Room에서 분석이 실패하면 전체 요청이 실패하게 됩니다.

다중 공급자 분석 개요

다음은 다중 공급자 분석의 작동 방식에 대한 개략적인 개요입니다. 실행 가능한 샘플 코드는 코드 샘플을 참조하십시오.

  1. 컨슈머는 모든 Clean Rooms를 표준 방식에 따라 다중 공급자 흐름에서 사용할 수 있도록 설치 관리자가 설치합니다. 다중 공급자 분석의 Clean Rooms는 표준 Clean Rooms입니다.

  2. 컨슈머는 데이터 세트를 연결하고 표준 방식으로 조인 정책을 설정합니다. 템플릿에 의해 정책이 확인되는지 여부에 관계없이 공급자와 컨슈머 Clean Rooms에는 모두 조인 정책이 정의되어 있어야 합니다.

  3. 요청은 단일 템플릿에 대한 것이며, 모든 Clean Rooms에는 해당 템플릿이 설치되어 있어야 합니다. 컨슈머가 사용자 지정 템플릿을 사용하려면 표준 컨슈머 템플릿 요청 흐름 을 거쳐야 합니다.

    1. 컨슈머는 각 Clean Room에서 consumer.create_template_request 를 호출하여 사용자 지정 템플릿을 전달합니다.

    2. 공급자는 provider.list_pending_template_requests 를 호출하여 보류 중인 템플릿 요청을 확인한 다음 provider.approve_template_request 를 호출하여 Clean Room에 템플릿을 추가하는 것을 승인합니다.

    3. 컨슈머는 consumer.list_template_requests 를 호출하여 요청이 승인되었는지 확인합니다.

  4. 공급자와 컨슈머는 표준 방식으로 템플릿에 대한 열 정책을 설정합니다.

  5. 공급자는 각 Clean Room에서 provider.enable_multiprovider_computation 을 호출하여 컨슈머의 요청을 표시합니다. (이 호출 전에 전송된 요청은 큐에 대기하지만 이 프로시저가 호출될 때까지 공급자에게 표시되지 않습니다.)

  6. 컨슈머가 템플릿 실행에 대한 승인을 요청합니다. 요청 및 승인 흐름에는 몇 가지 변형 이 있지만 기본 흐름은 다음과 같습니다.

    1. 컨슈머는 consumer.prepare_multiprovider_flow 를 호출하여 모든 Clean Rooms에 다중 공급자 요청을 보냅니다. 이 요청은 Clean Rooms 목록, 사용된 템플릿, 공급자 및 컨슈머 테이블을 포함한 모든 템플릿 매개 변수를 지정합니다. 호출은 한 번만 이루어지며 요청에 포함된 모든 Clean Rooms에 브로드캐스트됩니다. 각 Clean Room은 모든 요청 세부 정보를 볼 수 있지만 공급자 테이블 목록은 해당 Clean Room의 공급자 테이블로 필터링됩니다. 요청 ID 를 반환합니다.

    2. 각 공급자는 provider.view_multiprovider_requests 를 호출하여 컨슈머가 보낸 여러 공급자의 요청을 확인한 다음 provider.process_multiprovider_request 를 호출하여 이를 승인합니다.

  7. 모든 Clean Rooms가 요청을 승인하면 컨슈머는 consumer.execute_multiprovider_flow 를 호출하여 요청을 실행합니다. 템플릿은 가장 최근 consumer.prepare_multiprovider_flow 요청에 제공된 정보로 각 Clean Room에서 실행되며, 결합된 결과가 컨슈머에게 전송됩니다. 컨슈머는 공급자가 쿼리에 대한 권한을 취소하거나 차등 개인정보 보호 예산이 소진될 때까지(차등 개인정보 보호가 활성화된 경우) 다른 승인 없이 execute_multiprovider_flow 를 다시 호출할 수 있습니다.

요청 및 승인 세부 정보

요청 및 승인 절차에 대한 자세한 내용은 다음과 같습니다. 여러 가지 변형된 절차가 있습니다.

요청 및 승인 흐름의 변형

다중 공급자 분석을 실행할 때 가능한 흐름은 세 가지입니다.

요청별 승인(기본 동작):

  1. 컨슈머 가 쿼리 세부 정보로 consumer.prepare_multiprovider_flow 를 호출합니다.

  2. 공급자 가 쿼리(provider.view_multiprovider_requests)를 보고 승인합니다(provider.process_multiprovider_request). 공급자가 이전에 이 쿼리를 승인한 경우 이 단계를 생략할 수 있습니다.

  3. 컨슈머 가 쿼리를 실행합니다(consumer.execute_multiprovider_flow).

컨슈머 및 Clean Room별 승인:

  1. 컨슈머 가 쿼리 세부 정보로 consumer.prepare_multiprovider_flow 를 호출합니다.

  2. 공급자 가 쿼리(provider.view_multiprovider_requests)를 보고 승인하여(provider.process_multiprovider_request) 실제 쿼리 ID 대신 쿼리 ID 로 -1 을 전달합니다. 따라서 컨슈머는 향후에도 consumer.prepare_multiprovider_flow 를 호출해야 하지만, 공급자의 추가 승인 없이 자동으로 승인이 부여됩니다.

  3. 컨슈머 가 쿼리를 실행합니다(consumer.execute_multiprovider_flow).

자동 승인:

  1. 공급자 가 Clean Room에서 provider.resume_multiprovider_tasks 를 호출합니다. 이 Clean Room의 모든 컨슈머 다중 공급자 요청은 자동으로 승인됩니다.

  2. 컨슈머 가 쿼리 세부 정보로 consumer.prepare_multiprovider_flow 를 호출합니다. 요청이 자동으로 승인됩니다.

  3. 컨슈머 가 쿼리를 실행합니다(consumer.execute_multiprovider_flow).

모든 흐름에서 이전에 부여된 모든 쿼리 승인을 취소할 수 있습니다.

쿼리 승인 기준

consumer.execute_multiprovider_flow 는 consumer.prepare_multiprovider_flow 로 전송된 마지막 쿼리를 평가하여 승인 여부를 확인합니다. 승인된 요청과 일치하는 항목이 발견되면 쿼리가 진행됩니다. 이전에 일치하는 요청을 찾을 수 없으면 consumer.execute_multiprovider_flow 가 실패합니다. (이 컨슈머 또는 모든 컨슈머에 대해 포괄 승인 이 부여된 경우 승인 확인을 건너뜁니다.) 이전 승인은 다음 값과 비교하여 일치합니다.

  • 쿼리 중인 Clean Rooms 목록.

  • Clean Room으로 전송된 인자 이름. 승인된 요청에 있는 모든 인자 이름이 새 요청에도 있어야 합니다. 인자 값은 확인되지 않고 인자 이름만 확인됩니다.

  • 실행 중인 템플릿의 이름.

또한 템플릿은 행 정책, 열 정책, 차등 개인정보 보호(활성화된 경우) 등 모든 Clean Room 정책을 준수해야 하며, 포괄적인 승인을 받았는지 여부에 관계없이 모든 Clean Room 정책을 준수해야 합니다.

승인 기록

consumer.execute_multiprovider_flow 는 consumer.prepare_multiprovider_flow 로 전송된 마지막 쿼리를 실행하려고 시도합니다. 모든 보안 검사를 통과하고 일치하는 쿼리가 과거에 승인된 적이 있는 경우 쿼리를 실행할 수 있습니다. 따라서 다음과 같은 흐름을 볼 수 있습니다.

  1. 컨슈머가 쿼리 A를 준비합니다.

  2. 공급자가 A를 승인합니다.

  3. 컨슈머가 A를 실행합니다.

  4. 컨슈머가 쿼리 B를 준비합니다.

  5. 공급자가 B를 승인합니다.

  6. 컨슈머가 B를 실행합니다.

  7. 컨슈머는 동일한 매개 변수를 사용하여 쿼리 A를 다시 준비합니다.

  8. 컨슈머는 이미 승인되었으므로 공급자의 승인 없이도 A를 다시 실행할 수 있습니다. Clean Room에서 쿼리가 이미 승인되었는지 여부를 결정하는 방법은 다음 섹션을 참조하십시오.

자동 쿼리 승인 활성화 또는 비활성화하기

쿼리 승인은 Clean Room에서 컨슈머별로 또는 모든 컨슈머에 대해 자동화할 수 있습니다.

Clean Room에서 주어진 컨슈머의 모든 다중 공급자 쿼리를 자동으로 승인하기 위해 공급자는 -1 을 쿼리 ID 로 사용하여 provider.process_multiprovider_request 를 호출합니다. 그러면 해당 Clean Room에 있는 해당 컨슈머의 모든 다중 공급자 요청이 승인됩니다. (컨슈머는 쿼리를 변경할 때 여전히 consumer.prepare_multiprovider_flow 를 호출해야 하며, 공급자는 provider.view_multiprovider_requests 요청 기록에서 모든 consumer.prepare_multiprovider_flow 호출을 볼 수 있습니다.) 특정 사용자에게 부여된 자동 승인을 비활성화하려면 승인 로그를 업데이트 해야 합니다.

모든 컨슈머에 대한 모든 다중 공급자 쿼리를 자동으로 승인하기 위해 공급자는 Clean Room에서 provider.resume_multiprovider_tasks 를 호출합니다. 그러면 모든 컨슈머의 모든 다중 공급자 요청이 자동으로 승인됩니다. (컨슈머는 쿼리를 변경할 때 여전히 consumer.prepare_multiprovider_flow 를 호출해야 하며, 공급자는 provider.view_multiprovider_requests 요청 기록에서 모든 consumer.prepare_multiprovider_flow 호출을 볼 수 있습니다.) 이러한 방식으로 부여된 자동 승인을 비활성화하려면 provider.suspend_multiprovider_tasks 를 호출하십시오.

템플릿 디자인하기

다중 공급자 흐름은 테스트하는 데 시간이 오래 걸리고 템플릿 오류를 가릴 수 있는 단계가 많으므로 템플릿을 다중 공급자 흐름에서 사용하기 전에 공급자가 만든 기본 컨슈머 실행 흐름에서 템플릿을 테스트하여 템플릿이 올바른지 확인하십시오.

각 Clean Room은 똑같은 템플릿을 실행하지만 각 Clean Room에 전달되는 source_table 목록은 해당 Clean Room의 공급자 테이블만 표시하도록 필터링되기 때문에 길이와 테이블 이름이 다를 수 있습니다. 따라서 쿼리에 따라 다양한 목록 길이 또는 테이블 이름을 처리하기 위해 Jinja 루핑 및 조건문을 사용해야 할 수도 있습니다.

자동 승인 관리 및 승인 상태 변경하기

요청 기록 로그

공급자가 provider.enable_multiprovider_computation 을 호출하면 samooha_cleanroom_cleanroom_ID.admin.request_log_multiprovider 라는 로그 테이블이 생성됩니다. 공급자가 Clean Room에 대한 다중 공급자 분석을 승인할 때마다 요청이 여기에 로그됩니다. 컨슈머가 여러 공급자의 쿼리 실행을 요청할 때 Clean Rooms가 확인하는 테이블입니다. 이 테이블에는 요청 실행 허용 여부를 나타내는 approved 열이 포함되어 있습니다. 쿼리는 테이블에 추가되기 전에 승인을 받아야 하므로 초기 approved 상태는 true 이지만, 나중에 승인을 취소하려는 경우 변경할 수 있습니다.

로그 테이블에는 컨슈머의 쿼리 실행이 아닌 provider.process_multiprovider_request 에서의 컨슈머 쿼리 요청이 보관됩니다. 컨슈머 쿼리 실행은 로그에 기록되지 않습니다.

이전에 승인된 요청 거부하기

이전에 승인된 요청을 거부하려면 다중 공급자 요청 로그 테이블의 approved 열을 FALSE 로 업데이트해야 합니다.

컨슈머는 동일한 쿼리를 여러 번 제출할 수 있고 지정된 쿼리에 대한 승인을 받으면 쿼리를 실행할 수 있으므로 다중 공급자 쿼리를 비활성화하는 가장 안전한 방법은 지정된 컨슈머의 모든 쿼리에 대해 approved=false 를 설정한 다음 컨슈머에게 consumer.prepare_multiprovider_flow 를 호출하여 실행하려는 쿼리를 다시 제출하도록 지시하는 것입니다.

-- 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 PARTY_ACCOUNT='<CONSUMER_LOCATOR>';
Copy

이전에 거부된 요청 활성화하기

이전에 요청을 승인했다가 거부한 후 다시 승인하려는 경우 일반적으로 요청 로그 테이블을 업데이트하기보다는 컨슈머에게 흐름 요청을 다시 제출하도록 요청한 다음 표준 흐름에서 승인하는 것이 가장 안전합니다.

자동 승인 취소하기

  • provider.resume_multiprovider_tasks 를 호출하여 Clean Room에서 모든 컨슈머에 대해 자동 승인을 활성화한 경우 provider.suspend_multiprovider_tasks 를 호출하여 모든 사용자에 대한 포괄 승인을 취소하십시오.

  • provider.process_multiprovider_request 에서 -1 을 쿼리 ID 로 지정하여 Clean Room의 특정 컨슈머에 대한 자동 승인을 활성화한 경우 이전에 승인된 요청 거부하기 섹션을 참조하십시오.

코드 샘플

다음 통합 문서를 다운로드하여 다중 공급자 분석 흐름을 사용해 보십시오. Clean Rooms API 가 설치된 두 개의 Snowflake 계정이 필요합니다. 하나는 공급자 역할을 하고 다른 하나는 컨슈머 역할을 합니다. 공급자 계정은 두 개의 Clean Room을 생성하며, 이는 각각 하나의 Clean Room을 가진 여러 공급자가 있는 것과 유사하게 작동합니다.

언어: 한국어