这篇文章主要梳理了抖音集团在数据资产与数据血缘建设上的一些思考和实践。

在大数据领域，多数公司起步于元数据采集和数据地图。但抖音集团真正的落脚点放在了“数据资产”上。

原因很直接：单纯依赖原始元数据，很难满足用户精准找数的需求。 经过系统化设计，团队构建了一套“管、找、用”一体化的资产平台。

这套平台的核心逻辑是，通过强大的元数据采集能力，将各类数据源的元数据统一汇入元数据中心，形成统一元数据湖。

其中，包含了全链路血缘。采集完成后，数据BP（Business Partner）会对资产进行二次上下架、分级分类等管理操作。

平台也会借助主动元数据（Gartner提出的概念）等手段，丰富资产元数据。随后，建立一套评估体系来衡量资产的完善度，牵引资产持续优化。

在消费侧，基于资产元数据构建搜索、门户、推荐等产品化能力，并引入大模型打造AI搜索，用多样化的产品矩阵满足元数据消费需求。

今天的分享，重点聚焦在资产体系中的全链路血缘，主要分为四个部分：

• 血缘整体介绍
• 系统架构
• 应用场景
• 未来展望

01 抖音集团血缘整体介绍

整体概览

抖音集团建设血缘，目标很明确：构建全覆盖、实时、准确的大数据血缘，并基于此打造全场景的血缘应用，赋能提效。

这背后有一个共识：数据血缘是元数据的核心基础能力。 如果想打造更高效的数据平台，就需要在血缘建设上持续投入。

建设背景

血缘说到底，就是元数据实体之间的关系，也可以理解为大数据任务ETL的结构化信息。

抖音集团为什么要建设它？主要可以从四个维度来看：

• 看链路：整个大数据链路过长，集团内有百万级别的任务，光靠人力很难看清业务之间的关系。
• 保质量：线上任务每天都有万级别变更，如何评估迭代对线上是否有影响？需要借助血缘链路来评估，保障生产质量。
• 保安全：安全是企业的生命线。如何高效发现敏感数据？依赖血缘的传播能力，可以快速圈定影响范围。
• 降成本：大规模集群背后是海量的计算和存储资源。如何精准发现低价值资源并驱动治理？同样需要血缘来实现。

所以，建设好大数据血缘，确实是一件迫在眉睫的事。

血缘整体链路

简化来看，大数据链路通常是这样的：数据从埋点流到消息队列或上游业务DB，经过离线数仓、实时数仓加工，再写入高速存储，最终提供线上服务。

需要覆盖的血缘主要包括三类：

• 数据源或数据采集的血缘（埋点血缘）
• 数据生产链路的血缘（实时、离线）
• 应用端的血缘（服务/产品应用）

在粒度上，还要覆盖表级和字段级。字段级中又特别强调细粒度字段级血缘，包括行级和算子级别。

血缘模型抽象

抽象模型时，很多人会先想到把血缘拆解成点和边。但仅这样处理，并不够。

比如一张表ta和表tb，通过某个任务产生关系，同时两表的列也发生了关系。最直接的模型，可能只存表和表、列和列的关系。

但任务节点本身同样关键，不能忽略。

两个模型各有优劣：

• 第一个模型（存边）：更新慢，但因为关系被固化，读取非常高效。
• 第二个模型（存任务节点）：更新快，但每次读都需要推导血缘关系，速度慢。

综合考量后，设计了一个更泛化的模型，抽象出三类实体：

• DataStore（对应Hive Table）
• Column（从属DataStore）
• Process（对应task）

这三类实体产生六类关系，经实践验证可以覆盖所有血缘场景。

为了兼顾读写效率，实际存储时用了两套模型：写入用第二个模型，查询用第一个模型，从而满足大数据场景下的高性能要求。

血缘衡量指标

还定义了一个“血缘质量分”指标，由三个一级指标加权计算：

• 覆盖率
• 准确率
• 完整率

目前内部的血缘质量分处于较好水平，但仍有提升空间。

血缘整体生态体系

整个生态体系可以概括为：依赖上游生产任务逻辑或日志，通过多种接入模式采集，再经过血缘处理形成统一血缘数据。

其中，血缘处理的重点是解析。对外则提供血缘分析服务和应用，包括血缘图谱、口径探查、血缘分析以及各种工具箱。

目标是做到：人人都能贡献血缘，人人都能用好血缘。

这套体系的特点也很鲜明：

• 全链路
• 精细化
• 准确度高
• 应用场景广泛

02 抖音集团血缘系统架构

系统建设挑战

建设一套血缘系统，主要面临四个难点：

• 如何精准解析细粒度血缘
• 如何覆盖非结构化数据源（比如Redis、Kafka）
• 如何覆盖跨Region的机房血缘
• 如何覆盖调用量巨大的应用端血缘

解决方案架构

针对这些挑战，团队设计了整套架构。

