专栏名称: DataFunTalk

专注于大数据、人工智能领域的知识分享平台。

抖音集团数据血缘深度应用：架构、指标与优化实践

DataFunTalk · 公众号 · 大数据科技自媒体 · 2024-11-10 13:00

正文

导读本文简单介绍了“抖音集团数据资产管理平台”全貌，数据资产管理平台是抖音集团在复杂业务场景中思考的新方向，启发大家对于元数据以及数据资的全新思考。文章重点展开介绍了“抖音集团大数据血缘的演进和应用”部分，让大家以更宏观视角认识血缘，并在如何建设好数据血缘给出建设性的思路。

首先整体介绍下抖音集团的一站式数据资产门户平台。在大数据领域，各大公司通常会开展元数据采集以及数据地图的建设工作，行业内的普遍认知聚焦于“元数据”。而在抖音集团，我们的认知核心在于“数据资产”。其核心点在于，我们发现若要真正服务好用户，单纯依靠原始元数据，难以满足更精准化的找数需求。因此，我们经过全方位的思考，构建了更具系统化的“管、找、用”数据资产平台。以下为抖音集团数据资产管理平台。

我们的资产平台支持丰富的数据源类型，借助于强大的元数据采集能力，将所有数据源元数据采集至元数据中心，形成统一元数据湖，其中就包括全链路血缘。基于采集后的原始元数据，数据 BP 会通过资产管理进行二次上下架、分级分类等管理操作，平台会借助主动元数据手段（Gartner 提出）等，持丰富资产元数据。我们会建立资产评估体系评估资产的完善度，牵引资产不断做好。在消费场景上，我们基于数据资产元数据构建搜索、门户以及推荐等产品化能力，同时结合大模型构建AI搜索，通过多样化产品矩阵满足数据资产元数据消费需求。以上是数据资产平台整体简单介绍。

本次分享将聚焦于资产体系中的全链路血缘，文章将围绕下面四点展开：

1. 抖音集团血缘整体介绍

2. 抖音集团血缘系统架构

3. 抖音集团血缘应用场景

4. 未来展望

分享嘉宾｜刘浩阳字节跳动大数据研发专家

编辑整理｜吃货小八

内容校对｜李瑶

出品社区｜DataFun

抖音集团血缘整体介绍

1. 整体概览

在抖音集团内，对于数据血缘建设的目标是：构建全覆盖、实时、准确的大数据血缘，基于血缘数据打造全场景血缘应用赋能提效。这里我们的认知是：数据血缘是元数据的核心基础能力，如果想致力于打造更高效的数据平台，可提高对于数据血缘的建设重视程度。

2. 建设背景

血缘，即元数据实体之间的关系，也可以简单理解为大数据任务 ETL 的结构化信息。抖音集团内部数据血缘建设背景，可以分为四个方面：

看链路：整个大数据是一个超大的数据链路，集团内有百万级别的任务，需要结合血缘看清楚这些业务之间的关系。
保质量：生产任务每天都在线上迭代，每天有万级别的线上任务变更，该如何评估好这些迭代对线上是否会产生影响，需要结合血缘链路去评估，以保障整个生产的质量。
保安全：安全是企业数据数据的生命线，如何高效发现企业中的敏感数据，需要依赖血缘数据传播能力。
降成本：超大规模集群规模背后是大量的计算、存储资源，如何合理利用资源，并精准发现低价值资源，并驱动治理，也需要依赖血缘实现。

因此，建设好大数据血缘对我们来说迫在眉睫。

3. 血缘整体链路

那么如何建设好一套大数据血缘呢？

简化来看大数据链路：从埋点到消息队列（或者上游的业务 DB），构建离线数仓、实时数仓，数仓加工完后写入到高速存储，提供线上服务或者产品化能力。基于大数据链路，我们需覆盖血缘包括以下三类。粒度上覆盖表级血缘和字段级血缘，其中字段级我们更多提细粒度字段级血缘，包括行级血缘和算子血缘。

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

4. 血缘模型抽象

在建设血缘时，该如何抽象模型呢？

前面介绍到，血缘可以简单理解为关系，那是否把血缘抽象为点和边就能解决血缘的问题呢？如上图示例，表 tb 包含两列，列都来自于表 ta，ta 和 tb 通过任务产生的关系，同时两个表的列也都产生了关系，这是最直接的模型。另外，会发现是这个任务让两个实体产生了关系，所以另外一种模型方式是把任务节点也抽象出来。我们可以通过这两种模型来表达血缘关系，但实际两个模型其实存在差异。

第一个模型：表现更新时会非常慢，一旦任务变更，需要去更新所有任务相关实体节点，但读取会非常高效，因为关系被直接被固化存储；第二个模型：更新非常快，更新任务时只需更新任务相关的关系，但读会非常慢，需推导最终血缘关系。

