在 Databricks 上的 Unity Catalog 数据治理——访问控制与权限模型在第 1 章里，我们介绍了湖仓

特权越多，机会越多；机会越多，责任越大。
——诺姆·乔姆斯基

在第 1 章里，我们介绍了湖仓范式，并说明 Databricks 平台如何将数据存放在云对象存储中，并提供用于高效查询和 ACID 属性的优化层。第 3 章我们讨论了身份管理的概念，并简单触及了访问管理。本章将阐述 Unity Catalog 如何保护数据和 AI 资产、各种访问控制机制与权限模型，以及如何设计可扩展的数据架构。我们也会讨论不同的治理模型，以及我们的虚构组织 Nexa Boutique 如何借助 Unity Catalog 以集中策略实现联邦式治理模型。

访问管理

第 3 章简要提到工作区与 Unity Catalog 可保护对象（securables）。工作区级可保护对象的访问控制在工作区层面生效；Unity Catalog 可保护对象的访问控制在 Unity Catalog 元存储层面生效，如图 5-1 所示。

图 5-1. Databricks 工作区与 Unity Catalog 可保护对象的访问控制

从访问管理角度看，你可以把 Databricks 工作区视为“项目层 + 计算层”的组合。工作区级可保护对象（如 notebooks、queries、jobs、dashboards、MLflow 实验等）支撑你构建项目资产，构成“项目层”。集群、SQL 仓库、池、集群策略、模型服务端点、向量检索端点等为你的工作负载提供算力，构成“计算层”。Unity Catalog 负责“数据层”，它主要控制存储在云对象存储中的数据与 AI 资产的访问。你也可以连接其他数据库、数据仓库与数据目录，并在通过 Databricks 访问这些数据存储时控制其中资产的访问。图 5-2 展示了 Databricks 工作区、Unity Catalog 与数据层的定位关系。

图 5-2. Databricks 工作区、Unity Catalog 与数据层的定位

举个简单例子：一位分析师要在 Databricks 查询一张表。TA 先登录拥有访问权限的 Databricks 工作区。登录后，TA 打开 Notebook 或查询编辑器编写 SQL，然后附加一个计算实例（集群或 SQL 仓库）来运行查询。以上这些对象都属于工作区级别，因此分析师必须具备创建或使用它们的权限。至于访问目标表的权限，则在 Unity Catalog 元存储层面授予。图 5-3 说明了这一用户旅程。

图 5-3. 分析师在 Databricks 查询表的用户旅程

需要注意的一点是：分析师并不需要知道数据实际存在哪里，也不需要知道 Databricks 运行在哪个云上，甚至无需了解 Unity Catalog 这个术语。这些细节都可以被抽象掉。分析师只需要知道如何进入工作区并用它来查询表。此外，如果分析师使用 Power BI 这类 BI 工具、只想从 Databricks 获取数据，那么只要 BI 到 Databricks 的连接配置妥当、管理员授予了相应权限，分析师甚至不必了解 Databricks。本书第 9 章将介绍不同的 Databricks 数据与 AI 资产访问方式。

“特权（privilege）” vs “权限（permission）”
特权是授予主体（用户/组/服务主体）的许可与能力，使其可在可保护对象上执行具体动作。例如：给用户 X 授予某表的 SELECT，给用户 Y 在某个 schema 上授予 CREATE TABLE。特权与“主体”关联。
权限指可以对哪些可保护对象（如表、schema）执行哪些操作（如读、写）。权限与“可保护对象”关联。
在本书中，我们有时将“特权”和“权限”交替使用。

访问控制

管理资源与资产访问的机制有多种。你可能熟悉基于角色的访问控制（RBAC）：这是以角色为中心的机制，把权限关联到角色，再把角色分配给主体。所谓“基于角色”，意味着根据你在组织内的角色授予权限。主流公有云、Snowflake、Starburst 等云数据平台以及 Oracle、Teradata 等本地方案都提供 RBAC。

Databricks 主要提供访问控制列表（ACL）：将允许哪些主体访问资源或资产的权限列成清单。ACL 是以用户/身份为中心的。而且，对 Databricks 可保护对象的权限需要在 Databricks 平台内定义，不能在平台外部（如在身份提供商）定义工作区或 Unity Catalog 的 ACL。

虽然你可以把权限授予到个人用户，但最佳实践是授予到“组”。通过定义“与岗位/画像（persona）对应的组”，并把相关权限赋给这些组，你就能在 Databricks 中模拟 RBAC。例如，创建名为 data_engineer 的组，表示该组成员的职位角色。把使用集群、读写一组表等必要特权都赋给该组。新人入组即可获得相应权限；有人离开团队则从组里移除。

你应该已经意识到：工作区层（开发与计算资源）需要的权限，与 Unity Catalog 元存储层（数据与 AI 资产）需要的权限不同。因此必须分别理解二者的访问控制。下面先讲工作区可保护对象的访问控制，再讲 Unity Catalog 的访问控制。

工作区访问控制

工作区层的访问控制，主要是给工作区可保护对象配置 ACL。工作区里有三类用户：

Admin（管理员）
拥有对所有工作区可保护对象的最高特权 CAN MANAGE。管理员可以把任意工作区可保护对象的权限授予工作区内任意主体。
Owner（所有者）
可保护对象的所有者，默认是其创建者。创建者默认获得 CAN MANAGE，并可将权限授予工作区内任意主体。
User（普通用户）
默认对任何可保护对象都没有访问权。需要被授予相应权限才能使用某个对象；或者在具备相应创建特权时，可以创建新的对象。

注意
“权能（Entitlements）”定义主体如何与工作区交互，它们可以限制工作区用户创建计算资源的能力。

在所有工作区可保护对象上，最高特权是 CAN MANAGE。除此之外，不同对象有各自的特权集。例如集群有 CAN ATTACH TO、CAN RESTART，Notebook 有 CAN READ、CAN RUN、CAN EDIT 等。

管理工作区可保护对象的最佳方式，是定义与画像（persona）对应的组并将权限授予这些组。以“分析师”画像为例：分析师希望在 Databricks 工作区内以及通过 BI 工具访问/分析数据，通常需要如下工作区层面的权限：

访问 Databricks 工作区：能登录工作区。
对个人目录的 CAN MANAGE：能在工作区的个人目录下创建 Notebook、Query、Dashboard 或 Genie 空间。
对某个集群的 CAN ATTACH TO 或对某个 SQL 仓库的 CAN USE：能附加计算实例以运行查询。

