随着公司业务的不断扩展，进入大数据平台的业务数据日益增多，数据之间的产出与使用关系变得愈发复杂。元数据血缘的建设是理清这些复杂数据关系的最佳途径，它不仅能够明确数据的来源、流向和变更历史，向用户清晰明了的展示出数据之间的依赖关系，还为数据平台内的数据治理、数据质量和数据安全提供了重要的支持。

在元数据血缘建设的初期，血缘信息分散在数据同步、数据开发、数据应用等各个业务模块。每当用户需要对数据进行改造/治理时，往往需要分别从各业务模块收集数据实体被下游业务方使用或依赖的情况，最终汇总评估改造/治理成本。如果遗漏了某个模块的血缘数据，可能会在改造/治理过程中对下游业务造成不可预见的影响；在数据质量方面，数据平台需要对用户提供数据产出的基线保障，如果无法全局盘点出保障任务的上游链路会导致基线保障不准确，无法将高优资源给到相应的保障任务；在数据安全方面，数据平台需要利用全链路血缘对敏感数据入仓和使用进行监控，防止敏感数据在流转、加工和使用过程中出现未授权访问、违规流转或泄露等风险，确保数据在全生命周期内的合规性和安全性。

因此，我们着手对元数据血缘进行统一收口，推动各业务模块将血缘信息集中上报和采集，汇聚到统一元数据血缘平台。通过对大数据平台内整个数据加工链路的血缘关系进行统一抽象、统一建模和统一存储，使用户和数据平台服务能够从全局视角便捷地洞察和分析数据的加工流转关系，高效的利用元数据血缘。

数据加工链路分为3个阶段：

数据入仓：

埋点数据：主要来源于APP端、WEB端和服务端埋点，这些埋点以消息的方式进行上报，通过实时入仓任务解析后进入到数据平台。

业务数据：主要来源公司各业务平台的业务数据，主要来源于Mysql、TiDB、Boss、Taishan等业务存储，最终将数据同步到Hive/Clickhouse等数据平台存储中。

数据仓内加工：

离线加工：用户可以通过Spark Sql、Spark Jar、Presto Sql、python脚本等方式对仓内数据进行ETL加工。

实时加工：用户可以通过Flink Sql、Flink Jar等方式对仓内实时数据(Kafka)进行ETL加工。

数据应用/数据出仓：

数据应用：业务将最终加工出来的数据应用到各个场景中进行使用，有指标服务、报表平台、AI训练等等场景中。

数据出仓：业务也可以将仓内加工好的数据同步回业务自有的业务存储中，对数据进行再使用。

从上面数据加工链路来看，其实就是大数据平台数据加工的核心链路血缘，从数据入仓开始一直到数据被应用，我们需要对其中每个数据加工的过程都进行解析和获取，从而获取到数据完整的使用链路，使得数据血缘应用场景有更全面和更加精准。

在血缘模型设计层面，我们采用通用性模型架构实现对数据平台全加工链路中多维度血缘关系的覆盖，通过统一范式进行标准化存储，确保模型具备良好的可扩展性和复用性。

经过持续迭代优化，最终沉淀出两套标准血缘模型。当前平台已覆盖的所有血缘类型均可通过该模型体系进行精准描述，为各类血缘关系的规范化管理和高效应用提供统一框架。

模型一：

用于数据加工产出链路，主要用于有明确数据加工的血缘场景，其中source和target是实体对应的点，而builder则是加工逻辑中对应的边，从而构成了完整数据加工血缘；

模型二：

用于2个实体之间的依赖（或者说某一个实体来源于另一个实体），其中target(builder)依赖或者来源于source实体；

有了上面2套血缘模型，我们可以将所有解析到的血缘铺平存储到我们的关系型存储中，后续用于查询和同步图数据库。

数据平台统一元数据血缘的建设与整合自2021年启动，平台根据血缘覆盖的业务场景和粒度差异，分阶段、按需推进血缘体系的完善。随着血缘覆盖范围和细致度的不断提升，平台同步推出了多样化的血缘应用，助力业务用户更加直观、高效地利用血缘信息，全面提升数据治理与业务支撑能力。

根据上图，我们可以将血缘覆盖的历程分为4个阶段：

2021年之前：（血缘混沌时期）

