4、业务元数据管理：业务术语表构建、数据字典设计、数据域与数据主题划分
业务元数据，说白了就是让技术人员和数据使用者能「说同一种话」。我见过太多项目，数据湖仓搭得漂漂亮亮，但业务部门看不懂字段，技术部门听不懂需求。嗯，这章我们就来聊聊怎么把这事理顺。
4.1 业务术语表：统一沟通的「词典」
业务术语表是元数据管理的第一步。它解决一个核心问题：同一个概念，不同部门叫法不一样。
举个例子。我在一个零售项目里遇到过，「客户」在CRM叫「会员」，在订单系统叫「买家」，在财务系统叫「付款人」。你说这三个字段要不要打通？当然要。但如果没有术语表，数据治理就是一团乱麻。
4.1.1 术语表的核心要素
一个合格的术语表，至少包含以下字段：
| 字段 | 说明 | 示例 |
|---|---|---|
| 术语名称 | 业务侧统一名称 | 客户 |
| 英文名称 | 技术侧对应英文 | customer |
| 定义 | 清晰无歧义的解释 | 在本公司注册并产生交易记录的自然人或法人 |
| 同义词 | 其他系统或部门的叫法 | 会员、买家、付款人 |
| 所属数据域 | 归属的业务领域 | 客户域 |
| 负责人 | 业务侧维护人 | 张三（市场部） |
| 状态 | 草稿/已审核/已废弃 | 已审核 |
4.1.2 构建流程
我建议分三步走：
- 收集：从各业务系统、文档、会议纪要里提取高频业务概念。别贪多，先抓核心的50-100个。
- 评审：拉上业务和技术负责人，逐条过。我曾经吃过亏，自己闭门造车搞了一套术语，结果业务部门根本不认。后来改成「业务主导、技术配合」，效果好了很多。
- 发布与维护：术语表不是一次性的。每次有新系统接入，都要走术语对齐流程。
4.2 数据字典设计：从「术语」到「字段」的桥梁
术语表解决的是「业务概念」的统一。数据字典解决的是「技术字段」的标准化。两者缺一不可。
数据字典，说白了就是给每个字段写「身份证」。字段叫什么、什么类型、长度多少、允许为空吗、业务含义是什么，全写清楚。
4.2.1 数据字典的层级结构
我个人习惯把数据字典分成三层：
- 物理层：数据库里的真实字段名、类型、长度。比如
cst_id VARCHAR(32)。 - 逻辑层：业务视角的字段名和定义。比如「客户编号，唯一标识一个客户」。
- 映射层：物理字段和逻辑字段的对应关系。同一个逻辑字段可能对应多个物理字段（不同系统里叫法不同）。
关键点：数据字典必须和术语表联动。每个字段都应该关联到一个业务术语。如果字段找不到对应的术语，要么是术语表有遗漏，要么是字段定义有问题。
4.2.2 字段命名规范
没有规矩，不成方圆。我建议团队统一以下规则：
| 规则项 | 建议 | 反例 |
|---|---|---|
| 命名风格 | 小写+下划线 | camelCase、PascalCase |
| 前缀 | 按数据域缩写 | 无前缀，导致字段归属混乱 |
| 长度 | 不超过30字符 | 超长字段名，可读性差 |
| 保留字 | 避免使用SQL保留字 | 用 order、group 做字段名 |
4.3 数据域与数据主题划分
数据域和数据主题，是元数据管理的「骨架」。它们决定了数据怎么组织、怎么分类、怎么被找到。
4.3.1 数据域：按业务职能切分
数据域是最高层级的分类。通常按企业的业务职能来划分。比如：
- 客户域：客户信息、会员等级、客户画像
- 产品域：产品目录、库存信息、定价策略
- 订单域：订单头、订单行、支付信息
- 财务域：发票、应收应付、总账
- 渠道域：线上渠道、线下门店、合作伙伴
每个数据域应该有一个明确的负责人（通常是业务部门的负责人）。数据域的划分原则是：高内聚、低耦合。同一个域内的数据关联紧密，不同域之间的数据通过标准接口交互。
4.3.2 数据主题：按分析视角聚合
数据主题是数据域下面的细分。它更贴近具体的分析场景。比如「客户域」下面可以有：
- 客户基本信息主题：姓名、性别、出生日期、联系方式
- 客户行为主题：浏览记录、加购记录、购买历史
- 客户价值主题：消费金额、消费频次、会员积分
- 客户服务主题：投诉记录、售后工单、满意度评分
数据主题的划分，我建议遵循「业务事件驱动」的原则。每个主题对应一个核心的业务事件或实体。比如「下单」是一个事件，「客户」是一个实体。
4.3.3 数据域与数据主题的关系
用一张图来展示它们的关系：
4.3.4 划分的实践经验
我在实际项目中总结了几条原则：
- 不要超过7个数据域。人的短期记忆上限是7±2。数据域太多，管理成本会指数级上升。
- 每个数据域下的主题不要超过15个。超过这个数，说明数据域划分可能有问题，需要拆细。
- 允许跨域引用。比如「订单域」会引用「客户域」的客户ID。这是正常的，但必须通过标准接口，不能直接操作对方的数据表。
- 定期审视。业务在变，数据域和主题也要跟着调整。我建议每半年做一次审视。
customer.behavior.purchase_history。这样一眼就能看出数据的归属和用途。
4.4 业务元数据的治理流程
光有定义和分类还不够，还得有流程保证它们落地。我建议建立以下机制：
- 新增流程：任何新数据源接入，必须先过业务元数据评审。术语表、数据字典、数据域归属，一个都不能少。
- 变更流程：字段类型改了、业务含义变了，必须同步更新数据字典和术语表。我曾经遇到过，数据库字段改了，但数据字典还是旧的，导致下游报表全错了。嗯，那次教训挺深刻。
- 审计流程：定期检查数据字典和实际数据库的一致性。自动化脚本跑一遍，不一致的地方标红，限期整改。
- 培训流程：业务元数据不是技术团队自嗨的。要让业务部门也用起来。我建议每季度做一次培训，教他们怎么查术语表、怎么提变更申请。
核心思想：业务元数据管理，本质上是「建立共识」的过程。技术工具只是辅助，真正难的是让不同部门的人愿意坐下来，把定义对齐。我见过最成功的项目，不是工具最先进的，而是业务和技术配合最默契的。
好了，这章的内容就这些。业务术语表、数据字典、数据域与数据主题，这三样东西是业务元数据管理的「三驾马车」。把它们搞扎实了，后面的数据治理工作才能顺风顺水。