基于该案例推演，我们设计了更泛化的血缘模型，在模型中抽象三类实体。第一个 DataStore 实体，与通常的 Hive Table 对应；第二个抽象是 Column，由于实体和实体之间存在从属的关系，所以再往下抽象一层即 column，column 可以从属于 DataStore；第三个抽象是 Process，实体与实体通过 task 产生关系，所以抽象出 Process 来表达 task。

通过三类实体产生六类关系：实体和实体的关系（如表和表的血缘关系），列与列的关系（即字段血缘），任务和任务之间的关系等。通过实践验证，该模型能够覆盖到所有血缘关系，在实际存储过程中又考虑到以上两个特点，我们存储了两类模型，写入时使用第二个模型，查询时使用第一个模型，从而满足大数据场景下高效的存储和读取。

5. 血缘衡量指标

我们定义了“血缘质量分”指标来衡量血缘质量，包括三个一级指标，加权后为血缘质量分。抖音集团内部当前血缘质量分处于较好水平，但仍然也需要持续提升。

血缘覆盖率：考虑任务成功解析的数量，覆盖多少任务；
血缘准确率：成功解析并不代表完全正确，会在覆盖基础上近一步排除异常解析的情况。
血缘完整率：成功解析也不一定完整，最终通过完整率来看清楚血缘是否完全覆盖。

6. 血缘整体生态体系

血缘数据重点依赖依赖上游生产任务逻辑或者日志，通过多种接入模式采集，然后通过血缘处理（其中重点是解析）形成统一血缘数据。对外提供血缘分析服务以及血缘应用，包括血缘图谱、口径探查、血缘分析以及基于血缘的各种工具箱，帮助用户方便快捷地使用血缘。借助于血缘开放生态，希望人人能够贡献血缘，人人能够用好血缘。

整套血缘体系有几个特点：覆盖全链路、精细化血缘、准确度非常高、应用场景广泛。

抖音集团血缘系统架构

1. 血缘系统建设挑战

血缘系统建设主要面临如下一些挑战：

首先，如何精准化解析细粒度血缘；
其次，如何覆盖非结构化数据源，比如实时链路中会有 Redis、Kafka 等；
然后，如何覆盖跨 region 的机房血缘；
最后，如何覆盖调用较大的应用端调用血缘。

2. 血缘系统解决方案架构

基于以上四个挑战，我们设计了整套血缘架构。

数据源：覆盖各种上游数据源的有价值信息，包括任务代码、配置信息、离线表以及人工补录的数据。
采集：元数据链路和血缘链路，元数据链路重点关注元信息采集到元数据的体系里面；血缘链路，重点结合解析服务和 Catalog，提取血缘数据；
存储：通过图库存储血缘数据，开源图库有JanusGraph、Neo4j、NebulaGraph 等。离线链路通过图库 Dump 任务到 hdfs，并构建数仓；
分析：通过实时数据和离线数据，以通用的血缘分析服务，支持实时以及离线的分析场景。

3. 统一解析服务

Java 体系中有两个比较出名的解析器：Antlr 和 Calcite。Antlr 是一个词法和语法解析器，能够方便地帮我们解析各种各样语言，变成抽象语法树。Calcite 对 SQL 领域适配较好，SQL 方面定义了 RelNode，和对 SQL 相关的优化规则。

解析是血缘领域非常核心的组件，需要关注支持多种方言，因为生产任务是多样化的，有实时、离线、OLAP、非结构化数据以及更复杂的任务脚本。

这里我们提出的比较理想解析方案是：基于 Antlr+Calcite 的统一解析器，既能覆盖多方言，又能处理复杂脚本，充分利用两个解析器的优势。我们只要定义词法文件和语法文件，通过 Antlr 生成语法树，然后把语法树通过 SQLNode 转换器转换为 Calcite 的 SQLNode，在 SQLNode 和 RelNode 中提取出血缘信息。

4. 血缘接入服务 -生产血缘

上图中是数据生产血缘示例，一张商品表写到下游的一张表。解析器将任务逻辑解析，获取到表与表的依赖关系，比如商品的 detail 表依赖商品表，商品 detail 表里商品的 number 依赖下面表的商品 number。我们会存储几个关键的信息，字段与字段的裁剪掉代码片段，还会将计算算子存储下来，比如先做 aggregate -> select -> where,存到字段的血缘里面，这就是算子级别血缘。

对于 no schema 的任务，需要去查询 catalog 构建血缘信息，catalog 中已提前管理 MQ/Redis 的 meta 信息。对于算子血缘，希望能够尽量全的存储计算信息，会在一些场景使用。

5. 血缘接入服务 -跨 Region 血缘