在缺乏统一元数据血缘管理的情况下，表级血缘信息分散存储于各业务方的系统服务中。若需统计某张表的血缘关系，往往需要分别向各业务方的业务数据库逐一查询，过程繁琐且耗时，极大降低了查询效率和使用便捷性。

2021年 - 2023年：（初步建立血缘体系）

从零开始搭建统一的元数据血缘系统，统一采集各业务方的表级数据血缘。平台通过统一的元数据血缘服务，依据血缘模型规范对业务上报的血缘信息进行解析与入库，实现了对表级血缘及引擎执行后字段级血缘的全面覆盖。

在血缘应用层面，数据平台提供了血缘地图和影响分析等功能模块，用户可自主在相关模块中便捷查询和分析数据血缘关系，助力数据流转全链路的可视化与影响追溯。

2023年 - 2024年：（血缘体系的扩展和优化）

依托各业务方上报的表级数据血缘，平台将不同类型的任务通过表级数据血缘进行串联，构建了完整的任务依赖血缘网络，为数据平台的质量基线建设和全链路任务完成情况监控提供了坚实基础。

在字段血缘方面，平台利用基础架构的Sqlscan服务实现了事前解析，无需引擎实际执行SQL即可快速获取字段级血缘信息，显著提升了血缘解析的实时性。

同时，我们高度重视血缘解析的准确性，调研业界最佳实践后，采用血缘样例库机制收集和管理bad case。用户可将存在解析误差的SQL录入样本库，平台根据用户反馈的错误样本进行分析与修正，并将修正后的准确血缘信息同步更新至统一元数据血缘系统，持续提升血缘解析的质量保障。

2024年 - now：（血缘价值的发挥）

随着血缘体系的完善，其在数据治理中的价值日益凸显。依靠完整的全链路血缘和治理策略规则，平台能够识别出大量可治理的资产对象（如数据表、任务等），并通过治理平台推动业务方对这些资产进行清理、归档或优化，从而有效降低存储和计算成本。

在数据安全方面，平台通过字段血缘实现敏感字段标签的自动传递，能够精准标记加工链路中涉及的所有敏感字段。在后续的安全规范场景中，对敏感字段的使用进行拦截和审计，切实保障数据平台的用数安全。

此外，我们还调研并借鉴了业界算子血缘的优秀实践，通过对SQL AST的深度解析与结构化，获得了字段算子血缘。基于此，平台发现并识别出部分重复加工表，后续将借助治理平台推动这些重复加工表的替换与下线，进一步提升数据治理效率。

截止到目前（2025-05-21）：

元数据血缘关系的总数在1472W条，其中包括了24种血缘关系类型，头部的血缘类型主要集中在字段级数据血缘关系、表与基线关系、表级数据血缘关系等；

线上环境，每天平均有超过140W条血缘关系在发生变更，占血缘关系总数的10%。

2021 年初，元数据血缘的采集方式以业务方主动上报为核心模式。我们向业务方提供血缘上报 SDK 工具包与标准化格式规范，支持业务方在服务链路里借助 SDK 完成血缘信息的埋点上报。这些上报的血缘信息会被投递至 Kafka 消息队列，再由元数据系统异步消费处理。实际场景中，多数业务方采用 “操作触发式埋点” 来上报血缘，典型情况是当用户完成某任务的上线操作时，系统会自动捕获并触发血缘信息的上报流程。

优点：

实时性比较高，用户一触发任务上线就可以查询到血缘信息；

实现成本较低，对于业务方只需要加个上报埋点就行；

缺点：

运维困难，一旦发现血缘信息不一致，需要联系相关业务方帮忙触发再上报；

业务新增场景的时候，容易遗漏加上报埋点，导致漏报；

消息中间件偶发消息丢失，导致血缘信息丢失，且无法感知丢失问题；

血缘上报业务方变多之后，不同业务上报血缘容易互相阻塞消息队列，导致消费不及时；

V1版本经过半年运行（2022年），我们针对实际遇到的问题和不足，对元数据血缘采集的质量保障体系进行了全面升级。血缘采集方式由原先的业务方自主上报，转变为由元数据采集服务主动拉取。我们制定了统一的采集接口规范，业务方按规范开发采集接口后，平台即可通过这些接口按需增量拉取指定时间段（startOffset ~ endOffset）内的血缘变更数据。一旦发现血缘信息存在不一致或丢失，可立即按startOffset或指定血缘实体进行补数和对齐，确保血缘数据的完整与准确。

