3. 元数据采集与注册：元数据分类、采集方式、注册流程
好，咱们进入第三章。这一章讲的是元数据的采集与注册，说白了就是回答三个问题：要采什么？怎么采？采完怎么入库？
我在好几个数据治理项目里都发现，大家容易把精力全放在主数据本身，却忽略了元数据这个“说明书”。结果就是——数据有了，但没人知道它从哪来、怎么用、谁负责。嗯，这章咱们就把这事掰扯清楚。
3.1 元数据分类：技术、业务、管理
元数据不是铁板一块。我个人习惯把它分成三类，就像人的身份证、简历和体检报告——各有各的用途。
| 分类 | 核心问题 | 典型内容 | 谁最关心 |
|---|---|---|---|
| 技术元数据 | 数据长什么样？ | 表结构、字段类型、主键、索引、ETL脚本、数据血缘 | 开发、DBA |
| 业务元数据 | 数据代表什么？ | 业务定义、计算口径、枚举值含义、数据质量规则 | 业务分析师、数据产品经理 |
| 管理元数据 | 数据归谁管？ | 负责人、创建时间、访问权限、版本号、变更记录 | 数据治理专员、安全审计 |
一个容易踩的坑：很多团队只采技术元数据，觉得“字段名都有了还要啥自行车”。但你想想看，业务人员打开数据目录，看到一堆 col_001、col_002，他能用吗？
我曾经在一个制造业项目里，客户说“我们元数据都采完了”。结果一看，全是数据库的 DDL 信息。业务部门问“这个‘成品率’字段到底怎么算的？是下线合格数除以投料数，还是最终入库数除以投料数？”——没人答得上来。这就是缺了业务元数据的典型症状。
3.2 采集方式：推模式 vs 拉模式
元数据怎么从源系统进到数据目录？主流就两种模式。我画了张图，先看整体流程：
3.2.1 拉模式（Pull）
拉模式，就是数据目录主动去源系统“扒”元数据。像爬虫一样，定时扫描数据库的系统表、读取数据字典、调用 API 获取表结构信息。
- 优点：对源系统无侵入，不需要对方配合改造。部署一次，长期生效。
- 缺点：实时性差。你设的扫描周期是每天凌晨2点，那白天新增的表就要等到第二天才能被发现。
我的经验：拉模式适合那些结构相对稳定的系统，比如财务系统、HR 系统。我建议把扫描频率和业务节奏对齐——业务月底结账时，元数据变化最频繁，这时候可以临时提高扫描频率。
3.2.2 推模式（Push）
推模式反过来——源系统主动把元数据变更“推”给数据目录。通常通过消息队列（Kafka、RabbitMQ）或者 Webhook 实现。
- 优点：实时性好。源系统一有变更，数据目录几乎同时收到通知。
- 缺点：对源系统有侵入。需要对方开发推送逻辑，或者安装 Agent。
注意：推模式容易产生“消息风暴”。我曾经遇到一个场景，某个源系统每5分钟全量推送一次元数据，结果数据目录的入库队列直接被打满。解决方案是加一个“变更检测”层——只有元数据真正变化时才推送，而不是定时全量推。
3.3 注册流程：从采集到入库
元数据采集回来，不能直接往库里一塞就完事。得走一套注册流程。我把它拆成5步：
- 元模型定义——先定规矩。你要采集哪些属性？表名、字段名、类型、注释、主键……这些都得在元模型里提前定义好。没有元模型，采回来的数据就是一堆散沙。
- 采集适配器配置——不同源系统，适配器不同。MySQL 用 JDBC 适配器，Kafka 用消息适配器，文件系统用文件扫描适配器。这一步就是“对号入座”。
- 数据采集执行——跑起来。拉模式就是定时任务触发，推模式就是监听消息队列。这一步要关注的是采集效率和失败重试机制。
- 元数据解析与清洗——原始数据往往不干净。比如字段注释里混了乱码、枚举值定义不完整。这一步要做标准化处理，把“脏数据”洗干净。
- 注册入库与版本管理——入库不是覆盖，是“增量+版本”。每次变更都要保留历史版本，方便回溯。我习惯用
valid_from和valid_to两个时间戳来做版本控制。
避坑指南：我曾经在一个项目中，第4步“解析与清洗”做得不够细。结果入库后，业务人员发现某个字段的注释是“//TODO: 待补充”。这种元数据注册了等于没注册。所以，我建议在清洗环节加一个质量门禁——注释为空或包含占位符的，直接打回重新采集。
3.4 三种元数据的采集策略差异
三类元数据的采集方式，其实不太一样。我整理了一张对比表：
| 元数据类别 | 推荐采集方式 | 采集频率 | 典型工具 |
|---|---|---|---|
| 技术元数据 | 拉模式为主 | 每日/每小时 | JDBC Scanner、Atlas Hook |
| 业务元数据 | 推模式为主 | 按需/事件触发 | Webhook、Excel导入 |
| 管理元数据 | 推模式+手动录入 | 变更时触发 | 审批流、LDAP同步 |
为什么技术元数据适合拉模式？因为数据库结构相对稳定，而且你没法要求每个业务系统都给你装个 Agent。但业务元数据就不一样了——业务定义经常变，而且只有业务人员自己知道变了，所以得让他们主动推。
管理元数据最特殊。负责人信息、权限配置这些，很多时候是手动录入的。我见过一个比较好的做法是：把管理元数据的维护入口嵌入到数据目录的审批流里——谁申请了权限、谁审批了、什么时候生效，这些信息自动落库，不需要人工再填一遍。
3.5 注册流程中的版本管理
最后聊一个容易被忽视的点——版本管理。元数据是会变的。表结构改了、字段含义调整了、负责人换了……这些变更如果不记录版本，数据目录就变成了“一次性用品”。
我建议的做法是：
- 每次注册都生成一个 版本号（比如
v1.0.0、v1.1.0） - 保留完整的 变更历史（谁、什么时间、改了哪个字段、旧值是什么、新值是什么）
- 提供 版本对比 功能（两个版本之间 diff 一下，一目了然）
一个小技巧：版本号可以用“主版本.次版本.修订号”的语义化版本规则。主版本：表结构变更（增删字段）；次版本：字段属性变更（类型、注释）；修订号：管理属性变更（负责人、权限）。这样一看版本号，就知道变更的严重程度。
好了，这一章的内容就到这。元数据采集与注册，说白了就是三个字：采、洗、存。分类搞清楚，模式选对路，流程走扎实——数据目录的根基就稳了。