此外，分析师还可能需要访问其他人创建的工作区对象，具体取决于对象类型与所需的访问级别。关键在于：分析师要使用某项功能，必须对涉及的所有对象都拥有权限。比如被授予某个 Dashboard 的访问权，还必须能使用其背后的计算资源（SQL 仓库）以及底层表/视图。

实操中，你先创建一个带有 data_analyst 字样的组（可加前/后缀标识业务单元或项目），把分析师加入组；再创建所需资源（集群、SQL 仓库等）；最后把必要权限授予该组。图 5-4 展示了这个场景涉及的可保护对象与 ACL。

图 5-4. 分析师画像所需权限的示例

同理，你可以为“数据工程师”“机器学习/AI 工程师”等其他画像定义组，并授予相应权限。

Unity Catalog 访问控制

Unity Catalog 的可保护对象（securables）采用三级命名空间层级结构。所有对象的根是 metastore；在其下可以创建 catalog（目录，层级 1）；在目录下可以创建 schema（也称为 database，层级 2）；schema 中包含所有数据与 AI 资产，如表、视图、模型等。见图 5-5（Unity Catalog 对象层级）。

图 5-5. Unity Catalog 对象层级

如你所见，用于存放非结构化数据的 volume，以及构成 AI 资产的 model 与 function，与表和视图处于并列位置。它们的访问控制、权限模型和共享机制在各资产间保持一致。图 5-6 展示了 Nexa Boutique 零售销售领域的一组数据与 AI 资产，已编目至某个 metastore 中。

图 5-6. 编目在 catalog/schema 下的零售销售数据与 AI 资产示例

在上例中，若要访问 transactions 与 customers 两张表，需要连同其父级的 catalog（data_products）与 schema（sales）进行引用。SQL 如下：

SELECT * FROM data_products.sales.transactions;
SELECT * FROM data_products.sales.customers;

Unity Catalog 的可保护对象及其对应权限在 metastore 层定义。metastore 是抽象的元数据层，主要存储以下元数据：

结构性元数据：对象层级、模式定义、数据类型、数据源位置等
发现性元数据：用于发现与理解资产的标签、注释、描述等
访问控制元数据：ACL、适用的行列级过滤与脱敏函数、以及治理数据与 AI 资产访问的其他权限
血缘元数据：描述资产之间关系与依赖、追踪其全生命周期的演进
审计元数据：谁在何时执行了什么操作，支撑安全与合规

权限模型

前文提到，尽管数据与 AI 资产存放在对象存储中，作为用户你无需了解其物理位置或存取方式，因为 Unity Catalog 通过数据访问配置对象来抽象这些细节——即 storage credentials 与 external locations：

Storage credentials（存储凭据）
Unity Catalog 的包装对象，授权 Unity Catalog 服务访问相应云存储对象，例如：
- 具有某 S3 桶读/写权限的 IAM 角色（AWS）
- 在 ADLS Gen2 账号上具备 Storage Blob Data Contributor 角色的 托管身份（MI） 或 服务主体（SP） （Azure）
- 在 GCS 桶上拥有 STORAGE LEGACY BUCKET READER 与 STORAGE OBJECT ADMIN 权限的 服务账号（GCP）
External locations（外部位置）
将存储凭据映射到特定云存储 URI 的包装对象。单个存储凭据可关联多个外部位置，这些位置可指向同一云存储对象的不同路径。

在对象层级上，storage credentials 与 external locations 直接创建在 metastore 下。你可以像对待 catalog 层级下的可保护对象那样，为这些对象向主体授予特权。图 5-7 展示了它们在 UC 对象层级中的定位。

图 5-7. 存储凭据与外部位置在 Unity Catalog 对象层级中的定位

由于存取数据需要先有这些配置，你通常先创建存储凭据与外部位置，再创建其他 UC 可保护对象。换言之，先设计存储布局并由 UC 配置访问，再设计 catalog 布局，并将存储凭据/外部位置映射到 catalog、schema、table 或 volume。第 5 章后文会讨论存储与目录布局。

类似工作区，我们也可将 UC 用户概括为三类：

Admin（管理员）
对应 metastore 的最高特权拥有者。可对任意 UC 可保护对象授予特权并变更所有权，面向任何“账户级主体”。
Owner（所有者）
UC 可保护对象的所有者，默认为创建者。对象创建者默认对该对象拥有全部特权，可为任意账户级主体授予特权或变更所有权。
User（普通用户）
账户用户默认无法访问任何可保护对象。需在具体对象上被授予相应特权，方可使用或创建对象。

UC 对象层级的每一层都有相应的特权集合。特权授予给主体，并沿层级向下继承。例如：若你在某个 catalog 上拥有 ALL PRIVILEGES，则你对该 catalog 内所有当前与未来对象也拥有 ALL PRIVILEGES。

只有在以下情形之一，你才能对某可保护对象授予特权：

你是 metastore admin；
你是该可保护对象的 owner；
你是该对象 父级对象 的 owner；
你对该对象拥有 MANAGE 特权；
你对该对象的父级拥有 MANAGE 特权。

仅当你拥有对象（及/或其父级）的所有权与/或 MANAGE 特权时，才可 DROP 该对象。这对 metastore admin 同样适用。但 metastore admin 可以先把对象所有权改为自己，或先授予自己 MANAGE，再执行 DROP。注意：ALL PRIVILEGES 不包含 MANAGE，而拥有 MANAGE 并不等于自动拥有 ALL PRIVILEGES。

非表格数据的访问控制

Nexa Boutique 的 ML/AI 工程师长期受困于无法妥善保护非表格训练数据集（如音视频文件）与 ML 模型：存哪儿、如何做版本管理、如何把模型与其训练数据集关联、以及更重要的——如何配置合适的访问控制而不打扰同事。很多工程师本应专注模型开发与微调，却被迫投入到应用开发、平台运维、安全与治理上。这也是他们非常认同“表格与非表格资产统一治理”的原因之一。类似经历在许多组织中都很常见。虽然 MLflow 等框架缓解了部分 ML 场景的问题，但安全与治理需求并未因此得到满足。

在 Unity Catalog 出现前，Databricks 自身也是如此：数据集与模型存放在工作区上下文，访问控制也只在工作区层面生效，跨工作区共享数据集与模型困难。非表格文件须存放于 DBFS（作为云对象存储接口的分布式文件系统），而 DBFS 不支持细粒度访问控制——只要能访问工作区，就能访问 DBFS 上任意文件。本质上，没有办法对非表格数据集与模型实施合规治理。

Unity Catalog 彻底改变了这一点。正如前文所述，你可以用 volume 存储非表格数据集；而 ML 模型在 UC 对象层级中有独立的 model 对象类型。Volume 是云对象存储位置的逻辑表示：它为某个云存储路径下的目录与文件建立编目，并向用户抽象位置与访问细节。Volume 与前述 external location 听起来相似——区别在于：external location 是底层的数据访问配置对象，而 volume 是其上的用户可见抽象。你需要先有 external location，随后才可据此创建 volume。

