火山引擎数据飞轮实践:在电商场景中,如何建设全链路数据血缘?
![火山引擎数据飞轮实践:在电商场景中,如何建设全链路数据血缘?](https://static001.geekbang.org/infoq/ff/ff42faea0365e2291d4a325e7d765216.png)
数据作为新型生产要素,正支撑企业的数智化转型。但企业数字化建设也存在管理成本高、数据产品使用门槛高、数据资产价值不够的问题,其原因在于业务和数据之间没有形成双向良性驱动。
结合新时代企业数字化转型需求,火山引擎基于字节跳动十余年数据驱动的实践经验,对外发布企业数智化升级新范式“数据飞轮”,帮助企业实现数据驱动。
具体来说,数据消费是数据飞轮的核心,通过一个又一个具体业务中的数据消费,在上层“业务应用轮”实现决策科学、行动敏捷,带来业务价值提升;在下层“数据资产轮”,也通过频繁的数据消费和业务收益,有的放矢建设高质量、低成本的数据资产,更好支撑业务应用。
构建扎实的数据资产轮能更好支撑企业上层数据应用。那么,在企业实践中,究竟应该如何做呢?
作为数据资产轮的支撑产品之一,火山引擎 DataLeap 在资产建设治理层面,能提升数据质量,实现效率提升和成本优化。本文将从电商角度出发,聚焦在数据血缘建设层面,具体介绍如何建设血缘底座、电商场景的血缘应用实践。
数据全链路血缘介绍
在电商场景中,我们建设数据全链路血缘的核心目的,是对数据从源头到终端全过程进行追踪和管理。
![](https://static001.geekbang.org/infoq/b0/b03f0d0834d23ffaaf4d64e93cbfc33d.png)
以零售行业举例,数据包括商品数据、物流信息、用户反馈等,其全流程包括:
通过数据采集,如业务日志、埋点、表格、存储;
经过 ETL 数据加工,包括离线和实时两种任务;
再到数据服务中的物理表、逻辑表,以及服务编排;
最后透传到数据应用,比如接口、页面、报表、指标等。
在业务发展过程中,我们常常会遇到如下问题:
首先,随着业务的快速发展,数据不断膨胀。数据量到大,但数据产生的实际价值在哪里?数据血缘则可以帮助我们更好评估数据价值,并在满足业务需求的同时,控制存储计算资源的膨胀速度。与此同时,数据血缘还能够衡量数仓建设的优劣,并且做好数仓体系化建设。
第二,如何做好数仓变更监控?在数仓的日常开发过程中,我们经常会遇到上下游变更,变更后希望能及时、准确地衡量数据变更的影响。由于数据来源变更丰富,需要通过数据血缘将数据变更及时通知下游关联方。
第三,数仓研发提效。我们希望通过数据血缘及时完成表重构,理清字段的来源以及加工口径,并且进行任务精准回溯。
最后,通过数据血缘助力指标体系化建设,保证指标一致性,避免重复开发。在指标体系化建设中,数据血缘可以帮助将新增的指标绑定到已有的指标上。解决数据不断膨胀的问题
针对数据膨胀的问题,数据血缘可以明确数据流转路径,优化资源配置。血缘关系可以精确衡量数仓对业务的价值,实现数据治理,控制资源膨胀,并且能够精准地完成影响面评估。
帮助数仓开发提效
![](https://static001.geekbang.org/infoq/4d/4d73e486e4f93fa21f7632eced3ef960.png)
随着业务发展,我们经常面临模型重构的问题,比如一些旧表要切换到新表。数据血缘分析可以帮助我们快速定位模型重构的切入点,提升数据处理的效率。基于算子级的血缘关系,数据血缘可以实现任务的精准回溯优化,减少数据修复流程时间,减少错误传播。
保障数据一致性
![](https://static001.geekbang.org/infoq/ab/ab0c6a2723b662b6d1acb5b34d36d6b7.png)
在数据一致性方面,通过全链路血缘等手段,我们实现了指标从定义到生产消费的完整自动化流程,提升了指标的管理效率,减少了人为失误。通过血缘分析加解析能力,我们能识别出重复加工的字段,优化数据流程,从而减少不必要的资源消耗。如何构建数据血缘底座
血缘底座是全链路数据血缘的基石。接下来,我将从整体架构、质量评估体系和应用层血缘三个方面来介绍血缘底座的建设。
整体架构
![](https://static001.geekbang.org/infoq/6e/6e75d8e26db8b186b5cc7c11ceb3edfa.png)
整体架构-关系图谱
如上图所示,关系图谱中有一些关键特点,如点、边、节点存储和边存储等。
点(Node):代表各种类型的节点,如指标、任务等
边(Edge):表示节点之间的血缘关系,如数据流向、任务依赖等
节点存储:每个节点类型对应一个或多个图中的点
边存储:节点间的血缘关系通过边来表示,边包含方向和类型信息
一般数仓加工链路会进行分层,如 ODS 贴源层、DWD 明细层、DWS 汇总层等,最终透传到数据产品的前端页面。
如果用传统的离线数仓来实现以上架构,且有明确关系的表模型,是非常困难的。最终,我们选择了字节自研图数据库来实现血缘数据的底层存储。
血缘质量度量体系
血缘质量是整个全链路血缘从应用到实践的最核心评测标准。
举个例子,如果某个业务要基于字段级的血缘回溯下游,但是由于血缘质量不达标,预期要回溯 10 个任务,最终查出来 11 个或者 9 个,出现一定误差。
在电商场景中,我们搭建了一套完整的血缘质量度量体系,从血缘解析的准确率、成功率、覆盖率、查询能力等维度来度量血缘的数据质量,评估血缘质量的健康程度,并且定期自动化检验血缘数据与实际数据流向的一致性。我们通过定期巡检机制发现 bad case,并随之更新、迭代对应的血缘模块。
应用层血缘
![](https://static001.geekbang.org/infoq/4b/4b9f04fa36a8a7cb89a9336dfe83b803.png)
应用层调度链路
![](https://static001.geekbang.org/infoq/c0/c01c337f1294d20be556bae886ccf4ee.png)
应用层数据采集方案
应用层血缘,与常规理解的数仓链路血缘不同。
对于数据链路血缘来说,我们针对异构数据源的 SQL 进行解析,在数据平台上维护了很多丰富的元数据,可以更好解析数仓之间的链路关系。但是对于应用层则不同,在电商场景中,我们维护了很多数据应用,如果逐一推进应用接入全链路血缘能力,成本很高。数据流转是从产品页面经过 HTTP 或者 thrift 接口请求后端服务,经过数据服务层打到数仓底表。
右图将该过程划分层级,通过低代码平台搭建前端页面、业务产品页面、数据产品页面,再通过接口的形式请求后端服务,最终映射到在 one service 上,形成对应的 API,其底层就是刚才提到的数仓链路的血缘。
![](https://static001.geekbang.org/infoq/3f/3fcbb042c6cdb7a8c12924130bcce02f.png)
为了解决业务应用接入成本高的问题,我们实现了网关层自动参数上报,通过日志平台以及网关平台、服务平台间的合作,在前端请求接口时会自动上报 URL refer 参数,再通过日志采集系统把所有前端请求的日志采集下来,经过清洗,最终实现应用程序血缘的数据采集。
但在整个过程中,我们会遇到爬虫乱传参数、不传参数等问题,对血缘质量造成污染。为了解决该问题,我们通过脚本对域内的爬虫进行补全。通过自定义爬虫脚本,对全域的前端接口进行抓包,替换外部污染的数据。
电商场景的血缘应用实践
接下来重点介绍一下血缘应用在电商场景的实践,包含新旧表切换、字段口径探查、指标自动化拆解三个部分。
新旧表切换
开发人员使用 IDE 修改一个方法时,会改方法名、方法的入参以及方法的出参,IDE 则提供代码级的替换能力。
而对于数仓研发人员来说,没有类似的能力可以做切换的操作。一般在重构中,数仓研发人员拿到要切换的表,通过人工查询,获取切换旧表影响的任务,进而手动拉群,做切换表的通知,下游的接收人收到消息后,更改任务代码,并进行数据比对,如果发现有问题需要再与上游进行沟通,如果没有问题则上线代码。
![](https://static001.geekbang.org/infoq/dc/dc31350ed01502a8bbb952dd4bca0ac9.png)
基于一站式新旧表切换功能,上述人工操作可以由平台自动完成,大幅降低了切换的工作量,提高了工作效率和质量。
通过平台能力,数仓研发人员只需要在系统中录入旧表信息,以及新旧表的映射关系,就可以自动生成切换后的代码。在生成代码、跑数之后,平台还支持与旧表的历史数据进行比对。对比结果无误的情况下,下游无需做任何调整。除此之外,平台还提供了批量切换的能力,可以同时进行多张表的切换。
对于下游切换者来说,原本由于切换收益不大,导致操作意愿不强。但现在通过平台提供的切换收益量化的能力,如 SLA 和稳定性提升,提升下游切换意愿。
![](https://static001.geekbang.org/infoq/c9/c9a92813bef6f497d00de8f938dc08bd.png)
下面介绍技术实现。用户输入需要切换的旧表之后,平台通过旧表的产出任务进行解析,获取语法树文件,并基于语法树文件做裁剪、替换。基于用户输入的新旧表映射关系生成切换后的 SQL,再提交到比对平台,最终完成整体比对。
在这一过程中,用户不希望原生代码遭到太多破坏,如注释被溶解,或对一些写法造成影响。针对这种情况,我们会在 SQL 解析前把注释的关键信息保留下来,拿到比对完成的 SQL 之后再做补全,最终把原始任务的 SQL 尽可能相似地提供出来。
字段口径探查
作为一名数仓研发人员或 BI 分析师,经常需要阅读其他人代码,如果代码复杂度高,对读码的专业性要求会比较高。为解决这个问题,平台提供可视化页面辅助转译。
![](https://static001.geekbang.org/infoq/72/72612026f0984aa99ed9d4c2c8f4d194.png)
如上图中的例子,将一段 SQL 转译成图的形式,可以更好帮助不写代码的角色更好理解这段 SQL。
在大多数使用场景中,用户只想看到某个字段,或者某几个字段在任务中的加工逻辑。平台能力实现了在任务中裁剪出所需字段加工逻辑的能力,最终裁剪掉超 90%的无关代码。原本需要从 100 行代码中提取出来某个字段的加工口径,现在借助平台能力,只需要阅读几行代码就可以完成需求。
![](https://static001.geekbang.org/infoq/5c/5cb8d525504585770fb455c16b335fa0.png)
此外,我们希望将整个数仓链路中分层维护的 SQL 进行溶解。
一个传统数仓链路有 ODS 层、DWD 层、DWM 层、APP 层等等,每层都会维护一段 SQL。用户需要梳理 APP 层的 SQL 里面的某个字段从 ODS 层哪里来的,过程比较复杂。
基于平台的能力,我们把 4 个任务的 SQL 先展开成一段大 SQL,再进行内敛,最终变成从 ODS 层溯源到 APP 层的字段。平台内敛之后进行裁剪。代码的展开和收敛,是通过自研的一套语义解析引擎实现,该引擎已经申请了专利。
核心步骤如下:
第一步,对 SQL 算子进行优化,平台功能必须对算子级别 SQL 进行裁剪;
第二步,语法糖溶解,一段 SQL 要不断内敛,基于血缘关系找到上游表,放到替换掉这个实际的物理表名称中,在这个过程中,就会涉及到很多语法糖的溶解,在传统离线数仓里命名很多临时表,平台会进行完整的语法糖溶解;
第三步,基于此加上算子重写,获取关系代数,最终 unparse 成一段 SQL 返回给用户。
指标自动化拆解
![](https://static001.geekbang.org/infoq/5c/5ce9c70fd16b9e54eaf351d80b818914.png)
左图是传统数据指标体系化建设架构,包含配置信息、原子指标、度量、时间周期、修饰词等。每个指标种类不一样,衍生指标来源于原子指标,复合指标来源于衍生指标。
指标体系化建设的核心目的就是保证指标的一致性,避免指标重复建设。
在电商场景中,我们早期推进指标体系化建设有一个核心的步骤——指标拆解,即把字段关联到录入好的配置信息里面。如果发现绑定已有的衍生指标,则避免了重复建设的工作。
在该过程中,通过进行用户调研,我们发现,在做拆解的过程中,用户有几个核心环节,如通过字段口径了解字段真实的来源链路,同时还要看字段整体的加工逻辑,再人工用该 SQL 做拆解工作。最后,用户在指标平台里面维护好元信息。应用层的指标开发完成之后,再去评审最终拆解结果的质量。
![](https://static001.geekbang.org/infoq/1c/1caca06e307db2979d38075f88b5b48b.png)
指标自动化拆解-技术实现
上图为指标自动化拆解-技术实现过程。
第一,工程能力。工程能力底层是字段口径探查的能力,将应用层的指标透传到明细数据层表,同时平台进行单指标粒度的裁剪,裁剪完成之后拿到字段应该绑定的 DWD 表,最终内敛到 DWD 表的极简 SQL,过程中不需要人为查询代码完成逻辑梳理。
第二,底层数据能力。关键是必须维护好高质量的元数据。在电商场景中,我们维护了万级别的指标关系,在指标关系中再维护类似于业务过程度量的 SQL 逻辑,如 where 条件。
第三,大模型的能力。基于大模型能力,我们结合裁剪之后的 SQL、待选 SQL 完成召回。裁剪之后的 SQL,基于元数据及大模型能力,与规则方法论进行匹配,最终把标的元素判断出来。也就是说,研发人员只需要输入新开发的表,就可以知道该表是否存在重复开发的问题。
判断过程:根据拆解过程找到对应 SQL,原子指标、修饰词、时间周期三个元素生成衍生指标,该衍生指标如果存在,就是存在重复开发,如果不存在,则可以在系统里绑定,供给数据应用使用。
总结与展望
![](https://static001.geekbang.org/infoq/fa/fa60e61a3c72a91d8e4c9678f53e624d.png)
数据血缘底座是提升数据管理效率和数据质量的关键。我们希望能不断提升全链路数据血缘的能力,在上文提到的新旧表切换、数仓价值评估、指标拆解等场景中,更好结合大模型等能力优化功能和用户体验,为业务提供更多价值。以上就是本次分享的内容,谢谢大家。
![](https://static001.geekbang.org/infoq/ab/ab530a4272ab814324173f131cbb6648.png)
版权声明: 本文为 InfoQ 作者【字节跳动数据平台】的原创文章。
原文链接:【http://xie.infoq.cn/article/f5c5c6468820cc0ecf8fe0d43】。文章转载请联系作者。
评论