3. Unity Catalog元数据模型深入
Unity Catalog 的核心价值，在于它把原本散落在各个工作区、各个 Hive Metastore 中的元数据，收敛为一套三层命名空间加多种对象类型的统一模型。理解这套模型，是后续做数据质量校验、血缘追踪、权限治理和跨工作区共享的前提。本节从对象层级、命名规则、各对象职责以及命名空间管理实践四个角度展开。
三层命名空间：Catalog → Schema → Table/View/Volume/Function
Unity Catalog 采用 catalog.schema.object 的三段式全限定名。第一层 Catalog 是最大的隔离单元，通常按环境（dev、prod）、业务域（sales、finance）或租户划分；第二层 Schema（在旧 Hive 语境中叫 Database）是 Catalog 内的逻辑分组，用于组织同一主题下的表、视图、卷和函数；第三层才是真正的数据对象。三层之间是严格的父子包含关系，删除 Catalog 会级联影响其下所有 Schema 和对象，因此生产环境通常对 Catalog 的删除权限做最严格管控。
需要特别注意的是，Unity Catalog 中的对象分为可寻址对象和容器对象两类。Catalog 和 Schema 是纯容器，本身不存数据；Table、View、Volume、Function 才是承载实际语义的叶子对象。此外还有 Metastore 这一最顶层实体，一个 Metastore 可以挂载多个 Catalog，并绑定到多个工作区，这是实现跨工作区共享的物理基础。
四类叶子对象的职责边界
Table（表）是结构化数据的核心载体，分为托管表（Managed）和外部表（External）。托管表的数据和元数据都由 Unity Catalog 管理，删除表时数据一并删除；外部表只登记元数据，数据存放在外部存储路径（如 s3://bucket/path 或 abfss://container@account.dfs.core.windows.net/path），删除表不会动数据。做数据质量治理时，托管表更适合作为加工链路的中间结果，外部表更适合作为原始数据接入点。
View（视图）是逻辑对象，不存储数据，只保存查询定义。Unity Catalog 中的视图可以是标准视图，也可以是物化视图（Materialized View）。视图的价值在于把复杂的多表关联、过滤逻辑封装成一个可被权限管控的命名对象，下游只需 SELECT * FROM sales.curated.v_orders_clean 即可，无需重复编写清洗逻辑。
Volume（卷）是 Unity Catalog 中专门管理非结构化文件的抽象。它解决了一个长期痛点：过去用 DBFS 挂载点或外部路径访问文件时，权限无法与表统一治理。Volume 分为托管卷和外部卷，路径形如 /Volumes/sales/ml/feature_store/，可以像目录一样存放 CSV、JSON、图片、模型文件等。在数据质量场景中，Volume 常用来存放校验规则配置、异常样本快照和质检报告。
Function（函数）用于注册自定义逻辑，支持 SQL UDF 和 Python UDF。把数据质量校验中反复使用的判断逻辑（如手机号格式校验、身份证校验位计算）注册为函数，可以让校验规则在多个 Schema 间复用，并且函数本身也受 Unity Catalog 权限体系管控。
命名空间管理实践
命名空间管理不是简单的起名，而是要在隔离性、可发现性和权限粒度之间取得平衡。以下是一套可直接参考的命名约定示例：
| 层级 | 命名建议 | 示例 | 说明 |
|---|---|---|---|
| Catalog | 环境_业务域 | prod_sales | 环境前缀便于权限批量授予 |
| Schema | 数据分层 | raw / curated / ml | 与数据湖分层保持一致 |
| Table | 业务实体_粒度 | orders_fact | 事实表用 _fact，维度表用 _dim |
| View | v_业务含义 | v_orders_clean | v_ 前缀快速区分视图与表 |
| Volume | 用途_类型 | dq_rules | 按用途命名，不按文件格式 |
| Function | fn_功能 | fn_is_valid_phone | fn_ 前缀标识自定义函数 |
在权限授予时，命名空间层级直接对应授权粒度。例如 GRANT USE CATALOG ON CATALOG prod_sales TO `data_engineers` 只授予进入 Catalog 的权限，还需要 GRANT USE SCHEMA 和 GRANT SELECT ON TABLE 才能实际读取数据。这种三层授权模型让权限管理可以按层级批量操作，而不必逐表配置。
catalog.schema.table 全限定名直接访问对方的数据，无需复制数据或额外挂载。这是 Unity Catalog 相比传统 Hive Metastore 最显著的架构优势。
理解这套对象层级后，后续的数据质量规则注册、血缘采集、权限审计都可以围绕 catalog.schema.object 这一统一寻址方式展开，这也是 Unity Catalog 作为治理底座的关键设计。