回到“Unity Catalog 访问控制”中的零售销售示例，你可以像这样通过 catalog 与 schema 引用来列出 report_extracts 这个 volume 中的文件：

LIST '/Volumes/data_products/sales/report_extracts/';

若要访问 volume 内容，你至少需要对该 volume 拥有 READ VOLUME 特权，并对其父级的 catalog 与 schema 拥有 USE CATALOG 与 USE SCHEMA 权限。你无需知道云存储上的物理路径，也无需拥有云存储层面的访问权。注意：一旦被授予某个 volume 的访问权，你将能访问该 volume 下所有目录与文件；目前不支持对 volume 内部的单个目录/文件做细粒度 ACL。

由于 volume 的本质是“受治的文件集合”，它能存放的内容非常灵活：不仅可放数据集，也可放库、配置文件、证书等。这意味着你可以将项目/团队资源（无论类型）隔离到特定的 catalog 结构中，并据此施加访问控制。

例如 Nexa 的库存优化项目 singularity：你可以创建同名 catalog，将结构化数据以表/视图形式存入该 catalog 下的各 schema，将非结构化数据（文件）、代码库、配置等放入 volume，将模型以 Unity Catalog model 形式保存。再创建项目专属的 IdP 组（如 singularity_engineers），并对该 catalog 及内部对象授予该组相应特权。如此，项目相关的数据与资产集中在一个“空间”里，发现性、可访问性与治理都更简单。

托管与非托管数据集

在 UC 中编目数据集时，需要决定是否让 Databricks托管其存放位置（适用于 tables 与 volumes 两类对象）。托管表仅支持 Delta 或 Apache Iceberg 格式。所谓“托管”，Databricks 会管理该数据集的部分方面（主要是存放路径与优化）。

务必注意：使用托管数据集（托管表/volume）并不意味着你放弃对数据的控制权，因为你可以选择其存放的“存储单元”（external location 背后的云存储路径）。即你仍完全掌控数据。所谓 UC “管理位置”，是指 UC 负责路径前缀组织，并要求用户通过逻辑命名（catalog.schema.table/volume）而非云 URI 来访问数据。换言之，使用托管表/volume 不会导致厂商锁定。

要创建托管或非托管的表与 volume，先要理解数据访问配置如何与 UC 可保护对象关联。正如前文，访问配置由 storage credentials 与 external locations 定义。你可以在 UC 层级的不同层面为对象指定存储位置（由外部位置承载）。见图 5-8：

创建 表或 volume 时，可显式指定 LOCATION（云存储路径）——此类对象称为 external table / external volume；
创建 schema 时，可为其指定存储位置——该 schema 下托管对象的内容将写入此位置；
创建 catalog 时，可为其指定存储位置——该 catalog 下托管对象默认写入该位置；
也可在 metastore 层设置存储位置，作为所有托管对象的默认存储根（若 catalog/schema 未指定）。

我们不建议在 metastore 层设置存储位置，因为这可能导致大量（甚至无意间产生的）托管资产被存入同一共享位置，并在规模化时触发云存储的某些限制。若不在 metastore 设定位置，则创建 catalog 时必须指定存储位置。

图 5-8. 在 UC 各层设定默认存储位置

简言之：external table/volume 直接绑定了存储路径；托管表与 volume 则使用“最近的父级”定义的存储位置。顺序为：

若 schema 层指定了存储位置，则使用它；
否则使用 catalog 层指定的位置；
若上述皆未指定，则使用 metastore 层的位置。

见图 5-9（各层对象关联的存储位置）。

图 5-9. UC 不同层级与可保护对象关联的存储位置

因此，关联在 metastore/catalog/schema 层的存储位置称为托管位置（managed locations） ，存于此的为托管数据集；external table 与 external volume 的内容为非托管数据集。二者可在同一 catalog/schema 下共存。删除托管表或 volume 时，其底层文件会在 30 天内由 Databricks 自动清理；删除 external table/volume 时，仅清理 UC 中的编目元数据，底层文件保留，需手工删除。

关于 External Locations 的注意事项

External location 属于 UC 的“数据访问配置”，既用于指定托管资产的存储根，也用于 external table/volume 的内容路径。名字里有“external”容易误导，以为只与 external 对象相关，其实并非如此。
同一路径不能被两个 external location 指向，换言之，不允许路径重叠。
为避免路径重叠，不要在 external location 的根目录直接创建 external 表/volume，而应在其子目录中创建。

托管表与 volume 的实际存放路径根据 UC 元数据自动组织，取决于存储根。例如：当存储根在 catalog 层时，托管表的路径结构为：

<CLOUD_STORAGE_URI>/<OPTIONAL_SUBPATH>/__unitystorage/catalogs/<CATALOG_ID>/tables/<TABLE_ID>

CLOUD_STORAGE_URI：云对象存储中的根路径与可选子路径
OPTIONAL_SUBPATH：可选的进一步子路径
CATALOG_ID：该 catalog 的 UUID
TABLE_ID：该表的 UUID

若存储根在 metastore 层，则托管表路径结构为：

<CLOUD_STORAGE_URI>/<METASTORE_ID>/tables/<TABLE_ID>

METASTORE_ID：metastore 的 UUID

之所以展示路径结构，是为了对比它与 external 表/volume 的内容路径区别。直接用文件路径访问托管数据集既不方便，也可能变动，且本就不被设计为这样使用。

托管 vs 非托管，如何选择？
很多人都会问。托管表有更少的维护开销（系统会自动做存储与性能优化）；而 external 表的内容路径更直观。在过去，如果需要在 Databricks 外以文件形式访问数据，external 常更合适。但现在你可以通过 Unity Catalog REST API 获取表的内容，无需直接取底层文件，因而托管表有了更明显的优势。第 9 章将介绍 UC REST API 与其他数据访问方式。只有在你必须使用 Delta/Iceberg 之外的格式时，external 表才是必要之选。

高级访问控制

自诞生以来，Unity Catalog 一直在快速、正确的方向上演进。越来越多的新特性被发布，使我们在基于 Unity Catalog 设计方案时，能够纳入更复杂的治理需求。我们把这些统称为高级访问控制——它们为核心访问控制机制增加了更多维度，也即为制定与执行访问控制策略提供了更多选项与灵活性。要成为一个完整的治理方案，Unity Catalog 在这一领域仍需要继续演进；就我们看来，这正在发生，而我们的挑战在于持续跟进最新进展与功能发布。下面聚焦当前可用且实用的特性，同时点到为止地提及一些几乎必然会出现的未来态与有助于你提前做架构设计的注意点。

