📚 课程目录第3章 Unity Catalog数据资产组织

3. Unity Catalog数据资产组织

Unity Catalog 用一套统一的三级命名空间来组织所有数据资产：目录（Catalog）→ 模式（Schema）→ 对象（Table / View / Volume / Function / Model）。理解这套层级，是设计跨团队协作权限模型的前提。本节先讲清对象类型与命名规则，再给出可落地的可见性设计方法。

一、三级命名空间与对象类型

Unity Catalog 中每个对象的完整限定名（fully qualified name）都是三段式：

catalog.schema.object
例如：sales_prod.orders.fact_order
      sales_prod.ml.churn_model
      sales_prod.raw.landing_volume

其中前两级是容器，第三级才是真正的资产。容器与资产的对应关系如下：

Catalog（目录）：最高层隔离边界，通常按环境（dev / staging / prod）或业务域（sales / finance / marketing）划分。目录是权限授予和存储位置（Managed Location）绑定的主要单位。
Schema（模式）：目录内的逻辑分组，类似传统数据库的 database。常见划分方式是按数据分层（raw / bronze / silver / gold）或按主题域（orders / customers / payments）。
Table（表）：结构化数据主体，分 Managed（UC 托管存储）与 External（外部路径注册）两类。
View（视图）：基于表或其他视图的查询结果，是跨团队共享时最常用的“脱敏层”和“稳定接口层”。
Volume（卷）：用于存放非结构化或半结构化文件（图片、日志、CSV、模型权重等），分 Managed Volume 与 External Volume。
Function（函数）：用户自定义函数（UDF），可被 SQL 与 PySpark 调用，适合封装跨团队复用的业务规则。
Model（模型）：MLflow 注册模型在 UC 中的载体，命名形如 catalog.schema.model_name，并带版本号。

需要特别注意的是：Volume、Function、Model 与 Table 处于同一层级，它们共享同一个 schema 命名空间。因此同一个 schema 下不能出现同名的表和卷，命名时要避免冲突。

二、命名规范设计

命名规范的目标是让对象名本身携带足够信息，使跨团队使用者无需查文档就能判断归属与用途。推荐采用如下约定：

层级	命名规则	示例
Catalog	业务域_环境	sales_prod、sales_dev
Schema	分层或主题	bronze、silver、gold、ml
Table	实体_粒度	fact_order_daily、dim_customer
View	v_用途_来源	v_order_masked、v_customer_360
Volume	vol_用途	vol_raw_landing、vol_model_artifacts
Function	fn_业务含义	fn_calc_tax、fn_mask_phone
Model	模型用途_算法	churn_xgboost、fraud_lgbm

统一前缀（v_ / vol_ / fn_）的价值在于：在 SHOW TABLES 或 Catalog Explorer 中一眼区分对象类型，减少误操作。命名中避免使用空格、中文和大小写混用，统一小写加下划线。

三、跨团队可见性设计

可见性由 GRANT / REVOKE 在三级层级上控制，权限沿层级向下继承。核心原则是：容器开放、资产收敛——让团队能“看到目录和模式”，但只能“访问被授权的具体对象”。

典型做法是：

对协作团队授予 USE CATALOG 和 USE SCHEMA，使其能浏览层级结构，但不自动获得数据读取权。
对具体表/视图授予 SELECT，对卷授予 READ VOLUME / WRITE VOLUME，对函数授予 EXECUTE，对模型授予 EXECUTE。
敏感字段通过视图做列级脱敏，而不是直接开放基表，这样基表权限可以收紧到只有数据工程团队持有。

-- 让分析团队能浏览 sales_prod，但只读 gold 层
GRANT USE CATALOG ON CATALOG sales_prod TO `analytics_team`;
GRANT USE SCHEMA ON SCHEMA sales_prod.gold TO `analytics_team`;
GRANT SELECT ON VIEW sales_prod.gold.v_order_masked TO `analytics_team`;

-- 数据工程团队持有基表写权限
GRANT MODIFY ON TABLE sales_prod.silver.fact_order TO `data_eng_team`;

-- 共享模型给下游推理服务
GRANT EXECUTE ON MODEL sales_prod.ml.churn_xgboost TO `ml_serving_team`;

这里有一个容易踩的坑：只授予 SELECT 而不授予 USE SCHEMA，用户仍然无法访问。三级权限必须逐级满足，缺一不可。排查“为什么查不到表”时，第一件事就是检查 USE CATALOG 与 USE SCHEMA 是否都已授予。

跨团队共享优先用视图而非直接授权基表。视图是稳定的接口契约：基表结构变化时只需调整视图定义，下游团队的查询语句无需改动，权限也无需重新授予。

四、层级与可见性关系图解

下图把三级命名空间、对象类型与权限继承关系放在同一张图中，帮助建立整体认知：

五、跨团队协作的落地建议

把上述规则落到日常协作中，可以遵循三条实践：

按团队建组，按组授权：不要对个人账号授权，统一用 Account Group 或 Workspace Group，人员变动时只改组成员，不动权限。
共享层与生产层分离：在 gold 层建立专门的共享 schema（如 sales_prod.shared），只放视图和已脱敏表，对外团队只授予该 schema 的 USE SCHEMA 与对象 SELECT。
用 Catalog Explorer 做审计：定期检查各 schema 的授权列表，确认没有遗留的宽泛授权（如对整目录授予 SELECT），这是跨团队数据治理中最常见的风险点。

不要为了“方便”直接对 Catalog 授予 SELECT。一旦目录级开放，该目录下所有 schema 的所有表都会对团队可见，后续新增的敏感表也会自动暴露，这是权限设计中最难回退的错误。

掌握三级命名空间与权限继承规则后，跨团队协作的边界就变得清晰可控：容器负责“能不能看见”，对象级授权负责“能不能用”，视图负责“看到什么”。这三者配合，才能在共享效率与数据安全之间取得平衡。