开放湖仓中跨引擎与目录的统一治理

在我们之前的文章中，我们展示了开放表格式、开放 API 和统一治理如何结合起来， 完成开放湖仓愿景。我们还介绍了 跨引擎基于属性的访问控制，它允许在 Unity Catalog 中定义的策略在外部引擎访问受治理数据时得到一致执行。

如今，这一愿景正开始公开实现。Apache Iceberg™ 社区最近推进了 Iceberg REST Catalog 的两项重要新增内容：读取限制和目录标签。它们共同应对两个不同的挑战：将执行委托给外部引擎，以及使治理上下文可跨目录移植。

在本文中，我们将深入探讨规范中的这两项新增内容：它们如何工作、它们应对的关键挑战、未来的创新机会，以及何时使用它们。

读取限制：标准化委托执行

读取限制解决了一个常见的引擎到目录场景：一个组织在一个目录中治理数据，并希望从各种引擎或工具中查询它。

对于任何受治理的查询，必须发生三件事：

1. 目录接收请求身份和相关上下文，例如主体、组、角色，甚至诸如“区域”之类的身份属性
2. 它评估策略以决定用户是否可以读取该表，以及应用哪些行过滤器或列掩码。
3. 受信任的计算层在读取数据时执行该决定。

当从引擎访问数据时，这些职责可以通过两种方式划分。

在集中式执行中，所有三个步骤都保留在目录的环境中。例如，Databricks 通过透明地将查询路由通过安全过滤队列，在专用计算上实现细粒度访问控制。而 Unity Catalog 的跨引擎 ABAC功能通过将过滤队列置于 Iceberg REST 目录扫描/计划 API 之后，将这种治理扩展到其他引擎，以便在外部引擎（如 Spark1 或 DuckDB）处理结果之前对数据进行净化。

在委托执行中，目录接收请求身份并评估策略，然后将结果行和列限制返回给它信任执行这些限制的引擎。在这里，信任意味着目录可以依赖引擎来执行限制并防止用户绕过它们。当用户控制运行时，诸如 Spark 和 DuckDB 之类的引擎是不受信任的，因为这些用户可以执行任意代码或直接访问底层数据。安全配置的 Trino 部署是受信任引擎的一个例子，因为它为行过滤器和列掩码提供原生执行。

委托执行需要目录和引擎之间的共同契约。Iceberg 社区采用了读取限制来提供该契约。

读取限制如何工作

当读取者通过 Iceberg REST Catalog 加载表时，目录会为请求主体和请求上下文评估适用的策略。它可以返回所需的列投影操作和行过滤器表达式，受信任的引擎在读取表时必须应用这些限制。

有两个设计决策对于理解该提案当前的范围很重要。

首先，引擎不会收到管理员所定义的策略。相反，它收到的是针对特定主体的结果，表示为它必须应用的过滤或掩码指令。这在引擎和目录之间创建了一个共同的执行契约。初始规范定义了一个有界词汇表：九种预定义的列投影操作和标准化的行过滤器表达式，例如比较或集合成员资格。许多现实世界的企业策略依赖于子查询、查找表或自定义 UDF，这些无法在读取限制词汇表中表达。这有一个重要含义：只有当目录能够将其结果归约为标准定义的词汇表时，策略才能被表示，否则你就会失去策略语义。

其次，规范定义了受信任引擎必须执行什么，但没有定义目录如何建立这种信任。来自客户端的声明是不够的，因此系统管理员和实现必须使用适合其环境的安全机制。Iceberg 社区的讨论考虑了诸如 mTLS 和 OAuth 之类的机制，但信任最终仍处于协议之外（Iceberg 社区讨论）。

读取限制最适合直接引擎到目录访问的场景，其中源目录的策略简单，并且受信任的引擎可以执行由此产生的决定。仍有许多实现问题，例如引擎如何安全地传播最终用户的身份和属性，目录如何区分用户与代表用户行事的引擎，以及凭证如何绑定到其预期接收者。随着实现的出现，我们很兴奋能与 Iceberg 社区合作，共同解决这些挑战并推动标准演进。

目录标签：使治理上下文可移植

目录标签解决的是另一个场景：跨联合目录的治理。

