聚合策略¶

限制¶

• 如果查询使用显式分组结构，则必须是 GROUP BY 子句。查询不能使用 GROUP BY ROLLUP、GROUP BY CUBE 或 GROUP BY GROUPING SETS 等相关结构。

• 当其中一个查询作用于聚合约束的表时，大多数 集合运算符 不受支持。作为例外，UNION ALL 受支持，但每个结果组都必须达到要查询的聚合约束表的最小组大小（有关详细信息，请参阅 查询要求）。

• 如果聚合约束表的某列受 投影策略 保护，则对该表的查询不能将此列用作 COUNT 函数的实参。

• 在对聚合约束的表或视图的查询中，不允许使用 递归 CTEs。

• 在对聚合约束的表或视图的查询中，不允许使用 窗口函数。

• 如果引用符合聚合策略要求的查询部分，或者从该部分进行引用，则对聚合约束表的查询不能使用 相关子查询 或 横向联接。以下示例说明了禁止的查询类型。

  示例 1

  假设 protected_table 受聚合约束，则不允许进行以下查询，因为聚合数据的查询部分在子查询外部引用了该查询的另一部分：

  SELECT c1, c2
  FROM open_table
  WHERE c1 = (SELECT x FROM protected_table WHERE y = open_table.c2);
  

  Copy

  示例 2

  假设 protected_table 受聚合约束，则不允许进行以下查询，因为子查询引用了聚合数据的查询部分（该部分在子查询外部）：

  SELECT
    SUM(SELECT COUNT(*) FROM open_table ot WHERE pt.id = ot.id)
  FROM protected_table pt;
  

  Copy

注意事项¶

在使用聚合策略保护敏感数据时，请考虑以下事项：

• 聚合策略保护单个记录的数据，而不是实体的数据。如果数据集包含属于同一实体的多个记录，聚合策略只会保护与该实体相关的特定记录的隐私，而不会保护整个实体的隐私。

• 虽然聚合策略限制了对单个记录的访问，但它们不能保证恶意行为者不会使用特意设计的查询从聚合约束的表中获取可能很敏感的数据。只要尝试足够多次查询，恶意行为者就有可能设法满足聚合要求，从而确定某一行中的值。聚合策略最适合用于已有一定信任度的合作伙伴和客户。此外，提供商应警惕可能存在的数据滥用（例如，查看提供商列表的访问历史记录）。

从主体调用内部函数¶

聚合策略的主体使用两个内部函数来定义策略的约束：NO_AGGREGATION_CONSTRAINT 和 AGGREGATION_CONSTRAINT。当主体的条件调用这两个函数之一时，函数的返回值决定了必须如何构建对聚合约束的表或视图进行的查询，以便返回结果。

NO_AGGREGATION_CONSTRAINT

当策略主体从此函数返回值时，查询可以不受限制地从聚合约束的表或视图中返回数据。例如，当管理员需要从聚合约束的表或视图中获取未聚合的结果时，策略主体可以调用此函数。

在无实参的情况下调用 NO_AGGREGATION_CONSTRAINT。

AGGREGATION_CONSTRAINT

当策略主体从此函数返回值时，查询必须聚合数据才能返回结果。使用 MIN_GROUP_SIZE 实参指定每个聚合组中必须包含多少个记录。

AGGREGATION_CONSTRAINT 函数的语法是：

AGGREGATION_CONSTRAINT ( MIN_GROUP_SIZE => <integer_expression> )

Copy

其中 integer_expression 解析为 策略的最小组大小。

将 1 和 0 作为实参传递给函数是有区别的。两者都需要聚合结果。

• 传递 1 还要求每个聚合组至少包含一个来自聚合约束表的记录。因此，对于外部联接，来自聚合约束表的至少一个记录必须匹配来自未受保护表的记录。

• 传递 0 允许查询返回完全由另一个表中的记录组成的组。因此，对于聚合约束表和未受保护表之间的外部联接，组可以由未受保护表中不匹配聚合约束表中任何记录的记录组成。

策略示例¶

固定的最小组大小

