집계 정책을 사용하여 엔터티 수준 개인정보 보호 구현하기¶

엔터티 수준 개인정보 보호가 없는 집계 정책¶

기본적으로 집계 정책에서는 분석가가 개별 행을 검색하는 대신 데이터를 집계하는 쿼리를 실행해야 하므로 행 수준의 개인정보 보호 가 달성됩니다. 그러나 행 수준 프라이버시는 해당 특성이 여러 행(예: 트랜잭션 데이터가 포함된 테이블)에서 발견되는 경우 쿼리에서 엔터티의 특성이 노출되는 것을 방지하지 못합니다.

예를 들어, 스트리밍 서비스 ActonViz에 프로그램을 시청하는 각 시청자의 이메일 주소(user_id) 및 가구(household_id)가 포함된 트랜잭션 테이블이 있다고 가정해 보겠습니다.

ActonViz는 광고주가 최소 2개의 레코드가 포함된 그룹으로 데이터를 집계하도록 강제하기 위해 집계 정책을 사용할 수 있습니다. 이를 통해 광고주가 개별 레코드에서 데이터를 검색하는 것을 방지할 수 있습니다(행 수준 개인정보 보호). 각 시청자 및 가구가 테이블에 한 번만 나타나면 개인 정보를 보호하기에 충분합니다.

하지만 광고주의 쿼리를 통해 시청자와 시청자의 가구에 대한 정보를 파악할 수 있습니다. 쿼리를 통해 가구 12345 의 레코드로만 구성된 그룹이 생성되거나, 더 심하게는 시청자 dave_sr 의 레코드로만 구성된 그룹이 생성될 수도 있습니다. 두 경우 모두 그룹의 레코드 수가 ActonViz에서 설정한 요구 사항(그룹당 최소 2개 레코드)을 충족합니다.

엔터티 수준 개인정보 보호 기능이 있는 집계 정책¶

엔터티 수준의 개인 정보 보호를 달성하기 위해 Snowflake를 사용하면 테이블 또는 뷰에 집계 정책을 할당할 때 1개 이상의 엔터티 키를 지정할 수 있습니다. 엔터티 키가 정의된 후 집계 제약이 있는 테이블 또는 뷰에 대한 쿼리가 반환하는 그룹에는 지정된 수의 행 이 아니라 지정된 수 이상의 엔터티 가 포함되어야 합니다.

앞의 예제에서 ActonViz는 각 가구를 고유하게 식별하기 때문에 household_id 를 엔터티 키로 정의한다고 가정해 보겠습니다. 이제 각 가정의 프라이버시가 개선되었습니다. 변경 전에는 그룹이 household_id = 12345 인 레코드로만 구성될 수 있었지만, 이제 그룹에는 최소 두 개의 고유 household_id 값이 포함되어야 합니다.

엔터티 키가 항상 테이블의 기본 키 와 동일한 것은 아닙니다. 이 예제에서 테이블은 뷰어를 고유하게 식별하기 때문에 user_id 를 기본 키로 사용할 수 있습니다. 하지만 이 경우 ActonViz는 여러 시청자로 구성된 전체 가구의 개인 정보를 보호하고 싶었기 때문에 엔터티 키로 household_id 를 선택했습니다.

최소 엔터티 수 지정¶

엔터티 키를 사용하여 엔터티 수준의 개인 정보 보호를 수행하는 경우 CREATE AGGREGATION POLICY 를 사용하여 집계 정책을 생성하는 구문은 변경되지 않습니다. AGGREGATION_CONSTRAINT 함수의 MIN_GROUP_SIZE 인자를 사용하여 최소 그룹 크기를 지정하는 기능은 계속 제공됩니다. 엔터티 키를 정의 하는 즉시 최소 그룹 크기가 그룹 내 레코드 수에 대한 요구 사항에서 그룹 내 엔터티 수로 변경됩니다.

예를 들어, 다음 코드는 최소 그룹 크기가 5인 집계 정책을 생성합니다. 정책을 테이블에 할당할 때 엔터티 키를 정의하는 한, 각 집계 그룹에는 최소 5개의 엔터티가 포함되어야 합니다.

CREATE AGGREGATION POLICY my_agg_policy
  AS () RETURNS AGGREGATION_CONSTRAINT ->
  AGGREGATION_CONSTRAINT(MIN_GROUP_SIZE => 5);

