Snowflake Data Clean Room : 다른 회사와 서로 데이터를 노출하지 않으면서 서로의 데이터를 활용할 수 있는 방법
우리 회사의 다른 계열사와 또는 우리 비즈니스와 연결된 다른 회사와 데이터를 공유하고는 싶지만 서로의 데이터가 노출되는 것이 염려되었던 적 없으신가요? 공유는 받고 싶지만 내 데이터는 노출하기 싫어라니 그게 무슨 마음인가요? 싶으실테지만 실제 기업에서는 이런 요구사항이 생각보다 많이 그리고 자주 발생하고 있습니다.
이런 경우들에 대한 좀 더 구체적인 예를 들어보면 이렇습니다. A라는 미디어회사는 미디어를 이용하는 고객데이터에 대한 정보들을 가지고 있고, B라는 회사는 자신들의 제품을 이용하는 고객데이터에 대한 정보를 가지고 있습니다. B라는 회사가 A라는 회사에 광고를 하고 싶은 경우 우리 고객이 제일 많이 보는 미디어가 무엇인지, 또는 우리 고객군과 가장 유사한 고객군들이 많이 이용하는 미디어가 무엇인지를 확인해서 해당 미디어에 자신들의 제품을 광고하도록 투자할 수 있겠죠. 좀 더 생각해보면 해당 내용이 가능해지기 위해서는 한 회사가 다른 회사에게 자신들의 고객데이터를 넘겨주어야만 해당 분석이 가능해지게 됩니다. 그런데 자신들의 고객데이터를 다른 회사로 넘겨주고 싶은 회사가 있을까요? 여기서 회사들의 딜레마가 일어납니다. 소스를 공유하지 않고 정보를 공유하고 싶어지는 거죠.
소스를 공유하지 않고 정보를 공유할 수 있는 Snowflake Data Clean Room
다행히도 Snowflake에서는 회사들이 단방향/양방향적인 데이터 공유 대신 우리 회사와 상대 회사가 공통으로 가지고 있는 부분이 무엇인지를 확인하고, 해당 부분만을 서로 공유할 수 있도록 하는 Data Clean Room을 제공합니다.
이런 기능은 산업 전반에 걸쳐 다양한 사용 사례들을 통해 활용될 수 있습니다. 앞서 예를 든 것 처럼 광고를 어떤 미디어에 배치할지 또는 마케팅 캠페인에 대한 최적화에서 사용될 수도 있고 또는 부품 공급업체와 제조회사에서 데이터 공유를 통해 결함을 예측하고 제품 개발을 개선하여 예상치 못한 다운타임을 줄일 수도 있습니다. 은행과 소매업체가 협력하여 브랜드별 신용 카드 상품을 개발할수도, 사기 탐지를 개선하기 위한 거래 패턴 식별 또는 의료 활동 결과를 개선하기 위한 환자 수명 주기 추적 등에서도 활용될 수 있는 기회 등 안전한 데이터 협업의 기회는 무궁무진합니다.
Snowlake Data Clean Room에서 일어나는 일
실제 이 기능을 구현하고자 하는 엔지니어분들을 위해 좀 더 자세히 내부에서 일어나는 프로세스에 대해 설명드리겠습니다. 실제 이 과정은 QuickStart를 통해서도 제공되고 있습니다.
A회사와 B회사가 서로 공통된 데이터에 대한 분석쿼리 결과를 공유받을 수 있는 Data Clean Room을 구성한다고 생각해봅시다.
1단계) A회사에서는 B회사가 A회사의 데이터를 바탕으로 활용할 수 있는 분석쿼리와 공유할 수 있는 컬럼명을 미리 정의합니다.
예를 들어 A회사의 특정 테이블 안에서도 B회사와 공통된 키를 가진 특정 row들만을 조회하도록 할 수도 있고, 또는 특정 row들의 상세 값들이 아닌 sum/count와 같은 요약된 결과만을 조회하도록 정할 수도 있습니다.
(허용 가능한 쿼리) : B회사와 email 컬럼으로 조인한 결과값을 제공
(공유 가능 컬럼명) : 고객 행동 타입, 고객의 위치 데이터
2단계) A회사는 해당 분석 쿼리를 수행하기 위해 필요한 A회사의 고객 세그먼트 테이블을 B회사와 공유합니다. (참고> Snowflake의 데이터 공유 모델을 아시는 분은 이미 아시겠지만, 데이터를 공유했다고해서 실제 A회사의 데이터가 B회사로 물리적으로 복제되는 것은 아닙니다. B회사가 A회사의 스토리지에 접근해서 A회사의 데이터에 접근할 수 있도록 해주는 것이죠.)
A회사에서 테이블을 공유하나 B회사 분석가는 모든 행에 대한 Row Access Policy 때문에 직접 공유된 테이블을 전혀 읽을 수 없는 상태입니다. Row Access Policy는 원하는 행에 대해 선택적으로 접근을 못하게 하도록 설정할 수 있지만, Clean Room 시나리오에서는 원하는 행(서로 공통된 행)이 무엇인지 A회사에서 미리 확인하기 어렵기 때문에 모든 행에 대한 접근을 막아둡니다.
3단계) B회사 에서는 수행하고 싶은 분석쿼리를 [요청 프로시저]를 통해 요청합니다.
B회사에서 수행하고자 하는 분석쿼리를 프로시저로 실행하면 해당 내용이 A회사 계정으로 전달됩니다.
4단계) A회사 에서는 새로운 요청이 발생했음을 확인 후 해당 요청이 사전 정의한 범위 내에 있는지를 [확인 프로시저]를 통해 확인합니다.
A회사 Admin가 [확인 프로시저]를 수행 하면 해당 프로시저는 분석쿼리 요청 내역이 A회사 에서 1단계에서 정의해둔 범위에 포함되는 요청인지를 확인하고 맞다면 요청된 분석쿼리를 수행합니다.
5단계) B회사 분석가는 분석쿼리 결과를 조회합니다.
쿼리 확인 프로시저는 확인이 완료된 후 이미 요청된 분석쿼리 결과를 수행하여 테이블로 만들어두었기 때문에 B회사에서는 필요한 데이터의 테이블만을 선택적으로 확인할 수 있게 됩니다.
과정은 복잡해보이지만 실제로 복잡한 과정들은 모두 프로시저를 통해 Snowflake 내부에서 일어나게 됩니다. 고객들은 안전하게 우리 회사의 데이터를 노출할 위험 없이 프로시저 실행 명령만으로 선택된 데이터만을 공유받고 공유할 수 있게 됩니다. 그리고 이 모든 기록은 계정안에서 조회할 수도 있습니다. 현재 이 과정은 QuickStart를 통해서도 제공되고 있습니다.