最简单的聚合策略直接调用 AGGREGATION_CONSTRAINT 函数，并定义一个恒定的最小组大小，此大小应用于对表的所有查询。例如，以下命令创建最小组大小为 5 的聚合策略：

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

Copy

条件策略

策略管理员可以定义聚合策略的 SQL 表达式，以便不同的查询根据执行查询的用户角色等因素有不同的限制。这种策略可以允许一个用户不受限制地查询表，同时要求其他人聚合结果。

例如，以下聚合策略向具有 ADMIN 角色的用户授予对表的无限制访问权限，同时要求所有其他查询将数据聚合到包含至少 5 行的组中。

CREATE AGGREGATION POLICY my_agg_policy
  AS () RETURNS AGGREGATION_CONSTRAINT ->
    CASE
      WHEN CURRENT_ROLE() = 'ADMIN'
        THEN NO_AGGREGATION_CONSTRAINT()
      ELSE AGGREGATION_CONSTRAINT(MIN_GROUP_SIZE => 5)
    END;

Copy

小技巧

在条件策略中使用上下文函数（如 CURRENT_ROLE）时，可以使用以下策略：

• 上下文函数返回字符串，因此使用它们进行比较时区分大小写。如果想进行不区分大小写的比较，可以使用 LOWER 将字符串转换为全部小写。

• 当上下文函数返回某个值时，POLICY_CONTEXT 函数可以帮助您评估策略正文是否返回正确的值。POLICY_CONTEXT 函数根据一个或多个上下文函数的指定值模拟查询结果。

替换聚合策略¶

要替换聚合策略，推荐的方法是在单个命令中使用 FORCE 参数分离现有聚合策略并分配新策略。这使您能够以原子方式替换旧策略，而不会留下任何保护漏洞。

例如，要将新的聚合策略分配给已受聚合约束的表，请执行：

ALTER TABLE privacy SET AGGREGATION POLICY agg_policy_2 FORCE;

您也可以在一条语句 (...UNSET AGGREGATION POLICY) 中从表或视图中分离聚合策略，然后在另一条语句 (...SET AGGREGATION POLICY <name>) 中设置表或视图的新策略。如果选择此方法，在分离一个策略和分配另一个策略之间，表不受聚合策略的保护。在此期间，查询可能会访问敏感数据。

发现聚合策略¶

您可以使用 AGGREGATION_POLICIES 在共享的 Account Usage 架构中查看 SNOWFLAKE 数据库。此视图是 Snowflake 账户中所有聚合策略的 目录。例如：

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.AGGREGATION_POLICIES
ORDER BY POLICY_NAME;

Copy

识别聚合策略引用¶

POLICY_REFERENCES Information Schema 表函数可以识别聚合策略引用。有两种不同的语法选项：

1. 为在其上设置了指定聚合策略的每个对象（即表或视图）返回一行：

   USE DATABASE my_db;
   USE SCHEMA information_schema;
   SELECT policy_name,
          policy_kind,
          ref_entity_name,
          ref_entity_domain,
          ref_column_name,
          ref_arg_column_names,
          policy_status
   FROM TABLE(information_schema.policy_references(policy_name => 'my_db.my_schema.aggpolicy'));
   

   Copy

2. 为分配给名为 my_table 的表的每个策略返回一行：

   USE DATABASE my_db;
   USE SCHEMA information_schema;
   SELECT policy_name,
          policy_kind,
          ref_entity_name,
          ref_entity_domain,
          ref_column_name,
          ref_arg_column_names,
          policy_status
   FROM TABLE(information_schema.policy_references(ref_entity_name => 'my_db.my_schema.my_table', ref_entity_domain => 'table'));
   

   Copy

其他策略¶

本部分介绍聚合策略如何与其他策略交互，包括 掩码策略、行访问策略 和 投影策略。

您可以将其他策略附加到聚合约束表。对表的查询必须满足所有策略的要求才能成功。

如果将行访问策略分配给聚合约束表，则在计算聚合的结果时，不会包括基于行访问策略从查询结果中排除的行。

掩码策略、行访问策略或投影策略的主体不能引用聚合约束表（包括其列）。同样，另一策略的主体不能包含引用聚合约束表的 UDF。

