4. Unity Catalog统一治理体系
Unity Catalog（UC）是 Databricks 湖仓的“统一治理控制面”。它把过去分散在 Hive Metastore、工作区本地文件、集群级凭证里的元数据与访问控制，收敛成一套跨工作区、跨计算引擎的集中式对象模型。理解 UC，关键不是记住几个名词，而是看清一条治理主线：对象挂在哪里、权限沿什么路径继承、数据从哪来到哪去、谁在什么时候动了它、以及如何安全地跨工作区共享。本节围绕这条主线展开。
一、五级对象模型：从 Metastore 到 Volume
UC 的对象是严格分层的，层级关系决定了命名方式与权限继承路径。最顶层是 Metastore，它是区域级的元数据容器，一个区域（region）通常只挂一个 Metastore，并绑定到该区域内的多个工作区。Metastore 之下是 Catalog，用于按业务域或环境隔离，例如 prod_finance、dev_marketing。Catalog 之下是 Schema（旧称 Database），承载一组逻辑相关的表与视图。Schema 之下才是 Table、View 和 Volume 这些数据对象。
这里最容易混淆的是 Table 与 Volume 的分工。Table 由 UC 托管元数据，数据文件可以是托管（Managed）或外部（External）位置；而 Volume 是 UC 中专门用于管理非结构化与半结构化文件的对象，例如 CSV 原始落地、图片、模型文件、日志。Volume 分托管卷与外部卷，外部卷指向云存储路径，但访问同样受 UC 权限控制。换句话说，Table 管“有 schema 的表数据”，Volume 管“文件”，两者都在 Schema 下，都受同一套权限体系约束。
完整引用路径形如 catalog.schema.table，Volume 则是 catalog.schema.volume。这种三段式命名让任何一条 SQL 都能明确指向唯一对象，也让权限授予可以精确到对象粒度。
二、权限模型：继承、最小权限与授权对象
UC 的权限模型是“对象级授权 + 层级继承”。授权语句形如 GRANT SELECT ON TABLE prod_finance.sales.orders TO `analyst_group`，被授权者可以是用户、服务主体（Service Principal）或组。组是推荐做法，因为人员变动时只需调整组成员，不必逐条改权限。
继承规则要特别注意：要访问 prod_finance.sales.orders，用户不仅需要该表的 SELECT，还需要对 prod_finance 有 USE CATALOG、对 sales 有 USE SCHEMA。这三级缺一不可，是初学者最常见的“权限明明给了却查不到表”的原因。反过来，如果只授予了 Catalog 和 Schema 的 USE，却没有表级 SELECT，同样无法读取数据。
实践上应遵循最小权限原则：按业务域建 Catalog，按数据分层建 Schema，把权限授予组而非个人；对敏感表使用行级过滤与列掩码（Row Filter / Column Mask），让同一张表对不同组呈现不同数据。Volume 的权限独立于 Table，读取文件需要 READ VOLUME，写入需要 WRITE VOLUME，不能靠表权限“顺带”获得。
三、数据血缘：从列级追踪影响范围
UC 自动采集表级与列级血缘，覆盖 Notebook、SQL Warehouse、Job 等执行路径。血缘的价值在于回答两类问题：一是“这张表的数据从哪来”（上游溯源），二是“改这张表会影响谁”（下游影响分析）。例如当 raw.orders 的 amount 字段类型变更时，血缘图能直接列出所有引用该列的视图与下游表，避免盲目排查。
血缘基于实际执行的查询计划生成，因此用 SELECT * 或动态 SQL 拼接时，列级血缘可能不完整。要让血缘可靠，应尽量显式列出字段、避免过度动态化，并在关键链路上保持命名规范。
四、审计与跨工作区共享
审计方面，UC 把访问记录写入系统表，常用的是 system.access.audit 与 system.access.table_lineage、system.access.column_lineage。通过查询审计表，可以回答“谁在什么时间对哪张表执行了什么操作、来自哪个工作区、结果成功还是失败”。例如排查异常导出时，可按 action_name、user_identity.email、request_params 过滤，定位到具体的 SELECT 或 READ VOLUME 行为。
跨工作区共享是 UC 相对传统 Hive Metastore 的核心优势：因为 Metastore 是区域级共享的，同一区域内的多个工作区天然看到同一套 Catalog 与权限，无需为每个工作区重复建表、重复授权。跨区域或跨账号场景则通过 Delta Sharing 以只读方式共享表与 Volume，接收方无需复制数据即可查询。共享时同样遵循最小权限，只开放必要的 Schema 与表，并可通过共享级权限进一步收窄。
五、一个可复用的治理落地顺序
综合以上，落地 UC 治理可按如下顺序推进，避免返工：
- 规划命名：确定 Catalog 划分维度（按环境或业务域），Schema 按 raw / curated / serving 分层。
- 建组与授权：先建用户组与服务主体，再按组授予 USE CATALOG、USE SCHEMA 及对象级权限。
- 接入数据：结构化数据建 Table，文件类数据建 Volume，统一走三段式命名。
- 加敏感控制：对含 PII 的表配置行过滤与列掩码。
- 验证血缘与审计：跑一次典型查询，确认血缘图出现列级连线，并在
system.access.audit中查到对应记录。 - 按需共享：同区域工作区直接复用 Metastore；跨区域用 Delta Sharing 只读共享。
需要强调的是，UC 的治理能力只有在“对象建在 UC 下、访问走 UC 路径”时才生效。如果仍把数据放在工作区本地 DBFS 或绕过 UC 直接读云存储，血缘与审计都会出现盲区。因此治理的第一步，往往是把存量对象迁移或注册到 UC 的 Catalog 体系中。