数据血缘的元数据基础：元数据分类、采集与存储选型

做血缘分析，说白了就是搞清楚数据从哪来、到哪去、中间经历了什么。而这一切的根基，就是元数据。没有元数据，血缘分析就是空中楼阁。我刚开始接触这个领域时，也以为只要把数据流图画出来就行，结果发现连表结构都对不上，更别提追踪字段级别的变化了。

所以这一章，咱们把元数据这个地基打牢。我会从分类、采集、存储三个角度，结合我踩过的坑，把关键点讲透。

元数据分类：别把所有东西都塞进一个篮子

元数据不是铁板一块。你想想看，一个数据仓库里，有表结构、有调度依赖、有数据质量规则、有业务口径说明……这些信息的性质完全不同，混在一起管理，迟早要乱。

我个人习惯把元数据分成三大类：

分类	核心内容	典型例子	血缘分析中的作用
技术元数据	数据系统的物理结构	表名、字段名、数据类型、分区信息、ETL脚本	直接支撑字段级血缘解析
业务元数据	数据的业务含义	指标定义、维度描述、数据字典、业务规则	辅助理解血缘链路中的业务语义
管理元数据	数据生命周期与治理信息	数据所有者、创建时间、访问权限、质量评分	用于血缘治理中的责任归属与合规审计

我在项目中遇到过一种情况：技术元数据里字段名全是英文缩写，比如 cst_id、ord_amt，血缘图倒是画出来了，但业务方根本看不懂。后来我们强制要求每个字段必须关联业务元数据中的中文描述，这才把血缘图从“工程师自嗨”变成了“业务可用的工具”。

元数据采集：主动还是被动？这是个问题

元数据不会自己送上门来。你得想办法把它从各个数据源里捞出来。采集方式我总结为两种：主动采集和被动采集。

主动采集（Pull 模式）

系统主动去数据源拉取元数据。比如定时扫描 Hive Metastore，把表结构信息同步过来。这种方式可控性强，但需要你提前知道数据源在哪。

• 优点：频率可控、数据完整、适合批量处理
• 缺点：对数据源有侵入性、需要适配不同数据源类型
• 适用场景：内部数据仓库、数仓分层表、离线数据源

被动采集（Push 模式）

数据源主动把元数据推送给采集系统。比如在 ETL 任务执行时，通过钩子（Hook）把执行计划、输入输出表信息发送到元数据中心。

• 优点：实时性好、能捕获运行时信息（如实际数据量）
• 缺点：需要改造数据源或任务框架、依赖消息中间件
• 适用场景：实时流处理、任务调度系统、需要精确血缘的场景

我曾经在一个项目中只用了主动采集，结果发现调度系统里的依赖关系根本抓不到——因为调度信息不在数据库里，而在 Airflow 的 DAG 文件中。后来我们加了一个被动采集的 Hook，在任务启动时把上下游关系推送到元数据中心，这才把血缘链路补全。

元数据存储选型：选错了，后面全是坑

元数据存哪？这个问题看似简单，但选错了后面改起来非常痛苦。我见过不少团队一开始用 MySQL 存元数据，结果数据量一上来，查询血缘链路要几十秒，直接废了。

选型时主要看三个维度：数据量、查询模式、关系复杂度。

存储方案	适合场景	优势	劣势
关系型数据库（MySQL/PostgreSQL）	小规模（表数量 < 1000）、简单血缘	成熟稳定、支持事务、易于维护	血缘深度查询性能差、扩展性有限
图数据库（Neo4j/JanusGraph）	大规模、复杂血缘链路、需要深度遍历	血缘查询快（毫秒级遍历多层）、天然适合图结构	运维成本高、非关系型查询弱
搜索引擎（Elasticsearch）	元数据搜索、全文检索、日志类元数据	全文搜索能力强、聚合分析快	不适合复杂关系查询、更新成本高
混合存储（图库 + 搜索引擎 + 关系库）	大型企业级血缘平台	各取所长、灵活扩展	架构复杂、数据一致性维护成本高

知识体系总览

下面这张图把元数据分类、采集方式、存储选型的关系串起来了。你可以把它当作本章的思维导图。

小结

元数据是血缘分析的命根子。分类上，技术元数据是骨架，业务元数据是血肉，管理元数据是标签。采集上，主动和被动要配合使用，别指望一种方式搞定所有场景。存储上，别迷信单一方案，根据你的数据规模和查询模式来选——小规模用关系型，大规模上图数据库，再大就上混合架构。