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

文摘 2024-11-13 12:14 广东

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

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

我们的资产平台支持丰富的数据源类型，借助于强大的元数据采集能力，将所有数据源元数据采集至元数据中心，形成统一元数据湖，其中就包括全链路血缘。基于采集后的原始元数据，数据 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. 数据血缘未来规划

对于血缘的未来规划：全覆盖和血缘价值。

首先，会将血缘能力做得更加标准化，简化血缘的理解和接入；其次，基于标准化，做更高维度的能力开放，让人人都可以贡献血缘；最后，进一步构建更细颗粒的精细化的血缘，比如行级血缘。

近一步挖掘数据血缘在质量、效率、安全方面的价值。

2. 数据资产平台未来展望

火山引擎数智平台 VeDI 旗下 DataLeap 一直致力于打造一套领先的数据资产全链路能力，解决数据资产“管、找、用”的问题，未来期望在集团内部产生更大价值。

我们会构建更完善的元数据，行业里面有主动元数据、大模型等新的理念，结合算法能力挖掘更多元数据，形成统一的元数据知识图谱。持续借助平台能力把数据用好，例如数据资产门户。我们还会基于元数据构建丰富的应用，帮助用户用好这些元数据。

同时也通过火山引擎在 ToB 市场持续输出到行业，能够帮助到有需要的公司，为行业大数据赋能。

以上就是本次分享的内容，谢谢大家。

分享嘉宾

INTRODUCTION

刘浩阳

字节跳动

大数据研发专家

刘浩阳，字节跳动大数据研发专家，有多年的大数据经验，专注于大数据管理、数据服务以及 BI 分析产品等大数据中台化建设工作。

点个在看你最好看

SPRING HAS ARRIVED

旺知识

AI技术最新进展、发展趋势、研发经验、从业经验

最新文章

大语言模型图形用户界面智能体全面综述：背景、架构、数据、模型、评估、应用、挑战

WWW24-大语言模型个性化多模态生成技术：从千篇一律到量身定制

AI Agents 技术栈图谱与分析

智能体信息检索技术：定义、应用、挑战、趋势

学习计算广告，我为什么从推荐系统转向计算广告？

大众汽车，会成为下一个诺基亚吗？

2025年生成式人工智能革命：八大趋势开启智能新纪元！

大推理模型Marco-o1详细解读：开启开放式问题解决新能力

AI在广告投放上的应用正在大爆发

面向检索增强生成应用的最佳搜索和检索技术

历史性一刻！在东南亚，OPPO超过三星

多模态大模型能力评测基准全面综述：理解、推理、生成、应用、趋势

LLM-ESR@NeurIPS 2024: 大语言模型破解推荐系统的长尾难题

17岁高中生写了个神级Prompt，直接把Claude强化成了满血o1。

个性化大语言模型全面综述：背景、定义、分类、基础、技术、评估、数据、应用、挑战

京东探索：大模型在电商搜索中的生成式检索与优化实践

秘塔AI上线"知识库"，他们直接超进化成AI搜索完全体了。

迈向下一代大语言模型驱动的推荐系统：综述与展望

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

川普归来与战后国际秩序的瓦解

多模态移动智能体基础与最新趋势调研：评估基准、核心组件、技术路线、发展趋势

目标导向交互式智能体复杂任务调研：背景、分类、范畴、评估、趋势

川普上台后的赢家和输家

大模型图形用户界面操作智能体(GUI Agents)综述：数据、架构、分类、应用、挑战

AutoGLM-图形用户界面操作自主基础智能体技术详解

川普归来与战后国际秩序的瓦解

苹果语义索引(Semantic Index)技术调研：关键技术、隐私安全、应用效果、发展趋势

解码智能推荐：多模态大模型在网易云音乐的创新应用

智谱AI的AutoGLM后，Google和微软也下场来做“贾维斯”了。

小红书搜索：生成式检索的探索与实践

「深度」学习计算广告，我为什么从推荐系统转向计算广告？

AI自动操作电脑：AutoWebGLM-大语言模型的Web导航智能体技术详细翻译解读

算法工程师的未来之路：大模型还是搜广推？

未来已来：智谱AI的AutoGLM，让智能手机变身你的私人智能体

RLChina2024-AI Agent业界进展和发展趋势：简史、进展、难题、分级、趋势

揭秘Llama 3.1：我如何消化这份92页的AI大模型技术盛宴

朝韩冲突和中东局势

UniIR：通用多模态信息检索模型训练和评测标准

LECCR：多模态大语言模型增强的跨语言跨模态检索技术

黎以战争、美国大选和财政政策

检索增强生成(RAG)与相关技术综述：问题、分类、数据、模型、挑战

首个大推理模型(LRM) - OpenAI o1规划任务能力评测

黎以战争、美国大选和财政政策

大语言模型统一偏好学习技术综述：定义、数据、反馈、算法、评估、趋势

MMSearch：大型模型多模态搜索引擎

2024，平台型互联网公司的增长打法变了

开源语音实时交互新突破：LLaMA-Omni实现大语言模型无缝语音交互

Google广告点击率预估实践经验总结：在线学习、内存优化、模型评估、置信估计、校准预测、特征管理

从穷小子到公司估值10亿，清华小哥的“双杠杆”方法论

分类

时事

民生

政务

教育

文化

科技

财富

体娱

健康

情感

旅行

百科

职场

楼市

企业

乐活

学术

汽车

时尚

创业

美食

幽默

美体

文摘

原创标签

时事社会财经军事教育体育科技汽车科学房产搞笑综艺明星音乐动漫游戏时尚健康旅游美食生活摄影宠物职场育儿情感小说曲艺文化历史三农文学娱乐电影视频图片新闻宗教电视剧纪录片广告创意壁纸头像心灵鸡汤星座命理教育培训艺术文化金融财经健康医疗美妆时尚餐饮美食母婴育儿社会新闻工业农业时事政治星座占卜幽默笑话独立短篇连载作品文化历史科技互联网

发布位置

广东北京山东江苏河南浙江山西福建河北上海四川陕西湖南安徽湖北内蒙古江西云南广西甘肃辽宁黑龙江贵州新疆重庆吉林天津海南青海宁夏西藏香港澳门台湾美国加拿大澳大利亚日本新加坡英国西班牙新西兰韩国泰国法国德国意大利缅甸菲律宾马来西亚越南荷兰柬埔寨俄罗斯巴西智利卢森堡芬兰瑞典比利时瑞士土耳其斐济挪威朝鲜尼日利亚阿根廷匈牙利爱尔兰印度老挝葡萄牙乌克兰印度尼西亚哈萨克斯坦塔吉克斯坦希腊南非蒙古奥地利肯尼亚加纳丹麦津巴布韦埃及坦桑尼亚捷克阿联酋安哥拉