1. 课程导入

在金融行业，数据不是辅助材料，而是资产本身。监管报送、风险计量、反洗钱、客户画像、实时风控、估值定价，每一条业务链路背后都依赖大量数据表、指标、任务和接口。问题在于：当一张报表出现异常，或监管要求追溯某个指标的计算口径时，团队往往只能靠人工翻查调度日志、SQL脚本和邮件记录。这种“事后考古”的方式，正是数据血缘要解决的核心痛点。

一、为什么金融行业必须重视数据血缘

金融数据链路有三个显著特征：长、深、强监管。一笔交易数据从源系统产生，经过贴源层、明细层、汇总层、指标层，最终进入监管报送或管理驾驶舱，中间可能跨越十几个系统、上百个任务。没有血缘，排障就像在黑暗中拆解一台运转中的发动机。

• 监管合规：银保监会、证监会、人民银行对数据来源、加工过程、报送口径有明确追溯要求。血缘是“可解释性”的基础设施。
• 影响分析：修改一张核心表字段前，必须知道下游有哪些报表、模型、接口会受影响，否则一次变更可能引发连锁故障。
• 故障定位：当指标异常时，血缘能快速定位是源数据问题、加工逻辑问题，还是调度依赖问题。
• 数据资产治理：血缘让数据资产从“静态目录”变成“动态地图”，支撑数据质量、成本优化和权限管理。

二、OpenLineage的定位：开放、标准、可扩展

传统血缘方案通常绑定在某个调度平台或数据仓库内部，采集范围有限，元模型私有，跨系统集成成本高。OpenLineage 的出现，试图用开放标准解决这个问题。它定义了一套与平台无关的血缘事件模型，通过统一命名空间、数据集、作业和运行实例，把不同工具产生的血缘信息汇聚到同一张图上。

OpenLineage 的核心定位可以概括为三点：

1. 标准事件协议：用 JSON Schema 定义 RunEvent、DatasetEvent、JobEvent 等事件类型，任何工具都可以按规范发送。
2. 解耦采集与消费：采集端只负责发出事件，后端可以接入 Marquez、DataHub、OpenMetadata 等不同血缘服务。
3. 面向金融级场景：支持列级血缘、运行状态、Schema 变化、数据质量断言等扩展，满足审计和影响分析需求。

下面是一个典型的 OpenLineage 事件片段，展示了作业运行结束时上报输入输出数据集的基本结构：

{
  "eventType": "COMPLETE",
  "eventTime": "2025-03-18T10:22:31.000Z",
  "run": {
    "runId": "9f3c1a2e-7b4d-4c8a-9e01-2f6a8b7c1d23"
  },
  "job": {
    "namespace": "finance.risk",
    "name": "risk_daily_aggregation"
  },
  "inputs": [
    { "namespace": "hive://cluster", "name": "ods.transaction_detail" }
  ],
  "outputs": [
    { "namespace": "hive://cluster", "name": "dws.risk_daily_summary" }
  ]
}

这段事件本身不复杂，但它意味着：无论这个作业运行在 Airflow、Spark、Flink 还是自研调度上，只要按 OpenLineage 规范发送事件，血缘后端就能自动构建出跨平台的依赖关系。

三、课程整体知识框架

本课程围绕“采集”这一核心动作展开，因为血缘价值再高，采不到、采不全、采不准，后续的治理和消费都无从谈起。整体知识框架分为五个层次：

层次	核心内容	关键产出
认知层	数据血缘概念、金融场景价值、OpenLineage 标准模型	建立血缘思维与标准认知
采集层	Airflow、Spark、Flink、SQL 解析等采集方式	可运行的血缘事件采集链路
建模层	命名空间、数据集、作业、列级血缘、Schema 映射	统一、可扩展的血缘元模型
集成层	Marquez、DataHub、OpenMetadata 等后端对接	血缘存储、查询与可视化能力
治理层	影响分析、故障定位、监管追溯、质量监控	血缘驱动的数据治理闭环

可以看到，课程不是单纯讲一个开源工具，而是以 OpenLineage 为纽带，把采集、建模、集成和治理串成一条完整链路。学习完本课程，你应该能够独立设计并落地一套面向金融场景的血缘采集方案。

四、一个典型金融场景：监管指标追溯

假设某银行需要向监管报送“不良贷款率”指标。该指标由多个下游任务计算得出，数据来源于核心信贷系统、还款流水和五级分类表。某天监管反馈指标口径与上期不一致，需要快速定位差异原因。

没有血缘时，排查过程通常是：找到指标负责人，翻看调度任务，逐层向上追问，耗时数小时甚至数天。有血缘时，可以在血缘图中直接展开该指标的上下游链路，查看每个节点的输入输出、运行时间、Schema 变化和最近一次变更记录。

在这个场景中，OpenLineage 采集到的每个 RunEvent 都携带输入输出数据集信息，后端据此构建出从源系统到监管报表的完整链路。当指标异常时，排查路径从“人找数据”变成“图找问题”。

五、常见误区与学习建议

学习本课程时，建议遵循“先跑通、再扩展、后治理”的路径：先用最小采集链路跑通一个 Airflow 或 Spark 作业的血缘上报，再逐步扩展到列级血缘和多平台集成，最后结合 Marquez 或 DataHub 做影响分析和监管追溯。每章都会围绕真实可运行的配置和代码展开，避免停留在概念层面。