将 Unity Catalog 可保护对象与工作区绑定

前文提到，Unity Catalog 的可保护对象存在于 metastore 层，并可通过与该 metastore 关联的任意 Databricks 工作区访问。你可以通过把 UC 可保护对象绑定到特定工作区来控制这一点。该绑定适用于 catalog、storage credentials、external locations。例如，当你把某个 catalog 绑定到某个工作区后，只有在该工作区内才能访问该 catalog。对于有此 catalog 访问权的普通用户来说，他们将无法再从其他工作区访问它。即便你是 metastore admin，在其他工作区的 Catalog explorer 中也只能看到灰显、不可访问的该 catalog。

将 catalog 与工作区绑定，是隔离项目或业务单元（BU/OU）资源的好方法。假设你有一组专用于某个 OU 的工作区，同时为该 OU 创建了一组用于存放数据与 AI 资产的 catalogs；把这些工作区与对应 catalogs 绑定，便可确保资产仅在该 OU 内可访问。你还可以按开发生命周期的环境层级做进一步限制——例如仅允许生产 catalog 在生产工作区访问。该特性既可防止跨 OU 的误访问，也能隔离环境层级，支持安全、干净的开发流程。

理论上隔离环境很好，但现实中常常需要在其他环境访问生产资产。比如分析师想对最新销量做临时分析，或 ML 工程师想训练预测某些产品需求的模型。在这类场景下，你需要让用户访问生产数据，但没必要让他们进入整个生产环境。这时只读绑定就派上用场了：将生产 catalog 以只读方式绑定到开发工作区，分析师或 ML 工程师即可在开发工作区读取所需数据，同时因为绑定为只读，他们无法向生产 catalog 写入，从而避免意外操作。

图 5-10 展示了一个工作区–catalog 绑定示例：生产 catalog 以读写方式绑定到生产工作区，并以只读方式绑定到开发工作区；开发 catalog 仅绑定到开发工作区。

细粒度访问控制（FGAC）

如果你在 S3 桶里有一个 CSV 文件，直接对文件施加访问控制，与把该 CSV 抽象成表再对表施加访问控制，有什么不同？答案取决于你要实施的控制粒度。若仅需控制对“整份 CSV”的访问，区别不大；但若要仅开放部分列或部分行，则必须走“表”这一抽象，因为文件层无法做到这种粒度。

Unity Catalog 支持对表的行级与列级访问控制。针对某个主体（principal），你可以规定其可见的行与列。这类能力统称为细粒度访问控制（FGAC） 。它在处理敏感数据（如 PII）或基于某些列值（如地区）做过滤的场景中尤为有用。

图 5-11 给出了一个示例：属于 HR 组的用户 Aly 可访问包含员工信息的整张表；而不属于 HR 组的用户 Bob 只能看到过滤后的部分行，且部分列被掩码。

Databricks Unity Catalog 允许你定义带有判定逻辑的函数，以决定某主体可访问哪些行和列。换言之，你编写用于行过滤或列掩码的函数，并把它应用到表上。我们尤为看重的一点是：这些过滤/掩码函数本身也是 UC 的可保护对象。你可以像管理表一样查看函数定义并控制其访问。图 5-12 展示了一个与目标表同 catalog/schema 下编目的行过滤函数示例。

需要注意：应用 FGAC 并不会对静态数据做加密或匿名化。它是在访问时动态发生的：当用户通过 Databricks 工作区中的集群或 SQL 仓库访问表时，行过滤与列掩码会在计算层被执行，然后再把结果返回给用户。也就是说，Databricks 的计算层在 FGAC 执行上起着关键作用。如果你通过 REST API 访问 UC 中的表（第 9 章详述 API 访问），因为不涉及 Databricks 计算，FGAC 不会被执行。图 5-13 展示了带行过滤或列掩码的查询生命周期：

用户提交查询；
计算与 UC 服务交互，UC 校验元数据与权限，返回路径/文件列表与下放的临时令牌；计算据此从云存储读取数据；
云存储返回数据至计算；
在计算层应用行过滤与列掩码函数；
将过滤后的结果返回给用户。

（注：该生命周期适用于标准/共享集群、SQL 仓库与 Serverless 计算。对于专用/指派集群，执行路径不同，会借助额外后台服务，本文不再展开。）

基于属性的访问控制（ABAC）

我们已经看到多种控制 UC 可保护对象访问的方法。它们对小型乃至一定规模的中型组织往往足够；但在大型组织、尤其是治理要求复杂的场景中，仅靠 UC 的核心访问控制与所有权模型可能不够易扩展。比如，表的所有者可以把访问权限授予任意 Databricks 用户（当然，接收者仍需对父级 catalog/schema 有 USE 权限才能最终访问）。有些组织希望限制数据与 AI 资产的共享，并以集中策略来强制这些限制。这类策略通常需要动态评估多种属性（用户角色、环境因素、资源敏感度等），以确定请求访问的用户是否被允许；并且这些策略应能在不同对象层级、跨多个可保护对象上统一生效，以实现可扩展性。

在医疗等高度敏感、强监管行业，这尤为典型：例如“护士只能在自己排班的时段访问分配到本病区的病人记录”；或“研究员只能在工作时间、使用公司受管设备访问经批准项目的研究数据”。ABAC（Attribute-Based Access Control，基于属性的访问控制）正是为此而生，公有云与如 Immuta 之类的治理产品均提供支持。

2014 年，NIST 发布《Guide to Attribute Based Access Control (ABAC) Definition and Considerations》，提出企业实施 ABAC 的方法论，核心包括三点：

属性（Attributes） ：描述主体、客体与环境的特征；
策略（Policies） ：控制访问决策的规则；
策略执行（Policy enforcement） ：以属性匹配策略并作出访问决策的过程。

Databricks 当前发布的 ABAC 能力，包括增强的标签（tagging）与可扩展的行/列级控制。其实现围绕三大概念：属性、策略与继承，与 NIST 的思路一致。属性来源于可保护对象与访问主体的上下文，以及环境/时间等因素；如主体身份、对象上的标签、访问时间等。策略利用这些属性动态控制访问；策略与可保护对象关联，并沿 UC 对象层级向下继承，与既有对象权限并行生效。

目前 Databricks ABAC 的两项主功能是：**治理型标签（Governed tags）**与 ABAC 策略。

治理型标签（Governed tags）

