通过聚合策略实施实体级隐私¶

不 具有实体级隐私的聚合策略¶

默认情况下，聚合策略要求分析师运行聚合数据的查询，而不是检索单个行，从而实现 行级隐私。然而，当在多个行中（例如，在包含事务数据的表中）发现某个实体的属性时，行级隐私并不能阻止查询暴露这些属性。

例如，假设流媒体服务 ActonViz 拥有的事务表中包含每个观众在观看节目时的电子邮件地址 (user_id) 和家庭 (household_id)。

ActonViz 可以使用聚合策略来强制广告商将数据聚合到至少包含 2 条记录的组中。这样可防止广告商从单个记录中检索数据（行级隐私）。如果每个观众和家庭在表中只出现一次，那就足以保护他们的隐私。

然而，广告商的查询仍然可以了解有关观众及其家庭的信息。一个查询可以创建一个完全由家庭 12345 的记录组成的组，或者更糟糕的是，一个完全由观众 dave_sr 的记录组成的组。在这两种情况下，组中的记录数量将满足 ActonViz 设定的要求（每组至少 2 条记录）。

具有 实体级隐私的聚合策略¶

为了实现实体级隐私，Snowflake 允许您在将聚合策略分配给表或视图时指定一个或多个实体键。 在定义实体键之后，对聚合约束表或视图的查询返回的组必须至少包含指定数量的 实体，而不仅仅是指定数量的 行。

在前面的示例中，假设 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)。通过延迟执行机制，可以实现如下示例所示的效果。若没有延迟执行机制，内层查询将返回 NULL，因为每个组仅包含一个 (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;

多策略延迟执行¶

如果一个表包含多个聚合策略，每个聚合策略都将独立评估并可能延迟执行。当您在一个表上设置了多个聚合策略时，请谨慎设计查询语句，因为不同策略在不同查询层级应用可能会导致意外结果。

例如，在包含两个独立聚合策略的表中，若尝试使用嵌套查询将用户分类为高消费和低消费群体，您可能会遇到以下问题：

表 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，这违反了 vendor_policy 的最小组大小要求，因此即使有三个不同的客户属于“高消费”桶，内层查询仍将返回 NULL。