在元数据采集服务中，我们还可根据业务血缘的时效性灵活配置采集频率，并依据业务重要性为血缘上报分配不同优先级队列。新血缘接入仅需配置采集任务和规则，即可实现快速对接和高效管理。

相比较V1版的血缘架构：

针对运维难题，我们实现了血缘采集服务的自运维能力，支持自动触发补数和运维操作，大幅提升了系统的稳定性和响应效率；

相较于传统埋点上报易遗漏的方式，我们直接对接业务方接口，实时查询并同步业务血缘数据库，极大减少了血缘信息遗漏的风险；

针对消息中间件可能导致的数据丢失问题，我们采用接口调用方式获取血缘，并引入同批次采集数据量对比机制，能够及时发现并自动修复消息丢失，保障数据完整性；

除了采集业务方主动上报（执行前）的数据血缘外，我们还从大数据底层HDFS审计日志（执行后）补充采集非SQL类型任务的表级血缘信息，完善了数据表被任务访问的血缘链路；

针对多业务方血缘采集互相阻塞影响的问题，我们引入了分级队列机制，依据业务重要性进行分发和消费，通过队列优先级保障各业务队列的时效性和稳定性：

P0队列 - 消费延迟 < 20s

P1队列 - 消费延迟 < 5m

P2队列 - 消费延迟 < 1h (天级别同步频率任务除外)

在V2版本中，除了持续完善元数据采集服务，我们还引入了大数据底层的基础能力组件。通过这些组件所具备的SQL解析能力及执行引擎的事后日志，我们能够进一步解析出更细粒度的血缘信息，包括字段级血缘、算子级血缘以及UDF使用血缘。所有解析得到的血缘信息，经过统一的血缘模型规范化处理后，最终汇聚到统一的元数据血缘系统中，实现全局一体化管理。

元数据血缘系统采用多种存储中间件进行分层存储和管理，充分利用不同存储的查询特性，针对多样化的业务场景提供高效、灵活的血缘查询能力。

我们在架构演进中除了将元数据采集的方式进行了全面改造，还在原来表级血缘和字段血缘的基础上实现了算子级血缘的解析。

算子级血缘的解析能力主要是解析SQL获得其AST语法树，通过对AST语法树中规则的不断递归和遍历解析出SQL中不同关键字所对应的逻辑，从而获得算子级血缘。

解析过程：

解析结果：

字段计算算子

FROM

JOIN

WHERE

以上SQL解析的案例是按照最简单的SQL加工逻辑所解析的，而在真正数仓所使用的SQL会更加复杂：

WITH临时表；

TEMPORARY VIEW/TABLE临时视图/内存表；

多层嵌套子查询；

我们需要通过解析这些复杂结构中的 CTE 节点，精准提取 SQL 的关键特征，最终将提取的特征按业务含义进行结构化存储，为后续的 SQL 分析、优化和治理提供标准化数据基础。

算子级血缘应用：

在算子级血缘能力落地后，我们对全量生产环境中的 SQL 任务进行了解析与比对，识别出一批存在重复建设的问题模型。典型的重复场景包括 1:1 拷贝、简单条件过滤、字段裁剪等。

针对这些可替换的重复模型，我们制定了相应的治理策略与流程。在治理过程中，借助 AI 大模型自动生成替代 SQL，支持用户一键完成替换操作，并下线原有重复模型的计算任务和数据产出，从而显著节省存储和计算资源，提升整体资源使用效率。

前面所得到的数据血缘基本都是基于对任务SQL解析所得，但是数据平台内还有一部分非SQL类型的任务，这类任务都是代码和脚本，用户可以通过自定义代码和脚本对平台内的数据表进行读写操作。

为了能够解决非SQL任务血缘的问题，平台设计了两种方案来获取数据血缘：

第一种，用户在录入任务信息的同时自主录入血缘信息，来明确该任务的数据血缘，任务方将用户录入的血缘信息上报到统一元数据血缘；

第二种，任务和引擎透传trace_id来关联任务对数据的读写，通过离线计算的方式来获得任务的数据血缘；

