4. Unity Catalog元数据体系设计

Unity Catalog 采用三层命名空间：Catalog → Schema → 对象（Table / View / Volume / Function / Model）。理解这套层级是设计元数据体系的前提。Catalog 是最高级别的隔离边界，通常对应一个环境（如 dev、test、prod）或一个业务域；Schema 是 Catalog 内的逻辑分组，对应一个主题域或数据分层；Table、View、Volume 则是实际承载数据、逻辑视图和非结构化文件的叶子对象。三层命名空间意味着任何对象的全限定名都是 catalog.schema.object，跨 Catalog 访问必须显式写全名，这为权限隔离和血缘追踪提供了天然边界。

命名规范的核心目标是可预测、可排序、可自动化。建议统一采用小写加下划线，避免大小写混用带来的解析歧义。Catalog 命名推荐 {环境}_{业务域}，例如 prod_sales、dev_marketing；Schema 命名推荐 {分层}_{主题}，例如 ods_order、dwd_trade、ads_finance；表命名推荐 {主题}_{实体}_{粒度}，例如 order_detail_di（日增量）、user_profile_df（日全量）。后缀 _di、_df、_hi 分别表示日增量、日全量、小时增量，让消费方仅凭表名即可判断更新节奏。View 建议加 v_ 前缀，Volume 建议加 vol_ 前缀，避免与表混淆。

分层策略解决的是“数据放在哪个 Schema”的问题。推荐采用经典的四层结构：ODS（贴源层）→ DWD（明细层）→ DWS（汇总层）→ ADS（应用层）。ODS 层 Schema 命名为 ods_{源系统}，存放与源系统结构一致的原始数据，通常只做字段类型标准化和分区处理；DWD 层命名为 dwd_{主题}，完成清洗、去重、维度退化等操作，输出一致性明细；DWS 层命名为 dws_{主题}，按分析维度做轻度聚合；ADS 层命名为 ads_{应用}，直接面向报表、API 或下游系统。此外，非结构化文件统一放入 Volume，按 vol_{用途} 命名，例如 vol_raw_landing 存放落地文件、vol_ml_features 存放特征工程中间产物。分层策略的关键约束是：数据只能从低层流向高层，不允许反向依赖，这样血缘关系始终是单向的，便于影响分析和故障回溯。

标签体系是元数据治理的“横向切面”。Unity Catalog 支持在 Catalog、Schema、Table、View、Volume 各级别打标签（Tag），标签以键值对形式存在，可用于搜索、审计和策略绑定。建议至少维护以下几类标签：数据分级（sensitivity=public/internal/confidential/restricted）、数据域（domain=sales/finance/marketing）、更新频率（update_freq=daily/hourly/realtime）、负责人（owner=team_name）、生命周期（retention_days=365）。标签应尽量在 Catalog 或 Schema 级别批量设置，子对象自动继承，减少逐表维护成本。例如在 prod_sales Catalog 上设置 domain=sales，则其下所有 Schema 和表自动携带该标签；在 dwd_trade Schema 上设置 update_freq=daily，则该层所有表默认按日更新。对于敏感字段，可在列级别追加 pii=true 标签，配合动态视图或列掩码实现访问控制。

-- 全限定名结构：catalog.schema.object
prod_sales.ods_order.order_raw_df          -- 贴源全量
prod_sales.dwd_trade.order_detail_di       -- 明细日增量
prod_sales.dws_user.user_trade_summary_df  -- 用户交易汇总
prod_sales.ads_finance.v_trade_daily       -- 应用层逻辑视图
prod_sales.raw_log.vol_raw_landing         -- 原始日志 Volume

-- 标签设置示例
ALTER CATALOG prod_sales SET TAGS ('domain' = 'sales', 'env' = 'prod');
ALTER SCHEMA prod_sales.dwd_trade SET TAGS ('layer' = 'dwd', 'update_freq' = 'daily');
ALTER TABLE prod_sales.dwd_trade.order_detail_di SET TAGS ('owner' = 'trade_team', 'retention_days' = '730');
ALTER TABLE prod_sales.dwd_trade.order_detail_di ALTER COLUMN user_phone SET TAGS ('pii' = 'true');

在实际落地时，建议把命名规范和标签体系固化为建表模板与自动化检查。例如在 CI 流程中加入校验规则：表名必须匹配 ^[a-z][a-z0-9_]*_(di|df|hi)$，Schema 名必须匹配 ^(ods|dwd|dws|ads|raw)_[a-z0-9_]+$，Catalog 名必须匹配 ^(dev|test|prod)_[a-z0-9_]+$；每个新建表必须携带 owner、domain、update_freq 三个标签，否则拒绝合并。这样命名和标签就不再是“文档里的约定”，而是可执行、可审计的工程约束。对于已有存量对象，可以通过 information_schema.tables 和 information_schema.schemata 批量扫描，识别不符合规范的命名并生成整改清单，逐步迁移到目标结构。

总结来说，Unity Catalog 元数据体系设计不是简单的“起名字”，而是通过三层命名空间划定边界、四层分层策略约束流向、标签体系提供横向检索与策略绑定，三者共同构成可治理、可审计、可自动化的数据资产底座。命名规范让对象可预测，分层策略让血缘可追踪，标签体系让策略可批量落地——三者缺一不可。