4. Unity Catalog元数据与权限治理

Unity Catalog 是 Databricks Lakehouse 中统一管理数据与 AI 资产的元数据与权限层。它把原本分散在多个工作区、多个存储账户中的表、视图、卷、函数、模型等对象，纳入同一个三层命名空间：Catalog → Schema → Object。理解这个层级，是理解后续权限、血缘和外部位置治理的前提。

三层命名空间的实际写法是 catalog.schema.object，例如 sales_prod.orders.fact_order。其中 Catalog 通常对应一个业务域或环境边界（如 sales_prod、sales_dev），Schema 对应数据集市或主题域（如 orders、customers），最底层对象可以是表、视图、Volume、函数或模型。这种结构让权限可以在任意层级授予，并沿层级向下继承。

权限模型：从 GRANT 到行级与列级控制

Unity Catalog 的权限通过 SQL 的 GRANT / REVOKE 语句授予，作用对象可以是 Catalog、Schema、Table、View、Volume 等。权限沿层级向下继承：在 Catalog 上授予 USE CATALOG，用户才能看到该 Catalog 下的 Schema；在 Schema 上授予 USE SCHEMA 与 SELECT，用户才能查询其中的表。常见权限包括 USE CATALOG、USE SCHEMA、SELECT、MODIFY、CREATE TABLE、READ VOLUME、WRITE VOLUME 等。

当业务要求“同一张表，不同用户看到不同行或不同列”时，仅靠表级 GRANT 不够，需要细粒度访问控制。Unity Catalog 支持两种主要手段：行级安全（Row Filter）与列级掩码（Column Mask）。它们通过用户自定义函数实现，并绑定到目标表上。

-- 1. 创建行过滤函数：只允许看到本区域订单
CREATE FUNCTION sales_prod.orders.fn_region_filter(region STRING)
RETURN IF(IS_ACCOUNT_GROUP_MEMBER('regional_analyst'), region = current_user_region(), TRUE);

-- 2. 将行过滤函数绑定到表
ALTER TABLE sales_prod.orders.fact_order
SET ROW FILTER sales_prod.orders.fn_region_filter ON (region);

-- 3. 创建列掩码函数：对手机号脱敏
CREATE FUNCTION sales_prod.orders.fn_mask_phone(phone STRING)
RETURN IF(IS_ACCOUNT_GROUP_MEMBER('pii_reader'), phone, '***-****');

-- 4. 将列掩码绑定到指定列
ALTER TABLE sales_prod.orders.fact_order
ALTER COLUMN customer_phone SET MASK sales_prod.orders.fn_mask_phone;

上述示例中，regional_analyst 组的成员只能看到与自己区域匹配的行；非 pii_reader 组的用户查询 customer_phone 时得到脱敏值。行过滤与列掩码在查询执行时由引擎自动应用，用户无需改写 SQL，也无法通过其他查询绕过。

Volume 与外部位置：非结构化数据与云存储治理

Volume 是 Unity Catalog 中用于管理非结构化数据的对象，适合存放 CSV、JSON、图片、模型文件等。Volume 分为托管卷（Managed Volume）与外部卷（External Volume）：托管卷由 Unity Catalog 管理生命周期，数据存放在默认存储位置；外部卷指向用户指定的云存储路径，适合已有数据湖目录的接入。访问 Volume 需要 READ VOLUME 或 WRITE VOLUME 权限。

外部位置（External Location）解决的是“云存储路径级别的授权”。它把云存储路径与 Storage Credential 绑定，只有被授予该 External Location 访问权的用户或组，才能通过 Unity Catalog 读写对应路径。这样，即使某人拿到了存储路径，没有 External Location 授权也无法访问，形成元数据层与存储层的双重防护。

数据血缘：影响分析与合规审计的基础

Unity Catalog 自动采集表、列、作业、Notebook 之间的血缘关系。当 raw_landing.orders_raw 经过 ETL 写入 orders.fact_order，再被 v_order_summary 引用时，血缘图会记录这条链路。血缘的价值在于：上游表结构变更时，可以快速定位受影响的下游对象；合规审计时，可以追溯敏感字段从哪张源表流入、经过哪些转换。

血缘信息可在 Catalog Explorer 中查看，也可通过 system.access.table_lineage 与 system.access.column_lineage 系统表查询。例如，要找出所有直接依赖 fact_order 的下游表，可以查询 system.access.table_lineage 中 source_table_full_name = 'sales_prod.orders.fact_order' 的记录。列级血缘则能精确到字段，适合做 PII 字段的传播分析。

治理落地要点

• 命名规范：Catalog 用 域_环境，Schema 用主题域，表名用 fact_ / dim_ / raw_ 前缀，便于权限批量授予与血缘识别。
• 权限最小化：优先在 Schema 层授予 USE SCHEMA + SELECT，避免在 Catalog 层授予过宽权限；敏感表单独收紧。
• 细粒度控制优先用函数：行过滤与列掩码函数集中放在独立的 security Schema 中，由安全团队维护，业务表只做绑定。
• 外部位置按路径授权：为每个业务域创建独立 External Location，避免跨域路径混用。
• 定期审计：通过 system.access.audit 检查权限变更与异常访问，结合血缘确认敏感数据流向。

综合来看，Unity Catalog 的治理能力可以概括为“一套命名空间、一套权限模型、一套血缘记录”。Catalog、Schema、Table、Volume 构成对象层级，GRANT 与行/列级函数构成权限控制，External Location 守住存储入口，血缘提供可追溯性。四者配合，才能在 Lakehouse 上实现既开放又可控的数据治理。