2. 数据血缘基础
在金融数据体系中，数据血缘（Data Lineage）不是一张“好看的图”，而是一套可追溯、可验证、可运营的元数据能力。它回答的核心问题是：一份数据从哪里来、经过了哪些加工、最终被谁使用、如果上游变化会影响哪些下游资产。在监管报送、风控建模、指标口径治理和故障排查中，血缘是连接技术元数据与业务语义的桥梁。
一、核心原理：血缘的本质是“关系+方向+上下文”
数据血缘的最小构成单元是“节点”和“边”。节点可以是表、字段、文件、任务、报表、指标或模型；边表示数据流动或依赖关系，并带有方向。仅有节点和边还不够，金融场景必须补充上下文：加工逻辑、任务实例、时间窗口、负责人、系统环境、敏感级别。否则血缘只能“看”，不能“用”。
从采集视角看，血缘分为三个层次：
- 技术血缘：由 SQL 解析、任务依赖、ETL 日志自动抽取，描述表/字段级流动。
- 业务血缘：将技术节点映射到业务术语、指标、报表和监管口径。
- 运营血缘：叠加任务实例、调度状态、数据质量结果，用于影响分析和故障定位。
关键判断：血缘的准确性不取决于图有多漂亮，而取决于“边”的置信度和可验证性。自动解析的字段级血缘通常需要人工校验或采样比对，否则容易产生“看起来对、实际错”的假血缘。
二、类型与粒度：从表级到字段级，再到指标级
血缘按粒度可分为表级、字段级、指标级和任务级。粒度越细，治理价值越高，但采集成本和维护难度也越大。金融场景中，监管报送和指标口径通常要求字段级甚至指标级血缘；而日常影响分析可先以表级和任务级起步。
| 粒度 | 描述对象 | 典型采集方式 | 金融场景用途 |
|---|---|---|---|
| 表级 | 表与表之间的读写依赖 | SQL 解析、任务依赖、日志 | 影响分析、调度排障 |
| 字段级 | 字段到字段的映射与转换 | SQL AST 解析、列级比对 | 口径追溯、敏感数据追踪 |
| 指标级 | 指标到源字段、报表到指标 | 指标平台元数据、人工映射 | 监管报送、经营分析 |
| 任务级 | 作业、实例、调度依赖 | 调度系统 API、运行日志 | 故障定位、SLA 管理 |
类型上还可分为正向血缘（从源到目标）和反向血缘（从目标回溯源）。正向用于评估变更影响，反向用于问题溯源。两者必须成对建设，否则血缘只能单向使用。
三、方法流程：从采集到可运营血缘
一个可落地的血缘采集流程通常包含以下步骤：
- 资产盘点：识别数据源、表、任务、报表和指标，建立唯一标识。
- 关系抽取：通过 SQL 解析、调度依赖、日志和 API 抽取节点与边。
- 字段映射：解析 SELECT、JOIN、UNION、子查询和函数，生成字段级映射。
- 上下文补全：关联任务实例、负责人、系统、敏感级别和质量结果。
- 校验与发布：通过采样比对、人工确认和规则校验，发布可信血缘。
- 运营与消费：提供影响分析、溯源、变更通知和血缘 API。
-- 字段级血缘解析示例：从 SQL 中抽取目标字段与源字段
INSERT INTO dwd_loan_repay
SELECT
loan_id,
cust_id,
repay_amt,
repay_date
FROM ods_loan_repay
WHERE dt = '${bizdate}';
-- 解析结果（简化）：
-- dwd_loan_repay.loan_id <- ods_loan_repay.loan_id
-- dwd_loan_repay.cust_id <- ods_loan_repay.cust_id
-- dwd_loan_repay.repay_amt <- ods_loan_repay.repay_amt
-- dwd_loan_repay.repay_date<- ods_loan_repay.repay_date实践提示：OpenLineage 通过 Run、Job、Dataset 三类事件模型表达血缘。采集时优先保证“事件完整、命名空间一致、字段映射可解析”，再逐步提升粒度。
四、金融场景中的典型应用与价值
在金融行业，血缘的价值集中在四个方向：
- 监管报送与合规审计：监管要求说明数据来源和加工过程，字段级血缘可快速生成报送链路证据。
- 指标口径治理：当“不良率”“拨备覆盖率”出现口径争议时，血缘可回溯到源字段和计算逻辑。
- 变更影响分析：上游表结构变更或任务下线前，反向血缘可列出受影响报表、模型和接口。
- 故障排查与数据质量：数据异常时，沿血缘快速定位是源系统、加工逻辑还是调度问题。
以某银行信贷指标为例：监管报表中的“逾期贷款余额”来自指标平台，指标又来自汇总表，汇总表来自借据表和还款计划表。若没有字段级血缘，排查一个口径差异可能需要数天；有了血缘，可在分钟级定位到具体字段和任务实例。
常见误区：只建表级血缘就宣称“血缘完成”；忽略字段级映射；不维护命名空间导致同名表冲突；把血缘图当作静态文档，不与调度、质量、变更流程联动。这些都会让血缘沦为“展示品”。
五、复盘：血缘建设的三个关键指标
衡量血缘是否可用，建议关注：覆盖率（核心资产是否纳入）、准确率（边和字段映射是否正确）、消费率（影响分析、溯源、变更通知是否真正被使用）。只有三者同时提升，血缘才能从元数据项目变成数据治理的基础设施。