3. Unity Catalog 作为协作治理底座
跨团队协作真正困难的地方，往往不是“能不能把数据给别人”，而是“给出去之后，谁还能找到它、谁还能管住它、谁还能追溯它”。Unity Catalog（UC）在 Databricks 中承担的就是这个底座角色：它把数据资产、权限、血缘和审计统一到一套命名空间与一套权限模型里，让不同团队在同一个治理框架下发现数据、申请访问、被授权、被审计。理解 UC，核心是理解它的三层命名空间和对象模型，以及这套结构如何自然支撑跨团队的发现与访问控制。
一、Metastore 层级：从账户到对象的三级命名空间
UC 的命名空间是三级结构：metastore → catalog → schema → 对象。其中 metastore 是账户级的治理边界，一个 metastore 通常对应一个组织或一个强隔离的业务域，它绑定到具体的云区域，并集中保存元数据、权限授予和审计记录。metastore 之下是 catalog，catalog 是数据隔离与权限授予的第一层实用单位，常见做法是按业务域或环境划分，例如 sales_prod、sales_dev、marketing_prod。catalog 之下是 schema（在旧语境里也叫 database），schema 用于组织同一主题下的表、视图、卷和函数，例如 sales_prod.orders、sales_prod.customers。
三级命名空间的价值在于：它让“数据在哪”和“谁能访问”可以同时被表达。一个对象的完整名称 catalog.schema.object 既是定位符，也是权限判定的作用域。跨团队协作时，团队 A 不需要知道团队 B 的存储路径，只需要知道对方公开的 catalog 与 schema 名称，就能在目录中检索到资产。
二、对象模型：表、视图、卷、函数各自承担什么
UC 管理的对象不只是表。理解每类对象的定位，才能在设计协作方案时选对载体。
- Managed Table（托管表）：UC 同时管理元数据与底层数据文件，删除表时数据一并清理。适合由生产团队统一维护、对外共享的稳定数据集。
- External Table（外部表）：UC 只管理元数据，数据文件位于外部存储路径。适合已有数据湖文件需要纳入治理、但生命周期由外部系统控制的场景。
- View（视图）：在表之上做投影、过滤、脱敏或聚合。跨团队共享时，视图常被用作“受控出口”——只暴露必要列，隐藏敏感字段。
- Volume（卷）：用于管理非结构化或半结构化文件，如 CSV、JSON、图片、模型文件。它让文件也能进入 UC 的权限与审计体系，而不是散落在路径权限里。
- Function（函数）：可注册的 UDF，把业务口径（如“有效订单”的定义）封装成可复用、可授权的对象，避免各团队各写一套逻辑。
这五类对象共享同一套权限模型，意味着无论共享的是表、视图还是卷，授权方式是一致的，审计口径也是统一的。
三、统一权限模型如何支撑发现与访问控制
UC 的权限模型基于 GRANT / REVOKE，权限沿层级向下继承：在 catalog 上授予 USE CATALOG，在 schema 上授予 USE SCHEMA，在对象上授予 SELECT、MODIFY 等。跨团队访问一个表，通常需要同时具备上层 USE 权限和对象上的 SELECT 权限。这种“上层可见 + 下层可用”的组合，让管理员可以精细控制“能看见目录”和“能读取数据”两件事。
发现能力则来自 UC 的元数据目录：用户可以在 Catalog Explorer 中按名称、标签、注释检索资产，查看列级 schema、血缘和负责人。发现与访问控制在这里是同一套元数据的两个面——能发现什么，取决于你被授予了哪些 USE 与 SELECT。
示例：为分析团队开放订单数据的授权路径
-- 1. 允许分析团队看到 sales_prod 目录
GRANT USE CATALOG ON CATALOG sales_prod TO `analytics_team`;
-- 2. 允许其进入 orders schema
GRANT USE SCHEMA ON SCHEMA sales_prod.orders TO `analytics_team`;
-- 3. 只授予脱敏视图的查询权，而非基表
GRANT SELECT ON VIEW sales_prod.orders.v_orders_masked TO `analytics_team`;
-- 4. 若需读取卷中的原始文件
GRANT READ VOLUME ON VOLUME sales_prod.orders.raw_files TO `analytics_team`;判断依据：分析团队能检索到 sales_prod.orders，能查询 v_orders_masked，但无法直接读取基表 orders，也无法写入任何对象。若查询报“TABLE_OR_VIEW_NOT_FOUND”，通常是缺少上层 USE 权限；若报“PERMISSION_DENIED”，则是对象级权限未授予。
四、协作视角下的层级设计原则
把 UC 用作协作底座时，命名空间设计直接决定协作成本。一个常见且有效的做法是：按业务域建 catalog，按主题建 schema，按消费方式建对象。生产团队维护 sales_prod，在其中用 orders、customers 等 schema 组织主题；对外共享时，优先通过视图或专门的共享 schema 暴露，而不是直接开放基表。这样既保留了内部灵活调整的空间，又让外部团队的依赖面稳定可控。
另一个关键点是权限授予的粒度选择。授予整个 catalog 的 USE CATALOG 能让对方发现该域下的资产，但不应同时授予 SELECT；对象级 SELECT 才是真正的数据访问开关。对于需要长期协作的团队，可以借助 UC 的组（group）而非个人进行授权，把人员变动的影响收敛到组成员管理上。
五、把 UC 用成协作底座的三个判断点
第一，发现与访问是否分离。如果对方能看到目录却打不开表，说明 USE 与 SELECT 的边界是清晰的，这是好事；如果对方既看不到也打不开，需要先补 USE 再补对象权限。第二，共享载体是否稳定。直接共享基表会让对方依赖内部表结构，一旦生产团队调整列或分区，消费方就会断裂；通过视图共享可以把变更影响收敛在视图定义里。第三，授权对象是否可维护。按组授权、按 catalog/schema 分层授权，比逐人逐表授权更容易在人员流动时保持一致。
排查跨团队访问问题时，可以按“命名空间 → 上层 USE → 对象权限 → 对象类型”的顺序检查：先确认完整名称 catalog.schema.object 是否正确，再确认 USE CATALOG 与 USE SCHEMA 是否授予，然后确认对象级 SELECT 或 READ VOLUME 是否存在，最后确认访问的是视图还是基表、是表还是卷。多数“看不到”或“打不开”的问题都能在这一条链路上定位。
Unity Catalog 作为协作治理底座，本质上是把“数据在哪、谁能发现、谁能使用、谁改过什么”收敛到一套命名空间和一套权限模型里。掌握 metastore 到 catalog、schema、对象的层级关系，理解表、视图、卷、函数在协作中的不同定位，再配合 GRANT 的分层授权，跨团队的数据发现与访问控制就不再依赖口头约定和路径权限，而是变成可检索、可授权、可审计的治理动作。