元数据管理：分类、采集与存储选型
元数据管理这件事，说白了就是给数据做「档案」。没有档案的数据，就像没人管的仓库——东西堆了一屋子，真要找的时候啥也翻不出来。我在好几个数据平台项目里都吃过这个亏，后来才慢慢摸清楚，元数据管理得从分类、采集、存储三个维度下手。
元数据分类：技术、业务、管理
我个人习惯把元数据分成三类。这个分法不是拍脑袋想的，是踩过坑之后总结出来的。
| 分类 | 核心内容 | 典型例子 |
|---|---|---|
| 技术元数据 | 描述数据的技术属性 | 表结构、字段类型、分区信息、ETL依赖、数据血缘 |
| 业务元数据 | 描述数据的业务含义 | 指标定义、维度字典、业务规则、数据质量规则 |
| 管理元数据 | 描述数据的管理属性 | 负责人、创建时间、访问权限、生命周期、版本号 |
你想想看，如果只采集技术元数据，业务方拿到数据目录根本看不懂——「字段名叫 cst_id，到底是客户ID还是合同ID？」反过来，只关注业务元数据，开发同学做数据建模时又找不到物理表。所以这三类必须一起管。
我的经验：在流批一体场景下，技术元数据要额外关注「流表」和「批表」的映射关系。同一个业务实体，流处理用 Kafka Topic，批处理用 Hive 表，元数据里必须把这两者关联起来，否则数据对账会非常痛苦。
元数据采集策略
采集策略这块，我踩过的坑最多。一开始我搞了个全量采集，每天凌晨跑一次，结果发现流数据根本来不及——Kafka 的 Schema 一天变好几次，凌晨采集到的信息到中午就过时了。
后来我调整了策略，分三种模式来搞：
- 全量采集：每天一次，针对 Hive、HDFS 这类批存储。凌晨跑，不影响业务。
- 增量采集：每 5 分钟一次，针对 Kafka、Pulsar 这类流存储。只采集变更的 Schema。
- 事件驱动采集：实时监听 DDL 变更，比如建表、加字段、改分区。这个最轻量，也最及时。
嗯，这里要注意：事件驱动采集不能完全替代前两种。为什么？因为有些元数据变更不是通过 DDL 触发的，比如数据文件被手动删了、分区被意外覆盖了。这些情况只能靠全量或增量扫描来发现。
避坑指南：我曾经在一个项目里只用了事件驱动采集，结果某天运维同学手动清理了 HDFS 上的过期分区，元数据系统完全没感知。从那以后，我坚持「事件驱动 + 定时增量」双保险。
元数据存储选型
存储选型这个问题，没有银弹。我见过有人用 MySQL 存元数据，也有人用 Neo4j 图数据库，还有用 Elasticsearch 的。每种方案都有它的适用场景。
我整理了一个对比表，方便你根据实际情况选：
| 存储方案 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|
| 关系型数据库（MySQL/PostgreSQL） | 事务支持好，查询灵活，生态成熟 | 扩展性有限，血缘关系查询慢 | 中小规模，元数据量 < 1000 万条 |
| 图数据库（Neo4j/JanusGraph） | 血缘关系查询极快，支持深度遍历 | 运维成本高，批量写入性能一般 | 大规模血缘分析，数据链路复杂 |
| 搜索引擎（Elasticsearch） | 全文检索快，支持模糊搜索 | 不支持复杂关联查询，更新成本高 | 数据目录搜索，快速定位表/字段 |
| 混合存储（MySQL + ES + Neo4j） | 各取所长，性能最优 | 架构复杂，数据一致性难保证 | 大型企业，元数据量亿级以上 |
我个人比较推荐混合存储方案。MySQL 存基础元数据，ES 做搜索，Neo4j 管血缘。虽然架构复杂了点，但每个组件只做自己最擅长的事，整体效果最好。
注意：混合存储最大的坑是数据一致性。我曾经遇到过 MySQL 里表已经删了，但 ES 里还搜得到的情况。解决方案是引入消息队列，元数据变更先发到 Kafka，下游各自消费，配合幂等处理来保证最终一致。
元数据管理核心流程
下面这张图是我在实际项目中沉淀下来的元数据管理流程，从采集到消费，每个环节都有对应的存储和处理策略。
这个流程的核心思路是：采集不遗漏、存储不混用、消费不卡顿。批数据源用全量采集，流数据源用增量+事件驱动，管理数据源靠定时同步。存储层各司其职，消费层统一对外提供服务。
一个小技巧：在采集层和存储层之间加一个 Kafka 缓冲。元数据变更先发到 Kafka，下游的 MySQL、ES、Neo4j 各自消费。这样即使某个存储组件挂了，元数据也不会丢。我在生产环境用这个方案跑了一年多，基本没出过问题。
流批一体场景下的特殊考量
最后聊几句流批一体对元数据管理的特殊要求。这个我感触挺深的。
- Schema 兼容性：流数据的 Schema 变更频率远高于批数据。元数据系统必须支持 Schema 版本管理，能回溯历史版本，否则流批对账时会发现字段对不上。
- 时间戳对齐：流数据有 event_time 和 process_time，批数据有 partition_time。元数据里要明确标注每个时间戳的含义，不然分析血缘时容易搞混。
- 一致性校验：流批一体最怕的就是「流里有的字段，批里没有」。元数据系统要能自动做字段级的一致性校验，发现差异及时告警。
嗯，这些细节说起来不大，但真遇到问题的时候，每一个都能让你折腾好几天。提前在元数据层面做好规划，后面会省很多事。