以上就是非SQL任务血缘解析的关键流程，为了全面覆盖平台内各类非 SQL 任务的数据血缘，我们采用了以下机制：

TraceID 注入与透传： 在所有任务的运行变量中注入唯一trace_id。底层引擎（oneClient）在执任务实例时，会提取该trace_id并全程透传至其对 HDFS NameNode 的访问环节。

NameNode 日志集成： 通过在 NameNode 访问日志中记录trace_id，实现了任务执行与数据访问的关联。

血缘关联与获取： 利用trace_id将访问日志关联回相应的任务实例，从而解析出任务对数据的读写路径，最终形成血缘信息。

优点：

广泛覆盖： 能够一次性覆盖多种代码和脚本类型任务的数据血缘，无需对任务代码 / 脚本本身进行复杂解析。

实现简化： 直接从访问日志获取血缘信息，简化了血缘采集逻辑。

时效性：

时效性约束： 为确保血缘的时效性，我们基于平台主流任务的执行周期，设定了一个7 天的血缘滚动窗口。系统会对 NameNode 日志中近 7 天生成的、包含trace_id的访问记录进行血缘解析，以补全非 SQL 任务的血缘数据。

弊端： 

事后追溯： 血缘采集具有事后性。任务必须成功运行至少一次后，才能基于其访问日志产生血缘信息。

更新延迟与干扰： 当用户更新任务代码 / 脚本后，需要等7 天滚动窗口结束后才能查询到准确血缘，在此期间，系统可能出现新旧血缘并存的情况，导致血缘关系暂时不准确或产生干扰。

通过对非SQL任务的血缘补充，我们已覆盖约60%的非SQL任务数据链路。新增的血缘信息有助于业务更清晰地了解数据加工流程，并实现更精准的数据治理与问题识别。

随着血缘架构的演进和升级，我们数据血缘建设的核心目标聚焦在两方面：

覆盖度完善： 接入并采集新场景血缘，扩展范围，最终描绘全平台所有业务的数据使用全景图。

质量提升： 此项包含以下三个具体质量方向：

血缘时效性是指血缘信息能够反映数据当前真实依赖关系的时效性程度。它衡量的是从数据实际产生 / 变更，到其血缘关系被准确捕获、更新并可供使用的时间延迟。新鲜度越高，延迟越低，血缘信息越接近实时状态；反之则说明血缘信息滞后严重，可能无法反映当前真实的数据流转情况。

数据血缘：

当前我们对于表级血缘的时效性口径分为两类，一类是SQL类型任务的表级血缘，另一类是非SQL类型任务的表级血缘；

SQL类型任务的表级数据血缘，我们可以通过解析用户在保存任务时所提交SQL获取到表级血缘，确保时效性到秒级（采集频率30sec/次）。

非SQL类型（spark jar、pyspark、shell脚本）任务的表级数据血缘，我们需要在任务实例执行后通过审计日志来获取到表级血缘，所以这类任务的数据血缘时效性为天级（采集频率1day/次）。

由于字段级数据血缘现在都是通过解析SQL进行获取，所以用户在保存SQL任务时，可以直接解析到字段级血缘，时效性也可以做到秒级（采集频率30sec/次）。

应用血缘：

因为应用血缘来源于各个数据应用模块，不同数据应用团队对于血缘时效性的要求不同，得益于我们可以自定义cron表达式来配置血缘采集频率；

例如：

30sec/次：指标血缘、特征血缘等

1hour/次：API血缘等

1day/次：报表血缘

当前我们根据不同的血缘粒度来统计覆盖率，又因为不同类型的任务能够解析到的血缘粒度不同，所以在统计不同粒度血缘的覆盖率时分母也不同。

表级血缘覆率：

在统计表级血缘覆盖率时，我们将血缘分为两大类：一类是在数据清洗、加工、产出流程中形成的数据血缘，另一类则是下游实际应用数据时形成的应用血缘。

表级数据血缘的覆盖率统计以数据平台当前所有正在运行的任务（包括离线ETL任务、出入仓同步任务、流计算任务和Airflow任务）为分母，具备表级数据血缘的任务为分子，目前覆盖率已达到96.81%。