数据源覆盖各类上游信息，包括任务代码、配置、离线表以及人工补录的数据。

采集阶段分为元数据链路和血缘链路。血缘链路结合解析服务和Catalog提取血缘信息。

存储层采用图库（开源方案如JanusGraph、Neo4j、NebulaGraph等）。离线链路通过图库Dump任务到HDFS并构建数仓。

分析层则通过实时和离线数据，以通用血缘分析服务支持各类分析场景。

统一解析服务

解析是血缘领域最核心的组件。

Ja va生态里有两个明星解析器：Antlr和Calcite。Antlr擅长解析各种语言，能将代码变成抽象语法树；Calcite则对SQL领域适配更优，定义了RelNode及相关优化规则。

理想方案是结合二者的优势：用Antlr处理多方言，用Calcite处理复杂脚本。

具体做法是：

• 通过Antlr生成语法树
• 再通过SQLNode转换器转为Calcite的SQLNode
• 最后从SQLNode和RelNode中提取血缘信息

生产血缘接入

以商品表写入下游表为例，解析器将任务逻辑解析后，可以获取表与表的依赖关系，以及字段级的依赖关系。

比如商品detail表依赖商品表，detail表中字段number依赖商品表字段number。

不仅存储字段映射关系，还会将计算算子，如aggregate、select、where，存储下来，形成算子级别血缘。

对于No Schema的任务，需要查询Catalog来构建血缘。Catalog中已提前管理了MQ、Redis的Meta信息。

跨Region血缘

集团内部有多个Region，数据之间难免跨Region关联计算。

处理方式是，先在各Region获取本地血缘，再发到总线上构建跨Region血缘。

如果某个Region存在Global表，则借助该Region的Catalog将Global表展开到具体Region。

应用血缘

应用端血缘是抖音集团血缘体系的一大特色。目标是实现真正的端到端全链路血缘。

应用产品大致分两类：

• 搭建类（通过低代码平台构建）
• 定制开发类

它们通过HTTP或RPC调用后端服务，后端则调用One Service或直接调用物理表。

为了构建页面与后端服务的血缘关系，主要采用了几个方案：

• 搭建类产品借助低代码平台的Meta信息
• 通过Spider爬取页面信息提取接口关系
• 通过Trace日志，按照统一规范让业务打日志

服务之间的血缘，也主要依赖Trace日志。

应用血缘采集的难点主要在两点：

• 埋点日志量巨大，通过聚合或采样解决
• 日志不准确，通过“染色”机制解决

03 抖音集团血缘应用场景

前面讲了建设思路，接下来看看实际怎么用。

应用整体介绍

团队希望发挥数据血缘在数据全链路的价值，助力降本提效。

当前主要覆盖四大场景：

• 数据开发
• 数据治理
• 数据资产
• 数据安全

数据开发场景的应用

• 数据变更影响面评估：提供全链路任务、表、列的血缘查询和筛选，支持切换Select与Non-Select血缘，帮用户看清数据关系。
• 快速查看字段/指标加工口径：基于血缘能力，只展示与指定字段相关的逻辑代码，大幅减少无关代码，提升阅读效率。
• 实时开发任务提效：为下游任务创建影子链路，提供测试链路数据预览及线上比对功能。
• 精准选择待回溯链路：基于列级别的回溯范围计算，支持用户指定首尾节点并进行二次筛选。
• 上游数据变化及时感知：监听元数据变更，根据血缘判断影响范围，实时发送通知。
• 数据模型重构高效切换：根据用户配置，自动计算待切换任务列表并生成切换代码。

数据治理场景的应用

数据治理的核心目标是质量、成本、安全。

在血缘的加持下，相关能力包括：

• 低价值/风险资产识别：发现耗费大量资源但下游使用很少的资产，以及高风险资产。
• 成本计算：基于链路级别血缘计算全链路成本（例如：任务6本身不贵，但为了计算它需要跑任务12345，这些成本也要分摊过来）。
• 及时性保障：当某个核心任务需要6点完成时，可以利用血缘传播能力，在任务1执行时就能预判整个链路能否按时完成，实现链路级预测告警。同时还能做跨部门SLA签署。
• 准确性保障：检测高风险、高优先级资产的质量是否符合预期。
• 安全保障：高效发现高密数据，检测安全风险。

04 未来展望

数据血缘未来规划

对于血缘的未来，重点在“全覆盖”和“价值挖掘”上。

• 将血缘能力标准化，简化接入和使用
• 基于标准化做更高维度的能力开放，让人人都能贡献
• 构建更细颗粒的精细化血缘，比如行级血缘

进一步挖掘血缘在质量、效率、安全方面的潜力。

数据资产平台未来展望

未来，平台将致力于打造更完善的数据资产全链路能力。

行业里流行主动元数据、大模型等新理念。团队希望结合算法能力，挖掘更多元数据，形成统一的元数据知识图谱。

再借助平台能力，如数据资产门户、丰富的应用，把数据真正用起来。