第 7 章会从“可发现性”的角度再谈标签。总体上，UC 的标签是自由文本的键值对，可赋给 UC 可保护对象。但若缺乏创建与应用规则，标签价值有限。要以集中策略来治理，就必须保证标签一致命名、规范取值、并能受控管理。治理型标签正是为此设计：管理员可以定义带标签策略的标签，约束其允许值，并控制哪些主体可管理标签定义、哪些主体可把该标签赋给 UC 对象。

治理型标签在账户级定义，对该账户下的所有工作区生效。你创建一个标签键，并定义零个或多个允许值。例如创建键 domain，允许值为 finance/sales/marketing 等；随后可把该标签应用到某个 UC 对象（如 catalog 或 table），并赋予其中一个允许值。你还可以通过授予 ASSIGN/MANAGE 权限，确定谁能分配与管理该标签。

有了治理型标签，便可用于数据分级、成本管理、资产发现等；它们也是在 Databricks 上实施 ABAC 的必要前提，并能启用可信自动化（因为标签取值受控、赋权主体受控）。引入治理型标签后，UC 中的标签分为三类（见图 5-14）：

发现型标签（Discovery tags） ：无策略的普通标签；
治理型标签（Governed tags） ：带标签策略；
系统标签（System tags） ：Databricks 预置的治理型标签。

ABAC 策略

前述的 FGAC 是逐表应用：若要对 100 张表的 email 列做掩码，你必须在每张表上应用一次，难以规模化；若组织要定义并强制执行集中策略，也很难落地。Databricks 的 ABAC 提供了另一种思路：你定义一个策略（policy） ，将其应用在 catalog/schema/table 上；策略按治理型标签匹配对象并生效。

应用在 catalog 或 schema 层的 ABAC 策略，会对所有符合条件的子对象生效。策略的匹配条件通过治理型标签描述：你先定义治理型标签并贴到 UC 对象（表、列等）上；然后定义 ABAC 策略并应用在 catalog/schema/table 上。当前支持的策略类型包括行过滤与列掩码。

一个行过滤/列掩码策略通常包括：

策略应用到的可保护对象（catalog/schema/table）；
适用的主体集合（用户/组/服务主体）；
不适用的主体（例外）；
行过滤或列掩码的 UDF；
需匹配某治理型标签的表集合；
需匹配某治理型标签的列集合。

一旦应用，ABAC 策略会自动对今后新出现且满足条件的对象生效。比如你在 data_products catalog 上定义“对带 Category=Confidential 的表中、所有带 Category=PII 的列做掩码，适用于全体用户，certified_admin 组除外”的策略；那么今后任何新表或新列，只要打上对应治理型标签，策略就会自动生效；已存在的对象若后来补上这些标签，也会被策略覆盖。也就是说，你可以通过打标签来控制策略的作用范围，而无需修改策略本身。这极大地方便了集中策略管理；并且策略可在 catalog/schema 层统一下沉，便于规模化治理。图 5-15 展示了应用在 data_products catalog 上的一条 ABAC 列掩码策略示例。

ABAC 策略的另一个好处是：你可以在同一张表上并行应用多条策略、用不同条件覆盖不同治理诉求。比如第一条策略：对标记为 PII 的列做匿名化，对全体用户生效，certified_admin 例外。后来又出现新诉求：对某些非 PII但仍需保密的列做匿名化，则可新建一组治理型标签，贴到目标表/列上，定义第二条策略对这些列生效（允许的例外组也可不同）。这样，同一张表同时存在两条独立维护的策略。注意：在撰写本书时，对同一列或同一“行范围”，一次只能生效一条列掩码或行过滤策略（在对象层级上不会叠加到同一列/同一行上）。

数据治理模型

听到“治理”这个词，我们往往会联想到“政府”。实际上，用国家治理来类比数据治理的若干方面很合适。以法国和德国为例：两国都是在欧洲乃至全球颇具影响力的民主国家，拥有健全的选举制度。乍看之下，它们同为富裕的现代西方民主国家，文化与宗教底蕴深厚，对本国语言也有强烈自豪感，似乎十分相似。但深入观察便会发现，它们在政治结构、治理方式与文化细节上差异显著。

法国的政治格局是半总统制，并延续了强中央集权传统；德国则实行联邦议会制，强调分权治理。在法国，高达约 80% 的公共支出发生在国家层面；而在德国，这一比例约 50% ，各州拥有宪法保障的权力。德国的市政当局（地方政府）承担了约 2/3 的公共投资；相对地，法国的市镇在资金上更多依赖首都巴黎。德国倡导合作式联邦主义的政策制定，而法国更接近垂直化权力结构。

再加入实行州（州/州级）与市镇高度自治的瑞士，其治理模式又是另一种样态。州与市镇拥有重大自治权（例如可自行设定税率）。许多全国性决策往往需要公民公投或州级同意（如新冠疫情应对）。

概括来说，这三邻国呈现三种治理模型：法国的集中式、瑞士的分散/分布式、德国的联邦式。这正好可类比组织内部可实施的数据治理模型。

集中式数据治理

集中式治理类似法国的自上而下模式：由一个中央权威（如 IT 部门或企业数据平台 CDP 团队）统一掌控政策、标准与决策。这通常带来组织内政策的统一性，并简化合规路径；但也容易使中央团队成为瓶颈，且对各业务域的特定需求弹性不足。高度受监管行业往往采用此模式，因为其首要目标是监管合规。

在 Unity Catalog 中实施集中式治理意味着：中央团队需要创建并管理直到对象层级最末端的所有 UC 可保护对象。换言之，Databricks 用户通常仅在 schema 内获得有限权限。在工作区层面，中央团队可以创建与下发工作区、以及集群、SQL 仓库等工作区对象，并授予各团队使用权限。

然而，要完全强制集中治理并不容易，因为平台的所有方面并非都可控。例如：用户在 UC 中创建一个可保护对象后，会自动获得其所有权，并可将其共享给其他用户。如果你的中央政策禁止未审批的资产共享，现阶段无法完全强制此类政策（即将到来的 ABAC 功能有望缓解部分集中政策执行的限制）。还有其他挑战：例如 DDL 与 DML 权限在 UC 中合并为 MODIFY；因此无法只允许插入而不允许修改表结构。如果你的政策需要“允许 DML、禁止 DDL”，目前也难以精确落实。

至于审计日志分析、特性开关管控等治理面，则可借助管理员角色进行集中管理，契合集中式治理。

分散式数据治理

分散式（去中心化）治理类似瑞士：权限分布于各自治实体，无中央层级对其统一约束。该模式最具灵活性，或许适合强调创新的科技初创公司；但由于缺乏中央权威，合规可能更难。若组织拥有自给自足、能妥善保障平台与资产安全的团队，分散模式也可成功。顾虑在于：缺乏中央监督与重复建设。组织结构通常仍具层级性：再扁平也会向上汇报，直至 CEO。因而在需要自上而下的数据战略时，缺乏集中监督会成为问题。

