3、数据血缘的元数据采集：手动采集 vs 自动采集
元数据采集，说白了就是给数据血缘找「原材料」。没有这一步，后面所有的血缘分析都是空中楼阁。我做了这么多年合规审计项目，见过太多团队在采集阶段就栽了跟头——要么采不全，要么采不准，最后画出来的血缘图连自己都不敢信。
这一节，咱们就聊聊采集的两种主流方式：手动和自动。别急着站队，两种方式各有各的用武之地。
3.1 手动采集：什么时候还得靠「人肉」？
你可能会问：都2025年了，还手动采集？嗯，还真有场景绕不开。
典型场景：
- 历史遗留系统——那些跑了十几年的老系统，文档早丢了，ETL脚本散落在各个服务器上，连维护的人都换了好几茬。
- Excel/CSV 手工报表——业务部门用 Excel 拉数据、做汇总，然后通过邮件传来传去。这种「影子IT」产生的数据，自动化工具根本抓不到。
- 非结构化数据处理——比如人工编写的 SAS 脚本、Python 爬虫，没有统一的调度平台。
我记得有一次帮一家银行做合规审计，发现他们有个重要的监管报表，中间有一层数据加工是在一个老同事的本地 Excel 宏里完成的。那个同事已经离职三年了，我们翻了他留下的电脑，才找到那个宏文件。你说这种场景，不手动采集怎么办？
3.2 自动采集：主流方式，但也有坑
自动采集是现在的主流。说白了，就是让工具替你去「翻」元数据。常见的自动采集手段有三种：解析 SQL、抓 ETL 日志、读取数据字典。
咱们重点聊前两种，因为这是实战中最常用的。
3.3 解析 SQL 语句提取血缘
这是最核心、最精准的方式。只要数据加工是通过 SQL 完成的，理论上就能通过解析 SQL 来还原血缘。
基本原理：
- 找到所有 ETL 脚本、存储过程、视图定义中的 SQL 语句。
- 用 SQL 解析器（比如 Calcite、Antlr、sqlparse）把 SQL 拆成抽象语法树（AST）。
- 从 AST 中提取
SELECT子句中的字段来源、FROM子句中的表、JOIN条件、WHERE过滤条件等。 - 建立「源字段 → 目标字段」的映射关系。
举个例子，一条简单的 SQL：
INSERT INTO dws_cust_month_amt
SELECT
a.cust_id,
a.month_id,
SUM(b.txn_amt) AS total_amt
FROM
ods_cust_info a
JOIN
ods_txn_detail b ON a.cust_id = b.cust_id
WHERE
b.txn_date >= '2025-01-01'
GROUP BY
a.cust_id, a.month_id;解析后，我们能得到这样的血缘关系：
| 目标表 | 目标字段 | 源表 | 源字段 | 转换逻辑 |
|---|---|---|---|---|
| dws_cust_month_amt | cust_id | ods_cust_info | cust_id | 直接映射 |
| dws_cust_month_amt | month_id | ods_cust_info | month_id | 直接映射 |
| dws_cust_month_amt | total_amt | ods_txn_detail | txn_amt | SUM 聚合 |
SELECT * 和动态 SQL。解析器碰到这种「模糊引用」基本就废了。我的建议是：先做 SQL 规范检查，把 SELECT * 这种「坏味道」提前暴露出来，否则解析出来的血缘图会有大量「黑洞」。
3.4 利用 ETL 工具日志采集血缘
如果你用的是商业 ETL 工具（比如 Informatica、DataStage、Talend），或者开源调度平台（比如 Airflow、DolphinScheduler），那恭喜你——这些工具本身就会记录数据流动的日志。
采集思路：
- Informatica：它的 Repository 里存着完整的 Mapping 信息，包括 Source、Target、Lookup、Expression 等组件的连接关系。通过查询 Repository 表，可以直接导出血缘。
- Airflow：每个 DAG 的 task 之间有明确的上下游依赖。虽然 Airflow 不直接记录字段级血缘，但通过解析 task 内部的 SQL，可以结合 DAG 结构推断表级血缘。
- DataStage：它的 Job 日志里会记录每个 stage 的输入输出 schema，包括字段名、数据类型、转换规则。
我记得有一次帮一家保险公司做合规审计，他们用了 Informatica 做数据仓库。我直接连上 Informatica 的 Repository 数据库，跑了几个 SQL 查询，就把整个数据仓库的表级血缘给拉出来了。前后不到半天，比手动翻文档快了不知道多少倍。
关键点：ETL 工具日志采集的优势在于「可信度高」——这些日志是工具运行时自动生成的，不是事后补的。在合规审计中，审计师非常看重这一点，因为可追溯、不可篡改。
3.5 手动 vs 自动：怎么选？
我整理了一个对比表，方便你快速决策：
| 维度 | 手动采集 | 自动采集 |
|---|---|---|
| 适用场景 | 遗留系统、Excel 报表、非标脚本 | 标准化 ETL、SQL 脚本、调度平台 |
| 准确性 | 依赖人工，容易出错 | 高，但受限于工具能力 |
| 时效性 | 慢，通常按批次进行 | 快，可实时或准实时 |
| 审计可信度 | 低，难以追溯 | 高，日志天然可审计 |
| 成本 | 人力成本高 | 工具/开发成本高 |
我的建议是：能自动的尽量自动，但别指望 100% 覆盖。一个成熟的血缘平台，往往是「自动为主、手动为辅」的混合模式。自动采集覆盖 80% 的常规场景，剩下的 20% 靠人工补录。
3.6 一张图看懂采集体系
下面这张图，把三种采集方式的关系和流程串起来了：
3.7 实战中的几个关键判断
最后，分享几个我在项目中积累的判断标准：
- 什么时候优先用 SQL 解析？——当你的数据加工 80% 以上是 SQL 时，别犹豫，直接上 SQL 解析。这是精度最高的方式。
- 什么时候靠 ETL 日志？——当你的 ETL 工具本身就有完善的元数据管理功能时（比如 Informatica、DataStage），直接利用它。省时省力，审计还认。
- 什么时候必须手动？——遇到 Excel 宏、Python 脚本、SAS 程序这些「野路子」加工，别指望工具能搞定。老老实实做模板，让业务人员填。