在集团内部有很多 region，region 之间的数据可能会涉及到一些关联计算，因此需要跨 region 血缘去处理。例如 A、B、C 三个区域的血缘，我们会先在本区域获取 local 血缘，然后发到总线上去构建跨 region 血缘。如果某个区域是一个 global 表，我们会借助某个区域访问 catalog，将 global 表展开到具体 region。

6. 血缘接入服务 -应用血缘

应用端血缘在业界并不常见，是抖音集团血缘的一大特色。我们有非常多的应用端服务和产品，因此希望能够覆盖端到端的血缘关系，实现真正的全链路血缘。所以，我们构建了应用端的血缘。

应用产品大体可以分成两类，第一类就是搭建类，可以通过低代码平台去搭建应用产品，第二类就是定制开发的一些应用产品。这两类都会通过 HTTP 或者 RPC，去调用后端服务。后端服务会调用大数据 oservice（统一数据服务），one service 服务会调用到物理表。另外一种可能是服务会直接调用物理表。

应用产品页面跟后端服务的血缘关系打通几个方案：对于搭建类的产品，借助于低代码的 meta 信息去构建血缘；通过 spider 爬取页面信息，通过页面信息提取出页面和接口的信息；通过 trace 日志，基于一套日志规范，让业务去按照规范打日志，血缘系统中提取日志获取血缘数据。

服务和服务之间的血缘，主要依赖 trace 日志去构建血缘关系。服务和 one service，基于 one service 元信息构建血缘关系。

应用血缘采集过程中面临的关键问题：埋点日志量可能会非常大，我们采取日志聚合或采样来缩小量级；埋点日志不准确，业务方把关系打在日志中，我们称之为染色。

抖音集团血缘应用场景

以上介绍了数据血缘系统的建设思路，接下来介绍血缘在内部具体的应用场景。

1. 血缘应用整体介绍

我们希望能够发挥数据血缘在数据全链路的价值，助力公司降本提效。这里列举了四大应用场景，分别为数据开发、数据治理、数据资产和数据安全，其中一些已经覆盖，还有一些正在建设中。接下来将详细介绍各个场景的应用。

2. 数据开发场景的应用

数据开发场景中的应用主要包括：

数据变更影响面评估：提供全链路任务、表、列的血缘关系查询、筛选和展示，支持切换 select 血缘及 non-select 血缘，帮助用户看清数据之间的关系。
快速查看字段或者指标加工口径：通过血缘能力计算数据开发链路，并根据指定字段进行代码裁剪，只展示该字段相关逻辑，大幅减少无关代码，提高阅读效率。
实时开发任务提效：基于指定任务，使用血缘能力为下游任务链路创建影子链路，提供测试链路数据预览功能及线上数据比对功能，预览最终产品的变动。
精准选择待回溯链路：基于列级别的回溯范围计算，同时支持用户指定首尾节点、根据特征进行二次筛选等，提升回溯的整体效率和准确性。
上游数据变化及时感知：监听元数据埋点变更，根据血缘关系判断影响范围，并实时发送通知，帮助开发人员及时感知上游变更。
数据模型重构高校切换：基于用户配置好待切换模型后，根据血缘计算出待切换任务列表，自动生成切换代码，自动完成数据比对。

3. 数据治理场景的应用

下面重点看数据治理链路应用，数据治理的核心目标是质量、成本、安全。

低价值/风险资产识别：通过血缘发现耗费大量资源、下游使用很少的，低 ROI 的资产，以及一些高风险资产。
成本计算：基于链路级别血缘计算全链路成本。
及时性保障：构建链路级别的时效性保障能力。
准确性保障：检测高风险、高优先级价值的资产质量是否符合预期，是否存在风险。
安全保障：高效发现高密数据，检测安全风险。

对于及时性保障场景。通常大家做及时性保障，可能会做单点保障，比如监控某个任务的完成时间。我们可以充分利用血缘传播能力，当我们发现 6 这个任务是一个非常核心任务时，我们可以优先级传播到整个链路，进而可以提升链路优先级。当要求任务 6 需要 6 点完成，在任务 1 执行时可以预判，任务 6 在 6 点完成是否有风险，进而实现链路预测告警。另外，还可以做跨部门 SLA 签署，比如要保某个任务，需要上游一起保障，就可以通过血缘发现相关资产，然后联合相关部门签署 SA，从而保障整个资产及时性。

对于成本计算场景。在大数据链路里面，我们希望看到每个节点实际的资源成本消耗。例如任务 6 本身消耗资源并不大，但是为了计算 6，需要 12345 这五个任务来辅助计算，那这 5 个任务的成本也要算在 6 的成本上，这时就可以基于血缘关系将成本分摊下去。计算成本是为了能够看清楚资产的计算成本，同时也可以用于评估资产的 ROI，结合治理规则，找到低 ROI 的资产做治理。

未来展望

最后简单介绍一下对未来的设想。

1. 数据血缘未来规划