在 Unity Catalog 中，你可以在一定程度上实施分散式治理：在 metastore 层将多数权限下放给各团队，由其自行创建与管理可保护对象；各团队也可自建工作区并独立管理其工作区对象。但要达到完全分散仍不现实，因为仍存在中央管理员角色。Metastore admin 虽可选、可不设，但Account admin 仍是必须，且偶尔需要执行一些操作（尽管多数可自动化），如处理升级、在账户层开启新特性等。

联邦式数据治理

联邦式是集中与分散的混合：如德国，中央与地方之间权力平衡。某些政策（尤其是互操作与合规相关）由中央制定、地方执行；各实体/域在访问控制、数据质量、管道等方面保有自治。该模式可扩展性强，适合大型组织；可与数据网格（Data Mesh）等数据架构模式配合实施，既促进创新，也兼顾合规。这也是我们最推荐的模式。

Unity Catalog 最适合落地联邦式治理。与分散式相似，各实体可自行创建/管理 UC 可保护对象与 Databricks 工作区；中央团队则提供catalog 设计模板与工作区基线配置，制定安全最佳实践（如存储防火墙、数据外泄防护、敏感信息仅限认证员工访问等）。中央角色（metastore admin、account admin）在执行中央政策/指南上至关重要。中央团队还可通过系统表、信息架构（information schema）、血缘等实现全局监督（第 7 章详述），并制定互操作与数据共享标准，把实现细节下放给各实体。

当然，治理国家与治理数据毕竟不同。法国、德国、瑞士的治理结构为集中式、联邦式与分散式提供了形象比喻，但组织内部的数据治理面临的是不同的挑战与语境。某种国家层面的成功模式，并不必然意味着该模式就是组织层面数据治理的最佳解。每个组织都应基于自身的诉求、监管环境、组织文化与战略目标慎重选型。

下文将从联邦式数据治理的视角，讨论物理与逻辑存储布局的设计，以及数据共享。

数据存储与分发

当你开始使用 Unity Catalog 时，首先要做的一件事就是定义数据布局：也就是如何组织 catalog 与 schema，并整理你的数据与 AI 资产。它与在传统 RDBMS 或多数数据仓库上的做法不同。在 RDBMS 中，你只需关心逻辑数据布局，因为存储层被系统完全抽象掉；多数数据仓库也类似。因此，设计数据布局时，你通常只需要在逻辑层（定义数据库及其下的数据资产）上动手。

在 Databricks Unity Catalog 中，你还可以选择设计存储层布局。换言之，你可以自己挑选云对象存储单元（例如 S3 bucket）来存放数据与 AI 资产。但在实践中，往往已经存在需遵循的基础设施侧存储布局。对于每个对象存储单元，你都需要通过定义**存储凭据（storage credentials）与外部位置（external locations）**来配置数据访问。

为便于表述，我们把云存储层 + 数据访问配置对象统称为物理存储层；把catalog、schema 以及 schema 之下的其他可保护对象（securables）统称为逻辑存储层。见图 5-16。

图 5-16. Unity Catalog 的物理与逻辑存储层

如果你是从零开始使用 Databricks、准备设计数据布局，最好从逻辑存储层入手：先定义如何组织 catalog 与 schema，它会“自然映射”到一个物理存储层（稍后展开）。相反，如果你已经在用 Databricks、正要迁移到 Unity Catalog，那么你可能需要考虑现有数据布局——也就是云存储里的既有数据文件以及它们在 HMS 中的注册情况——以尽量减少迁移成本。

设计数据布局需要综合多方因素：组织结构与政策、业务域、数据来源与处理需求、以及数据消费模式。合理组织数据与 AI 资产能简化所有权模型，并通过减少数据搬运与重复，显著提升运维效率，同时也更易于执行集中式组织政策。尽可能多地考虑因素是好的，但不必追求“完美方案”。未来仍可调整或更新设计（只是会有额外成本）。下面给出一些指南与最佳实践，助你在设计阶段抢得先机。

Catalog 布局与命名

一个业务单元（BU）用一个 catalog？还是每个项目一个 catalog？或是仅按环境层级（开发/测试/生产）划分 catalog？一个 catalog 里能放多少 schema 与表？一开始会冒出不少问题。回想 RDBMS，我们有数据库以及其下的表与视图；数据库的作用是把相关的表与视图组织在一起。Unity Catalog 在此基础上又增加了一个层级，提供了更多编排空间，但核心理念相同：把相关资产分组。

如前所述，设计应反映多种因素（如组织结构与政策）。你可以按业务域、数据域、甚至项目来划分一个或一组 catalog。关键在于该单元的“体量”：数据规模、访问该 catalog 的用户数、访问模式等。不论选择何种单元，命名规范必须统一。

接下来看组织内最常见的 catalog 布局模式。本文用组织单元（OU）泛指在组织内足够独立且规模足以配备专属 catalog的单元（可指项目、团队、数据域、业务域或业务单元）。本章聚焦单一 Unity Catalog metastore 内的数据存储与分发；第 8 章将讨论跨 metastore 的数据分发；治理上采用联邦式治理视角。

一个重要技术因素会显著影响布局设计：你是否采用受管（managed）或外部（external）的表/卷（volume）。如果选择受管对象，设计会更简单，因为你可以在 catalog 级别指定 managed location，从而实现逻辑与物理的一对一映射。当然，即便在已指定 managed location 的 catalog 中，也可存在 external 表/卷，但这会让逻辑与物理之间的映射变复杂。为简明起见，下文仅以受管对象来讨论 catalog 布局设计。

面向某个 OU 的最简布局如图 5-17 所示，其要点如下：

为该 OU 准备 3 个专属 catalog，分别对应开发/测试/生产环境（即一个生命周期的三个操作层级）。
为该 OU 准备专属云对象存储单元，存放其所有数据与 AI 资产。
在 catalog 级为该 OU 指定一个指向专属云存储单元的 managed location。
（可选）将这些 catalog 绑定到 OU 对应的 Databricks 工作区（如果你按环境区分工作区，建议开启）。
为 OU 准备专属账户级群组，并把这些群组赋权到 OU 的工作区与 OU 的 catalog。

在联邦治理下，OU 内的管理员应同时管理云侧资源（VPC/VNet、工作区、存储等）与 Unity Catalog 可保护对象（catalog、数据访问配置对象等）。OU 成员通常在这些 catalog 的 schema 或资产层获得只读或读写权限。