许多企业现在通过联合和开放 API 连接多个目录，例如 Unity Catalog、Snowflake、AWS Lake Formation 和 Google Cloud Knowledge Catalog。这比引擎到目录集成更复杂，因为每个目录通过不同的身份模型、策略语言和语义为自己的用户、应用程序和引擎提供服务。

任何在企业规模上运作的统一治理解决方案都必须：

• 保持策略表达力。客户必须能够定义复杂的规则，包括基于属性的策略和复杂子查询，并在异构系统中一致地执行它们。
• 提供清晰的审计能力和问责制。每个目录必须能够独立证明合规性，而无需管理员跨多个系统核对审计跟踪。
• 在不将另一个目录服务置于关键路径的情况下实现扩展。Catalog A 中感知权限的发现不应为每个用户和资产都调用 Catalog B。例如，Unity Catalog 中的大多数用户体验都是感知权限的，而加载目录浏览器或提供输入提示搜索，否则可能需要对每个用户做出成千上万的逐项决策，这些决策难以缓存，这会导致用户体验缓慢，并将性能和可用性绑定到另一个服务上。

最近被 Iceberg 社区采用的目录标签，是迈向这一愿景的第一步。标签允许目录通过 Open API 在表和列级别交换轻量级键值元数据。标签可以指示某个字段包含 PII、将数据集与业务域关联，或为 AI 模型提供语义提示。由于该提案是通用的，标签可以支持访问控制之外的许多用例，包括发现、所有权、成本归因、AI 上下文和数据质量。

目录标签如何工作

当消费方目录通过目录联合从生产方目录加载表时，生产方目录会返回表和列级别的标签。

随后，消费方目录会将标签映射到自己的分类、属性或原生标签模型中。然后，它使用自己的原生身份和策略来评估访问，并在自己的运行时内执行控制。例如，如果生产方目录将 ssn 列标记为 pii=ssn，消费方目录可以应用基于标签的策略，对该列进行掩码处理。

由于策略执行仍在本地进行，消费方目录保留了其原生策略的表达能力，并避免为每次访问决策调用生产方目录。每个目录还独立维护自己的执行记录和审计跟踪。

值得记住的是，标签是不透明的键值对。该标准没有定义共享语义或稳定标识符，标签的血缘也不会超出源目录。消费方目录只接收到解析后的键和值，而不知道标签是用于发现、访问控制、成本归因还是其他目的。因此，标签使元数据可移植，但不使其含义可移植；企业仍然需要共享约定或显式映射，才能一致地解释标签。

目录标签最适合异构系统之间联合的目录到目录场景，在这种场景中，消费方目录拥有自己的治理系统，需要可复用的上下文，而不是为每个用户和请求单独做出访问决策。

目录标签是迈向开放策略交换长期愿景的一步。在这个世界中，受信任的目录通过开放 API 交换治理上下文，并最终交换策略定义，而每个平台使用其原生身份模型和运行时来评估和执行控制。核心思想是，治理和业务上下文，就像表元数据一样，应该通过 Iceberg REST Catalog API 保持开放和可移植。

选择正确的模型

正确的模型取决于目标：对不受信任的引擎进行集中式执行，对受信任的引擎进行读取限制，而当目标是另一个拥有自己治理系统的目录时，目录标签则作为开放策略交换的基础。

接下来是什么

读取限制和目录标签为跨平台治理解决了两个不同且重要的问题。读取限制为目录提供了一种标准方式，将强制执行委托给受信任的引擎。目录标签使治理和业务上下文能够像你的数据一样跨目录可移植。结合通过 跨引擎 ABAC 实现的集中式强制执行，这些为企业提供了一组实用选项，以便在引擎和目录之间一致地治理数据。

祝贺 Apache Iceberg 社区采纳这两项提案。虽然还有更多工作要做，但这是一个重要的里程碑。我们很高兴看到更多生态系统采用这些基础构建块，并继续与社区合作，使开放湖仓上的统一治理成为现实。

1Apache Spark 自身的安全指南指出，用户提交的代码在运行时对其行为没有限制，并让用户控制分配给其应用程序的资源。Spark 扩展可以实现读取限制，但只有当管理员控制运行时并消除所有绕过强制执行的路径时，该部署才符合受信任的条件，因为它缺少表级访问控制 API，更不用说细粒度访问控制 API 了（Iceberg 社区讨论）。