集計ポリシーによるエンティティレベルのプライバシーの実装¶

エンティティレベルのプライバシーが ない 集計ポリシー¶

デフォルトでは、集計ポリシーにより、アナリストは個々の行を取得するのではなく、データを集計するクエリを実行する、つまり 行レベルのプライバシー を達成する必要があります。しかし、行レベルのプライバシーは、クエリによってエンティティの属性が複数の行（例えば、トランザクションデータを含むテーブル）で検出された場合に、その属性が公開されることを防ぐことはできません。

たとえば、あるストリーミングサービス（ActonViz）が、番組を視聴する各視聴者の電子メールアドレス（user_id）と世帯（household_id）を含むトランザクションテーブルを持っているとします。

ActonVizは、集計ポリシーを使用して、少なくとも2つの記録を含むグループにデータを集約するように広告主に強制することができます。これにより、広告主が個々の記録からデータを取得することを防ぎます（行レベルのプライバシー）。それぞれの視聴者と世帯が表に一度だけ登場すれば、プライバシー保護には十分でしょう。

しかし、広告主のクエリは、視聴者とその世帯の両方の情報を知ることができます。クエリによって、世帯 12345 の記録だけで構成されるグループや、さらに悪いことに、視聴者 dave_sr の記録だけで構成されるグループが作成される可能性があります。どちらの場合も、グループ内の記録数はActonViz（1グループあたり最低2件の記録）が定める条件を満たすことになります。

エンティティレベルのプライバシーを 持つ 集計ポリシー¶

エンティティレベルのプライバシーを可能にするために、Snowflakeではテーブルやビューに集計ポリシーを割り当てる際に1つまたは複数のエンティティキーを指定することができます。エンティティキーが定義された後、集約制約のあるテーブルまたはビューに対するクエリによって返されるグループには、少なくとも指定した エンティティ 数が含まれている必要があります（指定した 行 数ではない）。

先ほどの例で、 ActonViz が各世帯を一意に識別するため、 household_id をエンティティキーとして定義したとします。各世帯のプライバシーが強化されるようになります。変更前は、 household_id = 12345 の記録だけでグループを構成することができましたが、現在は、 household_id の少なくとも2つの異なる値を含む必要があります。

エンティティキーは、テーブルの プライマリキー と同じになるとは限らないことに注意してください。この例では、 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タイプのバケットに集約したいとします。繰り延べによって、次の例のように動作させることができます。繰り延べがない場合、内側のクエリはNULLを返します。各グループが1つの (zipcode, email) エンティティで構成され、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;

複数ポリシーの繰り延べ¶

テーブルに複数の集計ポリシーがある場合、各集計ポリシーは独立して評価され、場合によっては繰り延べされます。異なるクエリレベルで異なるポリシーが適用される場合、予期しない結果が発生する可能性があるため、1つのテーブルに複数の集計ポリシーがある場合はクエリを設計する際に注意が必要です。

例えば、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、entity key = (user_id)

• vendor_policy: min_group_size = 2、entity key = (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 の最小グループサイズに違反し、3人の異なる顧客が「高額」に属していても、内側のクエリはNULLを返します。