图 5-17. 面向某组织单元的简单 catalog 布局

该布局可以扩展到很多 OU（直到触及 Unity Catalog 在 catalog 或其他对象数量上的限制）。当有多个 OU 时，布局仍与上例一致，见图 5-18。

你也许会问：为什么要把环境层级放进 catalog 名称？为何要每个环境一个 catalog？为什么不在 metastore 层做隔离（不同环境不同 metastore）？或者干脆在 metastore 层隔离不同 OU 的资产？这些是大型组织里常见的问题。回顾第 3 章：一个 Databricks 账户在同一云区域内只能有一个 metastore。为什么？说明如下。

图 5-18. 两个组织单元的简单 catalog 布局

Databricks 的 Unity Catalog metastore究竟是什么？在一个 Databricks 账户中，一个区域性 metastore可以看作抽象实体。创建一个新的 metastore，并不意味着“创建了一个新资源实例”，而是创建了一个逻辑实体，它允许你把该区域内所有工作区关联起来，并作为其所有数据与 AI 资产的元数据层。一个单一 metastore 还能简化数据共享：只要权限得当，用户可在任何关联到该 metastore 的工作区访问其中编目的所有数据与 AI 资产。第 5-18 图后的分发部分会更直观。即便你“设法”在同一区域拥有多个 metastore，也会提高数据版图的复杂度——跨 metastore 的共享要借助 Delta Sharing 等机制。

结论：在同一地理区域与同一开发生命周期的不同环境内，隔离 OU 的数据与 AI 资产，最佳做法是在 catalog 层完成，并统一放在同一个区域性 metastore里。Unity Catalog 的三层命名空间很好地支持这一点，也让数据共享与分发更简单。

当某个 OU 规模较大且需要更细粒度隔离时，你还可以为 OU 的子单元创建更多的 catalog，以换取更好的隔离（同时 catalog 总数也会增多）。命名也应反映该模式。见图 5-19。

图 5-19. 面向大型组织单元的另一种 catalog 布局

我们见过的客户模式从过度复杂到过度简单不一而足：复杂布局若缺乏良好规划，往往导致高维护成本（例如 catalog 很多、云存储单元却很少）；过度简单则可能隔离不足。因此，合理的 catalog 设计至关重要。

也有客户把隔离放在 schema 层而非 catalog 层：即共用一个 catalog，而为每个 OU 建独立 schema。技术上这是可行的（schema 也可以设置 managed location）。但在 catalog 层隔离有一个额外好处：可以把 catalog 绑定到特定工作区，从而进一步提升安全性。因此，schema 级组织更适合小型且不受严格监管的组织。

谁该担任 Metastore Admin？

Metastore admin 能访问该 metastore 中所有数据与 AI 资产。如果你在多个 OU 间共享 metastore（其中某些 OU 甚至是不同法人实体），要确定由谁担任 metastore admin 并不容易——这是大型组织的常见挑战。

首先，metastore admin 是可选的，你可以不设置。但根据经验，保留该角色常常更便利，例如处理升级、集中运维、监控与合规检查；当参与 metastore 创建的运维管理员并不涉足数据域时，该角色也很有用。

如果决定保留 metastore admin，主要有五种任命方式：

若 Databricks 在你组织的技术版图中占比很大，可投资组建一支专门团队，承担关键管理角色，例如：

Databricks 平台运维团队

Databricks 卓越中心（CoE）

Databricks 治理团队

让现有的管理团队担任该角色，例如：

云平台团队

身份管理团队（如 Entra ID 管理组）

平台运维团队

数据治理团队

组建一个虚拟团队，由不同 OU 的代表组成，共同承担职责。

把 metastore admin 角色赋给一个空群组。需要临时提权时，将指定人员短期加入该群组，完成操作或超时即移除。这相当于“破窗（break glass） ”流程，也有助于防止误操作。

把 metastore admin 赋给一个服务主体（SP） ，所有 metastore 级操作通过 API 或 IaC 脚本自动化完成，并与组织的 IT 工单系统集成。

无论采用哪种方式，建议把角色授予群组而非个人。此外，metastore admin 执行的每个动作都会被记录在审计日志中。结合上述做法与审计机制，可以在安全与可问责的前提下使用这一强权限角色。

数据共享与分发

到目前为止，我们讨论了按 OU（组织单元）设计的 catalog 布局以及资产访问。在大多数情况下，你会希望把 OU 内创建的数据与 AI 资产分享给其他 OU。本节将介绍实现这一目标的不同方式。

就地发布（In-place publishing）

与其他 OU 共享资产的最简单方式，是直接对这些资产授予权限。通常应限制为只读。以分享一张表为例，在 Unity Catalog 的权限上，这意味着：对该表授予 SELECT，并对其所在的 catalog 与 schema 分别授予 USE CATALOG 与 USE SCHEMA。如果你已将 catalog 绑定到对应 OU 的工作区，那么还需要把该 catalog 绑定到消费方 OU 的工作区。通常该绑定也应为只读。参考前文“两大 OU 的 catalog 布局”，资产共享如图 5-20 所示。

图 5-20. 直接在源 OU 的生产 catalog 上授予消费者访问权的简单共享模型

专用发布 catalog

你可能会担心：直接给其他 OU 访问生产 catalog并不理想；或者你和同事都不愿意将生产 catalog 绑定到 OU 之外的工作区。此时可以考虑为对外发布的资产单独准备一个专用发布 catalog。你在该发布 catalog 上向消费者授予相应权限，并把他们的工作区绑定到这个发布 catalog。图 5-21 展示了这种做法。

图 5-21. 将数据发布到 OU 专属的“发布”catalog，并在该 catalog 上向消费者授予访问的模型

讨论这种方式时，一个常见问题是：是否要把资产从生产 catalog 复制到发布 catalog？答案是不需要。思路是：你打算分享什么，就直接在发布 catalog 中创建/更新什么。图 5-22 展示了结合勋章架构（Medallion）的发布流程。正如第 1 章所述，勋章架构通常包含 bronze、silver、gold 多层；你通常分享的是 gold 层资产。因此在编排数据转换时，可在生产 catalog中生成 bronze/silver，而把 gold 直接写入发布 catalog。

图 5-22. 将 gold 表直接写入“发布”catalog 的编排，避免数据复制

这种设置可称为分布式发布：每个 OU 各自创建并维护一个发布 catalog。它适用于没有 CDP 团队的组织，或 OU 的对外资产仅与一两个 OU 相关。反之，若你有 CDP 团队，且 OU 间分享/消费十分活跃，则集中式发布更合适。

集中式发布

