文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

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

2024-11-28 14:44

关注

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

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

一、抖音集团血缘整体介绍

1. 整体概览

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

2. 建设背景

图片

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

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

3. 血缘整体链路

图片

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

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

4. 血缘模型抽象

图片

在建设血缘时,该如何抽象模型呢?

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

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

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

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

5. 血缘衡量指标

图片

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

6. 血缘整体生态体系

图片

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

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

二、抖音集团血缘系统架构

1. 血缘系统建设挑战

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

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

图片

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

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. 数据开发场景的应用

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

3. 数据治理场景的应用

图片

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

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

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

四、未来展望

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

1. 数据血缘未来规划

图片

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

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

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

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

图片

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

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

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

来源:DataFunTalk内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