应用血缘则涵盖了数据平台内外各类应用对数据表的实际使用情况，能够帮助下游业务快速定位所依赖的数据表。其覆盖率统计以所有数据应用实体数量为分母（数据集/卡片/报表/指标/API/模型/标签/人群/AI数据/AI模型/特征组），存在表级血缘关系的应用实体为分子，目前应用血缘的覆盖率为68.2%。（由于部分AI应用场景采用HDFS文件方式，导致表级血缘关联存在缺失，覆盖率相对较低）

字段血缘覆盖率：

与表级血缘类似，字段级血缘也分为两大类：一类是在数据清洗、加工、产出流程中形成的字段级数据血缘，另一类则是下游实际应用数据时形成的字段级应用血缘。

字段级数据血缘的覆盖率统计以数据平台当前所有正在运行的任务（包括离线ETL任务、出入仓同步任务、流计算任务和Airflow任务）为分母，具备字段级数据血缘的任务为分子，目前覆盖率仅为54.66%。

而字段级应用血缘由于暂未接入AI类应用场景，分母仅包含五类实体（数据集/指标/API/标签/人群），分子为具备字段级数据血缘的应用实体，当前覆盖率为81.59%。

血缘准确率：

当前血缘准确率的统计主要依托于血缘样本库中积累的案例。

在血缘建设和运营初期，开发者会主动录入部分已知的错误案例，针对这些案例进行修复后，样本库中比较状态不一致的记录会自动结果调整为一致，从而统计和提升血缘的准确率。

随着常见问题的逐步解决，平台进一步向用户开放了血缘样本库的录入权限，用户在日常使用过程中如发现血缘解析结果不符预期，可自主录入错误案例。平台会根据用户反馈及时检查和修复，待与用户达成一致后，将案例比对结果更新为一致。通过不断积累和处理错误案例，持续发现并解决血缘解析中的问题，推动血缘质量的持续提升。

目前我们对于案例的累积数量较少，统计的准确率可能无法客观反映全局准确率，根据当前的案例计算准确率为92.3%；

血缘地图

用户可根据所关注的表或字段维度，灵活查询平台内任意实体的上下游血缘关系，支持链路查找（如A表 → B表链路），帮助用户高效定位目标表或字段在上下游数据流中的应用情况，快速判断其是否被其他数据表引用或依赖，从而提升数据分析与管理的便捷性和准确性。

影响分析

用户可以根据自己想要查询的实体类型（表/字段/任务/指标/数据源/API等等）对其进行上下游血缘的全链路影响分析，当用户想对某一张表进行数据/结构变更的时候，可以使用该功能快速定位下游具体的影响，以及最下层是哪个业务方在使用该实体，其中还提供了一键拉群、一键通知影响责任人等功能，方便用户快速响应；

链路基线保障

针对重要且具有时效性要求的产出任务，用户可灵活配置任务基线保障，并通过任务血缘链路将该任务所有上游依赖任务统一纳入基线管理。这样不仅能够确保高优先级基线任务在高优资源队列中高效执行，还能对其产出时间进行全程监控与预警，从而切实保障高优任务的按时产出和业务连续性。

数据质量检查

用户可为自身产出的数据表灵活配置质量检查规则，实现对数据产出质量的有效把控，并在发现异常时及时阻断下游任务，防止不符合预期的数据被下游误用。在配置质量检查的同时，质量服务会基于数据血缘自动获取表的产出任务信息，精准监控产出任务的完成情况，并合理安排质量检查的启动时机，从而保障数据流转的高质量与安全性。

字段分类分级

在实际业务场景和埋点上报的数据中，往往包含部分敏感字段，这些字段虽然在ODS层已被标记，但在数据仓库内部的使用和加工过程中，敏感字段的管控容易出现缺失。为此，平台安全系统通过字段级和算子级的血缘分析，实现对字段分类分级信息的自上而下传递，对敏感字段进行全流程打标。后续在用户使用相关字段时，平台会结合使用审计和安全规范，持续监控和规范敏感字段的使用行为，从而有效防控数据使用过程中的安全风险。

报表分类分级

