OpenLineage 开放血缘标准：从事件模型到平台对接

建设血缘平台时，最大的坑往往不是解析不出来，而是每个引擎、每个调度器导出的血缘格式各说各话：Spark 有 SparkListener 事件，Airflow 有任务实例上下文，Flink 有 JobGraph，SQL 引擎有各自的执行计划输出，血缘数据到了平台侧要写 N 套解析器、维护 N 套映射。OpenLineage 要解决的正是这个问题——它不是又一个血缘工具，而是定义血缘元数据"以什么格式、走什么协议、由谁发出、由谁消费"的开放标准。本文聚焦标准协议层本身：事件模型、facets 扩展机制、事件类型，以及自研血缘平台如何对接。至于如何从 SQL 与任务日志中解析血缘、如何把血缘自动化实施，属于采集解析与实施层面，与本文互补，本文不再展开。

为什么需要开放血缘标准？核心是互操作。血缘要能跨工具链贯通，就必须让数据生产者（调度器、计算引擎、数据集成工具）和消费者（元数据平台、数据治理平台）之间有一份共同语言。没有标准时，血缘要么绑定在单一商业工具里，要么为每个引擎写私有解析器；换一个调度器或新增一个引擎，血缘链路就断一截。OpenLineage 由开源社区维护，把这份共同语言公开出来（官方文档），让引擎接入一次、平台消费一次，从而摆脱工具绑定与供应商锁定，也为审计与合规场景提供了统一的证据格式。

OpenLineage 的事件模型由三个核心实体组成：job、run、dataset。job 是"做什么"，一个有名字的任务定义，例如一个 Spark 应用或一条调度 DAG 中的任务；run 是 job 的一次具体执行，用 runId（UUID）唯一标识，同一个 job 每运行一次就产生一个新的 run；dataset 是"数据是什么"，即输入与输出的表、文件或主题。三个实体都挂在命名空间（namespace）之下，命名空间是解决命名冲突和标识来源系统的关键：例如数据库表可以表示为 postgres://host:5432/mydb.schema.orders 这样的命名空间加名称组合，对象存储文件用 s3://bucket/path 表达。没有统一命名空间，同一张表在不同任务里会被记成两个互不相通的 dataset，血缘图直接断链——这是对接时最容易翻车的地方。

facets 是 OpenLineage 的扩展机制，也是它能保持"标准可演进"的关键。每个实体可以挂若干 facets，每个 facet 是一组键值结构，描述该实体某一方面的属性：dataset 可以带 schema facet（字段列表与类型）、ownership facet（负责人）、columnLineage facet（字段级血缘）；run 与 job 也各有对应 facet 描述运行参数、代码版本等信息，数据版本变化通过 version 字段表达。官方定义了一批标准 facet，厂商和平台可以在此基础上自定义扩展 facet，这让标准既能覆盖通用场景，又不必为了某个私有能力修改协议本身。理解 facets 对自研平台的意义在于：标准字段是"保底"，扩展字段是"平台差异化的空间"。

事件按语义分为运行事件与作业事件两类。运行事件描述 run 的生命周期：START 表示开始执行，RUNNING 表示进行中，COMPLETE 表示成功结束，FAIL 与 ABORT 表示失败或中止；对应的作业事件（如 JOB_START、JOB_COMPLETE）描述 job 维度的状态变化，两者配合可以还原"哪个任务在什么时间以什么结果运行了"。一个容易忽略的细节是：START 事件发出时，输出 dataset 的 schema 通常是未知的，只有到 COMPLETE 事件时输出 schema 才确定下来，所以消费端不能只依赖 START 事件建立输出血缘。

事件通过 HTTP 传输，生产者把 JSON 事件 POST 到接收端，标准端点形如 /api/v1/lineage。官方维护了 Java 与 Python 客户端，以及 Airflow、Spark、dbt 等主流集成，方便各类引擎按统一格式上报。消费端方面，Marquez 是典型的 OpenLineage 消费实现：它接收事件、落库、构建血缘图并提供查询 API，很多平台以它为参考实现来设计自己的存储与展示层。也就是说，OpenLineage 只负责"事件怎么长、怎么传"，具体存哪里、怎么展示，由消费端决定。

自研血缘平台对接 OpenLineage，落地路径可以拆成五步。第一步埋点：在任务调度器与计算引擎的执行生命周期中接入官方客户端或自行构造事件，确保每个 run 都有 START 与 COMPLETE 或 FAIL 事件；第二步传输：实现或复用 HTTP 端点接收事件，要处理认证、限流与失败重试；第三步事件规范化：这是最花力气的一步，把各引擎上报的命名空间、job 名称、dataset 名称统一成平台内的规范命名，并补全缺失的 facets；第四步入湖：将规范化后的事件按原始 JSON 与解析后结构分别存储，原始 JSON 用于追溯与重放，解析后结构用于查询；第五步消费与展示：在元数据平台上把事件还原成血缘图、字段级血缘与影响分析。袋鼠云的 MetaDataAssets 元数据资产管理平台正是这类消费端，它覆盖资产盘点、元数据管理、血缘分析与数据质量能力，可承接标准化血缘元数据的消费与展示，支持字段级血缘可视、变更影响评估与问题溯源，自研平台可以按同样的"事件消费、归一化、展示"结构设计。

常见失败模式集中在三处。一是事件丢失：HTTP 传输失败后没有重试、进程崩溃导致 COMPLETE 事件永远缺失，血缘图上会出现大量"只有输入没有输出"的悬挂任务，解决方案是发送端加本地缓冲与重试、接收端提供幂等写入；二是命名不一致：同一张表在不同任务中的 namespace 写法不同（比如一个带端口一个不带），导致 dataset 被拆成多个实体，需要在规范化层做别名归并；三是 run 生命周期不完整：只收到 START 没有 COMPLETE，schema 与输出血缘无法建立，要在埋点层保证事件成对发送并做对账告警。

用一个例子说明事件怎么串成血缘。假设一个 Spark 作业每天凌晨从表 A 读数据、加工后写入表 B：作业启动时发出 START 事件，runId 记为 r-1，事件里带输入 dataset（A 的 schema facet）与 job 定义；执行中可发 RUNNING 事件；结束时发出 COMPLETE 事件，此时输出 dataset（B 及其 schema facet）才被带上，输入与输出通过同一个 runId 关联到同一个 job。消费端把 A、B 通过 job 与 run 连起来，就得到一条"A 加工到 B"的血缘边；如果另一个作业又从 B 读数据写 C，两条边共享 B 这个 dataset，血缘图自然延伸。字段级血缘靠 columnLineage facet 表达，schema 变化靠 version 追踪。这解释了为什么事件成对、命名统一比解析算法更重要——协议层的数据质量直接决定血缘图的完整性。

下一步建议：先选择一个引擎（推荐 Spark 或 Airflow）接入官方客户端，在测试环境跑通"事件发送、接收、入库、展示"全链路，用真实作业验证事件成对率与 dataset 命名一致性，再逐步扩展到其他引擎，最后把命名规范固化为团队内部的数据标准。