다양한 상황에서 다양한 제한을 적용하는 조건부 집계 정책의 예를 포함하여 집계 정책 생성에 대한 전체 세부 정보는 집계 정책 만들기 섹션을 참조하십시오.

엔터티 키 정의¶

테이블이나 뷰에 집계 정책을 할당할 때 테이블의 엔터티 키를 정의합니다. 새 테이블 또는 뷰를 생성 하거나 기존 뷰 테이블을 업데이트 할 때 엔터티 키를 정의할 수 있습니다.

ALTER TABLE viewership_log
  SET AGGREGATION POLICY my_agg_policy
  ENTITY KEY (first_name,last_name);

ALTER TABLE transactions ADD AGGREGATION POLICY ap ENTITY KEY (user_id, user_email);
ALTER TABLE transactions ADD AGGREGATION POLICY ap ENTITY KEY (vendor_id);

ALTER TABLE transactions ADD AGGREGATION POLICY ap ENTITY KEY (user_id) ENTITY KEY (vendor_id);

CREATE TABLE t1
  WITH AGGREGATION POLICY my_agg_policy
  ENTITY KEY (first_name,last_name);

연기 예시¶

(zipcode, email) 로 정의된 엔터티에 대해 사용자를 ‘저소비자’와 ‘고소비자’라는 2개의 버킷으로 집계한다고 가정해 보겠습니다. 지연을 사용하면 다음 예시와 같이 작동합니다. 지연이 없으면 각 그룹은 1개의 (zipcode, email) 엔터티로 구성되므로 내부 쿼리는 NULL 을 반환하며, 이는 min_group_size 가 1보다 큰 값으로 설정될 때 표시되지 않습니다.

WITH bucketed AS (
  SELECT
    CASE
      WHEN SUM(transaction_amount) BETWEEN 0 AND 100 THEN 'low'
      WHEN SUM(transaction_amount) BETWEEN 101 AND 100000 THEN 'high'
    END AS transaction_bucket,
    zipcode,               -- zipcode and email need not appear in the select list, but this lets us compute entity_count below
    email
  FROM my_transactions
  GROUP BY zipcode, email  -- This would not work if it was only GROUP BY zipcode, since the entity key is (zipcode, email)
)
SELECT
  transaction_bucket,
  COUNT(DISTINCT zipcode, email) AS entity_count
FROM
  bucketed
GROUP BY transaction_bucket;

다중 정책 연기¶

테이블에 여러 개의 집계 정책이 있는 경우 각 집계 정책은 독립적으로 평가되고 지연될 수 있습니다. 테이블에 여러 개의 집계 정책이 있는 경우 쿼리 수준마다 다른 정책이 적용되면 예기치 않은 결과가 발생할 수 있으므로 쿼리를 신중하게 설계하십시오.

예를 들어, 2개의 개별 집계 정책이 있는 테이블에서 사용자를 고비용 및 저비용 카테고리로 버킷화하기 위해 중첩 쿼리를 시도하는 경우 발생할 수 있는 문제는 다음과 같습니다.

테이블 T:

user_id, vendor_id, zipcode, email,         transaction_amount
   1     1001       90000    a@example.com        100
   1     1001       90000    a@example.com         50
   2     2001       90001    b@example.com         12
   2     2001       90001    b@example.com          5
   3     3001       90002    c@example.com         40

집계 정책:

• user_policy: min_group_size = 3, 엔터티 키 = (user_id)

• vendor_policy: min_group_size = 2, 엔터티 키 = (vendor_id)

버킷 사용자를 고액 또는 저액 지출자로 쿼리:

WITH amounts AS (
  SELECT
    user_id,
    IFF(SUM(transaction_amount) > 50, 'high', 'low') AS bucket
  FROM T
  GROUP BY user_id -- user_policy is deferred, but vendor_policy is enforced
)
SELECT COUNT(*) FROM amounts GROUP BY bucket

Copy

예기치 않은 결과:

내부 쿼리에서는 vendor_policy 가 적용됩니다. 각 행은 user_id 로 그룹화되어 있는데, 해당되는 vendor_id 가 1개만 있어 vendor_policy 최소 그룹 크기를 위반하고, 내부 쿼리는 “높음” 버킷에 세 명의 고객이 속해 있음에도 불구하고 NULL 을 반환합니다.