平台产出的部分报表包含敏感或机密数据，为保障数据安全，针对这类报表并非所有用户都可直接访问，必须经过严格的流程审批后方可查看。同时，用户每一次的查看行为都会被记录在审计日志中，实现全程可追溯，进一步提升报表使用的安全性。此外，报表的分类分级及安全等级均通过报表-表-字段的血缘关系进行精准标记，确保敏感信息在全流程中的有效管控。

数据治理：

在数据平台的治理活动中，几乎大多数治理规则都使用了元数据血缘。比如，针对无热度或低热度数据的治理，我们常常会遇到一些虽然访问频率低但业务价值极高的数据，这类数据可能用于年报、月报等长周期统计分析。此时，借助数据血缘可以精准识别这些关键数据，防止其在治理过程中被误清理。同时，通过分析数据产出血缘，我们还能发现部分数据表或字段已不再有周期性产出任务写入，对于这些真正闲置的数据，我们会进行治理，以有效降低存储成本；

数据寻主：

在数据平台早期建设阶段，部分数据资产未能严格归属到具体的业务或生产用户，导致后续治理过程中频繁出现无主资产的问题。通过数据血缘分析，可以全面梳理该数据资产的上下游依赖关系，结合其被使用和产出的实际情况，科学地为数据资产归属到相应的业务或责任人。这不仅为后续的数据治理工作提供了有力支撑，也有助于在数据业务口径等问题上快速定位责任归属，提升平台治理效率和数据管理规范性；

1.行级数据血缘解析能力

当前数据治理体系已具备三种粒度的血缘分析能力：表级、字段级和算子级。然而，在血缘体系的完整性上仍存在关键缺口，行级血缘尚未构建完成。

为弥补这一技术短板，我们正在推进埋点血缘的解析能力。该方案基于当前业务埋点统一存储的特点设计：数据平台采用单表聚合存储多个业务埋点，导致下游消费方需通过行级的 event_id 条件进行过滤提取。我们通过解析用户过滤的 event_id，识别各任务实际使用了哪些埋点，从而构建出埋点层级的行级血缘关系。

未来，我们将在埋点血缘的基础上进一步拓展，突破对 event_id 的依赖，逐步实现更广泛的通用行级血缘解析能力，覆盖更多数据使用场景。

2.更广的血缘场景覆盖能力

目前，元数据血缘的覆盖范围主要集中在数据平台及其上下游的直接链路，尚无法在公司层面实现跨业务部门的数据血缘追踪。

以AI训练场景为例，目前仍缺失样本、特征等关键链路的血缘信息，使AI团队在进行模型质量评估或成本治理时面临较大挑战。

此外，在数据平台对上层业务提供的数据应用方面，当前血缘仅覆盖到API、指标等应用层，对于业务部门通过何种服务查询了哪些数据仍属空白，给数据安全审计和后续治理带来潜在风险。

未来，数据平台将逐步打通其他业务部门的血缘链路，扩展血缘覆盖范围，帮助用户从更多视角了解数据的使用状态，从而更有效地管理数据的全生命周期。

1.数仓模型链路治理

随着公司业务的持续扩展，数据平台中的数据模型和加工链路日益增多，重复建设和低效链路的问题也日益突出。这不仅容易误导用户使用数据，还显著增加了数据运营成本。为此，我们希望通过元数据血缘分析对冗余模型和低效链路进行系统治理。在治理过程中，既可统一模型口径，提升数据一致性，又能下线冗余模型（包括数据存储和计算任务），实现数据质量提升与成本优化的双重收益。

2.AI模型训练链路治理

血缘不仅可用于数据仓库模型链路的治理，也适用于AI模型训练流程的管理。通过血缘分析，可以逐层追踪样本、特征、模型等数据的加工关系，构建出完整的AI训练链路血缘图。基于这些血缘信息，AI团队能够更清晰地识别数据的生命周期，例如判断哪些数据可以提前清理，哪些数据已无下游依赖，从而提升数据治理效率。

-End-

作者丨成天呆、warren

对于大数据场景的元数据血缘建设和应用，大家还有什么更好的建议或者更多的应用场景呢？

欢迎在留言区分享你的见解~

转发本文至朋友圈并留言，即可参与下方抽奖⬇️

小编将抽取1位幸运的小伙伴获取JOJO的奇妙冒险 石之海 冷水杯

抽奖截止时间：8月1日12:00

如果喜欢本期内容的话，欢迎点个“在看”吧！