3. 命名规范与标签体系：建立统一的数据资产命名规则与标签分类标准

数据目录好不好用，七成看命名，三成看标签。

这话可能有点，但我在好几个项目里都验证过。有一次帮一家金融客户梳理数据资产，光一个「客户信息表」就冒出来七八种叫法：cust_info、customer_data、t_cif、CLIENT_BASE……你想想看，搜索的时候到底该敲哪个词？

所以这一章，咱们就把命名规范和标签体系彻底聊透。

3.1 为什么命名规范这么重要

说白了，命名规范就是数据资产的「身份证号」。没有它，搜索就是大海捞针。

我个人的习惯是：命名规范解决「找得到」的问题，标签体系解决「找得准」的问题。两者缺一不可。

举个例子：

• ods_ord_trade_di → 一看就知道是 ODS 层的订单交易明细表，按天增量更新
• app_cust_risk_score_df → 应用层的客户风险评分表，全量快照

嗯，这才是好名字。

3.2 命名规范的三层结构

我在实践中总结了一套「三段式」命名法，你可以直接拿来用：

层级	含义	示例
第一段：数据域/层	标识数据所属的业务域或技术层	ods、dwd、dws、app、dim
第二段：业务主题	标识核心业务实体或主题	ord（订单）、cust（客户）、prod（产品）
第三段：后缀/属性	标识数据粒度、更新频率、类型	di（日增量）、df（全量）、ri（实时）

完整的命名示例：

ods_ord_trade_di      -- ODS层，订单交易，日增量
dwd_cust_addr_df      -- DWD层，客户地址，全量快照
dws_sale_daily_1d     -- DWS层，销售日汇总，1天粒度
app_risk_score_ri     -- APP层，风险评分，实时
dim_date_v            -- 维度表，日期，视图

3.3 标签体系：给数据资产打上「多维坐标」

命名规范解决的是「主标识」问题。但一个数据资产可能有多个维度的属性，这时候就需要标签体系了。

我曾经遇到一个场景：一张表叫 app_user_behavior，它既是用户画像团队的产出，又是推荐系统的输入，还涉及隐私合规。光靠名字根本表达不了这么多信息。怎么办？打标签。

3.4 标签分类标准

我建议把标签分成四大类：

标签类别	说明	示例
技术标签	描述技术属性	Hive表、Parquet格式、分区表、T+1更新
业务标签	描述业务归属	会员域、交易域、风控域、营销域
治理标签	描述数据质量与生命周期	已认证、待清理、敏感数据、PII
使用标签	描述使用场景	报表源、模型输入、API接口、人工标注

每个数据资产至少打上 3-5 个标签，覆盖两个以上类别。这样搜索的时候，不管用户从哪个维度切入，都能命中。

3.5 命名与标签的协同关系

命名和标签不是割裂的。我习惯把它们看作一个整体：

• 命名：唯一标识，全局唯一，不可重复
• 标签：多维描述，可重复，可组合

举个例子：

表名：dwd_cust_credit_score_df
标签：[
  "技术: Hive",
  "技术: 分区表",
  "业务: 风控域",
  "业务: 客户信用",
  "治理: 已认证",
  "治理: 敏感数据(PII)",
  "使用: 模型输入",
  "使用: 日更新"
]

用户搜索「风控 客户 信用」或者「敏感数据 模型输入」，都能找到这张表。这就是协同的力量。

3.6 落地实施步骤

光有理论不行，得能落地。我建议分四步走：

1. 制定规范文档：把命名规则、标签分类、示例写成文档，全员评审
2. 建立词根表：统一业务术语的缩写，比如 ord=订单、cust=客户，避免出现 order、ordr、od 等混乱写法
3. 工具化强制校验：在数据平台接入命名校验脚本，不符合规范的表不允许创建
4. 存量资产清洗：对已有数据资产进行批量重命名和标签补全，分批次推进

3.7 知识体系总览

下面这张图把命名规范与标签体系的核心逻辑串起来了：

3.8 常见问题与应对

最后聊几个我踩过的坑：

• 命名太长怎么办？ 控制在 3-5 段，每段不超过 8 个字符。超过这个长度，建议用标签补充描述。
• 历史遗留表怎么处理？ 先建别名映射，再逐步迁移。别一上来就改物理名。
• 标签谁来打？ 我建议「数据生产者打基础标签，数据管理者打治理标签，数据消费者打使用标签」。分工明确，责任到人。
• 标签怎么维护？ 每季度做一次标签清理，把无效标签、重复标签、过期标签移除。标签也是需要「新陈代谢」的。