2、血缘元数据采集：元数据概念、采集范围与策略
好，咱们进入实战环节的第二关。上一章聊了血缘分析能解决什么问题，这一章就得聊聊——数据从哪来？
说白了，血缘分析的基础就是元数据。没有元数据，血缘就是空中楼阁。我刚开始做数据治理那会儿，就吃过这个亏——上来就想画血缘图，结果发现连表结构都没采集全，更别提字段级别的依赖了。嗯，从那以后，我养成了一个习惯：先把元数据采集搞扎实，再谈分析。
2.1 元数据到底是什么？
先别急着背定义。咱们用大白话理解：元数据就是「关于数据的数据」。
你想想看，一张订单表，里面存了订单ID、用户ID、金额、时间。这些是业务数据。那这张表叫什么名字？在哪个库？谁建的？什么时候建的？字段类型是什么？这些描述数据的信息，就是元数据。
我个人习惯把元数据分成三类：
| 分类 | 说明 | 举例 |
|---|---|---|
| 技术元数据 | 描述数据的技术细节 | 表名、字段名、数据类型、分区信息、存储路径 |
| 业务元数据 | 描述数据的业务含义 | 字段的业务定义、指标口径、数据质量规则 |
| 操作元数据 | 描述数据的处理过程 | ETL作业运行时间、调度频率、数据量变化 |
血缘分析主要依赖技术元数据和操作元数据。业务元数据更多是辅助理解，但采集的时候也得带上，不然你画出来的血缘图，别人看不懂。
2.2 采集范围：到底要采什么？
这个问题很关键。采少了，血缘图不完整；采多了，存储和性能扛不住。我见过不少团队，一上来就把所有系统全量采集，结果每天跑十几个小时，还经常把源库拖垮。
咱们聚焦三个核心范围：
2.2.1 表级元数据
这是最基础的。包括：
- 表名、库名、Schema名
- 表类型（内部表、外部表、视图、物化视图）
- 分区信息（分区键、分区数量）
- 存储格式（Parquet、ORC、Avro、CSV）
- 记录数、存储大小
- 创建时间、最后修改时间
为什么要采这些？举个例子：有一次线上数据延迟，我查了半天，最后发现是一张分区表的分区策略变了，但ETL脚本没更新。如果当时采集了分区信息，一眼就能看出来。
2.2.2 字段级元数据
这才是血缘分析的灵魂。字段级别的依赖关系，能帮你精准定位到「哪个字段出了问题」。
- 字段名、字段类型、字段注释
- 是否为主键、外键
- 是否允许为空、默认值
- 字段的上下游依赖（这个后面专门讲）
2.2.3 ETL脚本元数据
这个容易被忽略，但恰恰是故障排查的关键。ETL脚本里藏着字段之间的转换逻辑。
采集内容包括：
- 脚本名称、路径、版本
- 脚本类型（SQL、Spark、Python、Shell）
- 脚本的输入表/输出表
- 脚本的调度依赖（上游任务、下游任务）
- 脚本的最后运行时间、运行状态
我记得有一次排查数据不一致的问题，数据对了好几遍都对不上。最后打开ETL脚本一看，里面有个JOIN条件写错了，把LEFT JOIN写成了INNER JOIN。如果当时采集了脚本的SQL解析结果，这个问题早就能自动发现了。
2.3 采集策略：全量还是增量？
这是个经典问题。我直接说结论：没有的对错，只有适合的场景。
| 策略 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 全量采集 | 首次搭建、元数据量小、对一致性要求高 | 数据完整、逻辑简单 | 耗时长、对源库压力大 |
| 增量采集 | 日常维护、元数据量大、需要高频更新 | 速度快、对源库影响小 | 逻辑复杂、可能漏采 |
| 混合策略 | 大多数生产环境 | 兼顾完整性和效率 | 实现成本高 |
我个人推荐混合策略：每周一次全量，每天一次增量。全量用来兜底，增量用来保证实时性。
避坑指南：我曾经在一个金融项目中，只做了增量采集，结果某天一张核心表被删了又重建，增量采集没感知到，导致血缘图里一直显示旧表。从那以后，我坚持每周至少跑一次全量，确保元数据仓库和源库保持一致。
2.4 采集架构与流程
说了这么多，咱们看看整体架构长什么样。下面这张图是我在实际项目中常用的采集流程：
这个架构看起来简单，但每个环节都有坑。我挑几个重点说说：
2.4.1 采集频率怎么定？
不是所有元数据都需要高频采集。我一般这样分：
- 表结构变更：每天一次增量就够了，变化不频繁
- 分区信息：每次ETL跑完后立即采集，因为分区每天都在变
- ETL脚本：脚本上线时采集一次，平时不用频繁采
- 运行状态：每次任务结束后采集，用于故障排查
2.4.2 采集性能怎么优化？
我曾经遇到一个场景：Hive集群有上万张表，全量采集一次要跑3个多小时。后来做了几个优化：
- 并行采集：按库或按表分区，多线程并发采集
- 只采增量：通过对比上次采集时间，只采有变更的表
- 采样采集：对于超大表，只采元数据不采数据分布
- 缓存机制：对不常变更的元数据做缓存，减少重复采集
information_schema、Hive的metastore。直接从这些系统表拉元数据，比扫描实际表快得多。我一般优先用系统表，实在没有才走API或命令行。
2.5 采集工具选型
市面上有不少现成的工具，但说实话，我建议自研轻量级采集器。为什么？因为每个公司的数据源、调度系统、元数据格式都不一样，通用工具往往需要大量适配工作。
当然，如果你们团队小、时间紧，也可以先用开源工具：
| 工具 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| Apache Atlas | Hadoop生态 | 功能全面、支持血缘 | 部署复杂、性能一般 |
| DataHub | 多数据源 | 现代化、UI好 | 社区版功能有限 |
| Amundsen | 数据发现 | 轻量、易扩展 | 血缘能力弱 |
| 自研采集器 | 定制化需求 | 灵活、可控 | 开发成本高 |
我个人更倾向于自研，因为血缘分析对元数据的格式和粒度要求很高。通用工具采回来的数据，往往还需要二次加工。与其这样，不如一开始就按自己的需求来设计。