此方式下，你创建并维护一个中心发布 catalog，它独立于所有 OU；愿意分享数据的 OU 都把资产发布到这个中心发布 catalog。让所有 OU 对同一 catalog 具备写入能力在持续运营上会很难，因此可采用替代方案：为每个 OU 划定一个或多个专属 schema，只在这些 schema 上授予写入（具体为 MODIFY）权限；同时对其他 OU 做选择性授权。此外，建议对所有 OU 授予该中心发布 catalog 的 BROWSE 权限，以便资产可发现；潜在消费者可搜索、发现并发起申请。第 7 章会更深入讨论可发现性。

图 5-23 展示了集中式发布模型。需要强调的是，发布到中心 catalog 并不意味着一定要从你的生产 catalog 复制资产到发布 catalog；你也可以直接在中心发布 catalog 中创建这些资产。如果中心团队自身也有希望分享的资产，同样可以发布到这个中心 catalog。

图 5-23. 将资产发布到中心“发布”catalog 的数据共享模型

集中式发布相较分布式发布的优势：

各 OU 无需维护各自的发布 catalog；在一定程度上还能节省存储成本，因为资产直接在中心发布 catalog 中创建/更新（由 CDP 团队托管）。
由于所有已发布资产都集中在与 OU 解耦的中心 catalog 中，搜索与发现相对更容易。

但如果没有明确规范与严格约束，中心 catalog 也可能沦为“大杂烩”。因此需要制定合规的发布流程。

我们讨论了多种 catalog 布局和共享模型。坦白说，我们几乎没见过谁能一丝不差地照搬理想方案，也不认为未来会有。以上方案是“理想型”，可以作为努力方向；现实中很难强推如此清晰的边界：你可能会为每个 OU 建不止三个 catalog，也可能会有不止一个发布 catalog，很多情况下会采用混合策略。只要职责与所有权清晰、并坚持最小权限等稳健安全实践，这样的“混搭”完全没问题。

随着数据量激增，catalog 与其他可保护对象随之增长，想要“人人都能访问一切”的用户也越来越多——管理复杂度会显著上升。应对之道是把数据与 AI 资产当作产品来运营：建立数据产品框架，签订数据契约，引入认证流程，有助于构建干净、可持续的数据共享与协作实践。Unity Catalog 的数据布局、治理特性与共享能力，非常适合用于数据产品化与实现类似数据网格（data mesh）的架构。

融会贯通

将物理/逻辑存储布局、权限与所有权模型组合成一套数据架构并非易事，却至关重要。你的数据与 AI 资产是需要抵御内外威胁的“宝藏”。你可以借助 Databricks 平台提供的多种访问控制选项，设计并落地稳健、可扩展的治理模型。也许需要花时间反复讨论和迭代，但这很值得。

以 Nexa Boutique 为例：在 Unity Catalog 之前，CDP 团队几乎掌控了大多数数据与 AI 资产以及它们的消费方式——实质上是趋于集中式的治理，但缺乏正式的政策与流程。若由单一团队负责全公司的采集、转换与供给，治理就很难实现分布或联邦化。这并非刻意设计，而是有机增长的结果。

如果你是一家创业公司（且收入并非依赖卖软件），很可能并不会过分在意数据架构或技术债；你会把重心放在业务增长，其他东西跟着“长”。Nexa 也是如此：一套数据平台从公司早期一路撑到跨国阶段。迁移到 Unity Catalog 时，他们抓住机会重构数据架构。

Nexa 决定现代化其数据与相关资产的管理方式。CDP 团队厌倦了做“瓶颈”，也厌倦了内部“老旧不贴近业务”的负面形象。他们与多个业务域代表、Databricks 及其合作伙伴反复研讨，最终确定采用一种数据网格风格的架构：多个数据域加中心枢纽发布通用资产的混合拓扑——把协调式数据网格与**辐射式（hub-and-spoke）**模型结合，并在不同地域复用该思路。图 5-24 展示了这种混合数据网格拓扑。

在协调式拓扑中，各数据域创建并发布域内资产，由其他数据域直接消费。在中心枢纽拓扑中，各数据域把资产发布到中心枢纽，再由其他数据域从中心消费。Nexa 采用的混合拓扑中，部分资产在域内发布，另一些对多域通用的资产发布到中心枢纽。

图 5-24. 结合中心枢纽与协调发布的混合数据网格拓扑

在 catalog 布局上，每个数据域为每个环境（dev/stg/prd）各设一个 catalog，并另设一个发布 catalog；由 CDP 团队管理的中心枢纽也采用相同设置。新架构的关键变化是：每个数据域（映射到销售、市场等业务域）负责采集并转换其最熟悉的数据源。例如销售团队大量使用 Salesforce，则销售数据域负责从 Salesforce 采集、转换并产出数据产品。贴近源头的数据产品称为源对齐数据产品（source-aligned） 。各数据域将源对齐产品发布到本域的发布 catalog或中心枢纽的发布 catalog；中心枢纽继续处理非特定域的数据源。图 5-25 展示了该设置与 catalog 设计。

图 5-25. 混合数据网格拓扑中，中心枢纽与各数据域的 catalog 布局

Nexa 在权限模型上延续了其安全优先的设计，关键实践包括：

坚持最小权限原则：只授予完成工作所需的最小集合。
采用零信任：即便已认证，也需显式授予访问。
在 metastore 层的首层对象（catalog、storage credentials、external locations）由中心与各域的管理员创建。
普通用户的权限仅落在 catalog 内，有时甚至只在 schema 内。
生产工作区与 catalog 默认禁止人类访问；生产环境处理由 **SP（服务主体）**执行。仅在改配或排障时临时赋权给人。
生产与发布 catalog 默认只允许受管表/卷；外部表/卷仅作例外。
一律把权限授予账户级群组，不授予个人。
生产环境所有 securables 的所有者是由 SP 组成的群组。
即便在工作区层面，也只给必要权限，例如 SQL Warehouse 的 USE、Query 对象的 CAN RUN。
各数据域有权自主管理其工作区与 Unity Catalog 资源；同时遵循中心制定/有时强制的准则与策略。Nexa 还设立了 metastore admin，由 CDP 与各数据域代表组成的群组担任。更多安全与治理细节将在后续章节涉及。

小结

本章展示了：想要保护你的数据与 AI 资产，必须在工作区层与 Unity Catalog（metastore）层同时施加合适的访问控制；同时介绍了 catalog 布局与资产共享的多种方法，这些方法对各种规模的组织都适用。我们也看到 Nexa Boutique 如何把迁移到 Unity Catalog 的过程，转化为现代化其数据版图的契机。第 6 章将进入一个更新的话题：AI 的安全与治理。