4、血缘元数据采集：元数据来源与采集工具选型
做血缘分析，第一步就是要把元数据捞上来。没有数据，后面全是空谈。
我见过不少团队，上来就搞血缘可视化，结果发现连 SQL 解析都跑不通。为什么？因为元数据采集这步没做好。说白了，你连数据从哪来、经过哪些转换、落到哪张表都不知道，还谈什么影响分析？
4.1 元数据的三大来源
元数据不会自己送上门。你得知道去哪找，怎么找。我个人习惯把来源分成三类：
| 来源类型 | 典型载体 | 采集难度 | 血缘完整度 |
|---|---|---|---|
| ETL 脚本 | Shell、Python、Perl、Kettle 作业 | 中 | 高（需解析 INSERT/SELECT） |
| SQL 解析 | DDL、DML、视图定义、存储过程 | 高 | 极高（字段级血缘） |
| 日志 | 数据库审计日志、调度系统日志 | 低 | 中（表级为主） |
ETL 脚本是最直接的来源。你想想看，数据仓库里大部分加工逻辑都写在脚本里。我在项目中遇到过，有些团队用 Kettle 做调度，作业里全是「表输入→字段选择→表输出」这种组件。解析这类脚本，其实就是在还原数据流动路径。
SQL 解析是获取字段级血缘的关键。视图定义、存储过程、INSERT … SELECT 语句，这些里面藏着字段到字段的映射关系。嗯，这里要注意：SQL 方言差异很大。Hive SQL 和 MySQL 的语法就不一样，解析器得做适配。
日志是兜底方案。当脚本和 SQL 都拿不到的时候，日志能告诉你「谁在什么时候读了哪张表」。虽然粒度粗，但用来做表级影响分析足够了。
4.2 手动采集 vs 自动采集
采集方式就两种：手动和自动。别觉得手动采集过时了，在某些场景下它反而是最靠谱的。
4.2.1 手动采集
说白了就是人肉干活。DBA 或者数据工程师登录到服务器，把脚本、建表语句、调度配置一个个导出来，然后人工整理成血缘关系。
什么时候用手动？
- 项目初期：数据量小，几十张表，手动搞一遍反而快
- 遗留系统：没有版本管理，脚本散落在各个服务器上
- 临时排查：线上出问题了，快速定位某张表的上游
我曾经接手过一个老项目，ETL 脚本全写在 crontab 里，连注释都没有。自动采集工具根本跑不通，最后只能手动把调度依赖梳理出来。虽然累，但梳理完心里踏实。
4.2.2 自动采集
自动采集才是正餐。工具定期扫描代码仓库、数据库元数据表、调度系统 API，自动构建血缘关系。
自动采集的核心流程：
- 扫描：定时扫描 Git/SVN 仓库，拉取最新脚本
- 解析：用 SQL 解析器或脚本解析器提取表名、字段名
- 存储：将解析结果写入血缘元数据表
- 增量更新：只采集变更的部分，避免全量扫描
自动采集的好处是快、准、全。但有个前提——你的脚本和 SQL 得规范。如果脚本里全是动态 SQL、临时表满天飞，自动采集也会翻车。
4.3 采集工具选型
工具选型这块，我踩过不少坑。市面上工具很多，但适合你团队的才是最好的。
| 工具/方案 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| Apache Atlas | Hadoop 生态 | 与 Hive、HBase 深度集成 | 部署重，学习曲线陡 |
| SQLFlow | MySQL、PostgreSQL | 轻量，支持字段级血缘 | 不支持 NoSQL |
| 自研解析器 | 定制化需求 | 完全可控，适配方言 | 开发成本高 |
| 商业工具（如 Informatica） | 大型企业 | 开箱即用，支持多数据源 | 贵，许可证限制 |
我个人习惯这样选：
- 如果团队技术栈是 Hadoop 全家桶，优先考虑 Atlas
- 如果只是 MySQL + 少量 ETL 脚本，SQLFlow 或者自研一个轻量解析器就够了
- 如果预算充足、数据源复杂，商业工具省心省力
核心原则：工具是手段，不是目的。选工具前先想清楚：你要的是表级血缘还是字段级血缘？采集频率是每天一次还是实时？团队有没有能力维护这个工具？
4.4 血缘元数据采集架构
下面这张图是我常用的采集架构。它把手动和自动两种方式整合在一起，形成一个闭环。
这张图里，采集引擎负责从三个数据源拉取原始数据，解析引擎负责提取血缘关系，最后落库。手动采集作为补充，在自动采集覆盖不到的场景下使用。
4.5 采集过程中的常见坑
最后聊几个我踩过的坑，希望能帮你少走弯路。
- SQL 方言问题：同一个 SQL，在 Hive 里能跑，在 Presto 里就报错。解析器必须适配方言，否则解析结果不准。
- 临时表污染：ETL 脚本里大量使用临时表，这些临时表在血缘分析里要不要保留？我的建议是：临时表只作为中间节点，不纳入最终血缘关系。
- 版本管理混乱：脚本改了，但没提交到 Git。自动采集扫不到最新版本，血缘关系还是旧的。这个问题只能靠流程规范解决。
- 性能瓶颈：每天全量扫描几万个脚本，解析引擎扛不住。解决方案是增量采集 + 缓存，只处理变更的文件。
嗯，元数据采集这块就聊到这。记住一句话：采集是基础，基础不牢，地动山摇。把采集做好了，后面的影响分析才能站得住脚。