视图和物化视图¶

您可以向视图和物化视图分配聚合策略。将聚合策略应用于视图时，基础表不会受聚合约束。用户仍然可以不受限制地查询此基表。

为了避免暴露敏感数据的可能性，所有聚合约束视图都被视为 安全视图 （即使它们不是）。

是否可以从聚合约束表创建视图取决于视图的类型：

• 可以从一个或多个聚合约束表创建常规视图，但是，对该视图的查询必须以符合这些基表限制的方式聚合数据。

• 您不能基于聚合约束的表或视图创建物化视图，也不能将聚合策略分配给物化视图所基于的表或视图。

克隆对象¶

以下方法有助于保护数据，防止拥有 SELECT 权限的用户访问存储在克隆数据库或架构中的克隆表或视图：

• 不支持克隆单个聚合策略对象。

• 克隆数据库会导致克隆数据库内的所有聚合策略。

• 克隆架构会导致克隆该架构中的所有聚合策略。

• 克隆的表会映射到与源表相同的聚合策略。

  • 当表在其父架构克隆的上下文中进行克隆时，如果源表引用了同一父架构中的聚合策略（即本地引用），则克隆的表将引用克隆的聚合策略。

  • 如果源表引用了不同架构中的聚合策略（即外部引用），则克隆的表会保留外部引用。

有关更多信息，请参阅 CREATE <object> ... CLONE。

复制¶

可以使用数据库复制和复制组来复制聚合策略及其分配。

对于 数据库复制，如果满足以下任一条件，则复制操作会失败：

• 主数据库位于企业账户（或更高版本）中，包含策略，但批准复制的一个或多个账户的版本较低。

• 主数据库中包含的表或视图具有对其他数据库中的聚合策略的 悬空引用。

在 复制组 中复制多个数据库时，可避免数据库复制的悬空引用行为。

聚合策略权限¶

Snowflake 支持聚合策略对象的以下权限。

请注意，对架构中的对象进行操作还需要对父数据库和架构具有 USAGE 权限。

有关详细信息，请参阅 DDL 命令、操作和权限总结 （本主题内容）。

聚合策略 DDL 引用¶

Snowflake 支持通过以下 DDL 创建和管理聚合策略。

• CREATE AGGREGATION POLICY

• ALTER AGGREGATION POLICY

• DESCRIBE AGGREGATION POLICY

• DROP AGGREGATION POLICY

• SHOW AGGREGATION POLICIES

DDL 命令、操作和权限总结¶

下表总结了聚合策略权限和 DDL 操作之间的关系。

请注意，对架构中的对象进行操作还需要对父数据库和架构具有 USAGE 权限。

Snowflake 支持不同的权限，以创建和设置对象的聚合策略。

1. 对于集中式聚合策略管理方法，即 aggregation_policy_admin 自定义角色在 所有 表上创建和设置聚合策略时采用的方法，需要以下权限：

   USE ROLE securityadmin;
   GRANT USAGE ON DATABASE mydb TO ROLE agg_policy_admin;
   GRANT USAGE ON SCHEMA mydb.schema TO ROLE proj_policy_admin;
   GRANT CREATE AGGREGATION POLICY ON SCHEMA mydb.schema TO ROLE aggregation_policy_admin;
   GRANT APPLY ON AGGREGATION POLICY ON ACCOUNT TO ROLE aggregation_policy_admin;
   

   Copy

2. 在混合管理方法中，单个角色具有 CREATE AGGREGATION POLICY 权限，以确保聚合策略的命名一致，并且各个团队或角色具有特定聚合策略的 APPLY 权限。

   例如，可以向自定义角色 finance_role 授予权限，以在该角色拥有的表和视图（即该角色具有表或视图的 OWNERSHIP 权限）上设置聚合策略 cost_center：

   USE ROLE securityadmin;
   GRANT CREATE AGGREGATION POLICY ON SCHEMA mydb.schema TO ROLE aggregation_policy_admin;
   GRANT APPLY ON AGGREGATION POLICY cost_center TO ROLE finance_role;
   

   Copy