在电商场景中 如何树立全链路数据血统

一、数据全链路血统引见

在电商场景中，咱们树立数据全链路血统的外围目的，是对数据从源头到终端全环节启动追踪和控制。

以批发行业举例，数据包括商品数据、物流信息、用户反应等，其全流程包括：

在业务开展环节中，咱们经常会遇到如下疑问：

首先，随着业务的极速开展，数据始终收缩。数据量增大，但数据发生的实践价值在哪里？数据血统则可以协助咱们更好评价数据价值，并在满足业务需求的同时，控制存储计算资源的收缩速度。与此同时，数据血统还能够权衡数仓树立的优劣，并且做好数仓体系化树立。

最后，经过数据血统助力目的体系化树立，保证目的分歧性，防止重复开发。在目的体系化树立中，数据血统可以协助将新增的目的绑定到已有的目的上。

1.处置数据始终收缩的疑问

针对数据收缩的疑问，数据血统可以明白数据流转门路，优化资源性能。血统相关可以准确权衡数仓对业务的价值，成功数据控制，控制资源收缩，并且能够精准地成功影响面评价。

随着业务开展，咱们经常面临模型重构的疑问，比如一些旧表要切换到新表。数据血统剖析可以协助咱们极速定位模型重构的切入点，优化数据处置的效率。基于算子级的血统相关，数据血统可以成功义务的精准回溯优化，缩小数据修复流程期间，缩小错误流传。

在数据分歧性方面，经过全链路血统等手腕，咱们成功了目的从定义到消费消费的完整智能化流程，优化了目的的控制效率，缩小了人为错误。经过血统剖析加解析才干，咱们能识别出重复加工的字段，优化数据流程，从而缩小不用要的资源消耗。

二、如何构建数据血统底座

血统底座是全链路数据血统的基石。接上去，我将从全体架构、品质评价体系和运行层血统三个方面来引见血统底座的树立。

如上图所示，相关图谱中有一些关键特点，如点、边、节点存储和边存储等。

普通数仓加工链路会启动分层，如 ODS 贴源层、DWD 明细层、DWS 汇总层等，最终透传到数据产品的前端页面。

假设用传统的离线数仓来成功以上架构，且有明白相关的表模型，是十分艰巨的。最终，咱们选用了字节自研图数据库来成功血统数据的底层存储。

血统品质是整个全链路血统从运行到通常的最外围评测规范。

举个例子，假设某个业务要基于字段级的血统回溯下游，但是因为血统品质不达标，预期要回溯 10 个义务，最终查进去 11 个或许 9 个，发生肯定误差。

在电商场景中，咱们搭建了一套完整的血统品质度量体系，从血统解析的准确率、成功率、笼罩率、查问才干等维度来度量血统的数据品质，评价血统品质的肥壮水平，并且活期智能化测验血统数据与实践数据流向的分歧性。咱们经过活期巡检机制发现 bad case，并随之更新、迭代对应的血统模块。

运行层血统，与惯例了解的数仓链路血统不同。

关于数据链路血统来说，咱们针对异构数据源的 SQL 启动解析，在数据平台上保养了很多丰盛的元数据，可以更好解析数仓之间的链路相关。但是关于运行层则不同，在电商场景中，咱们保养了很少数据运行，假设逐个推进运行接入全链路血统才干，老本很高。数据流转是从产品页面经过 HTTP 或许 thrift 接口恳求后端服务，经过数据服务层打到数仓底表。

右图将该环节划分层级，经过低代码平台搭建前端页面、业务产品页面、数据产品页面，再经过接口的方式恳求后端服务，最终映射到在 one service 上，构成对应的 API，其底层就是刚才提到的数仓链路的血统。

为了处置业务运行接入老本高的疑问，咱们成功了网关层智能参数上报，经过日志平台以及网关平台、服务平台间的协作，在前端恳求接口时会智能上报 URL refer 参数，再经过日志采集系统把一切前端恳求的日志采集上去，经过荡涤，最终成功运行程序血统的数据采集。

但在整个环节中，咱们会遇到爬虫乱传参数、不传参数等疑问，对血统品质形成污染。为了处置该疑问，咱们经过脚本对域内的爬虫启动补全。经过自定义爬虫脚本，对全域的前端接口启动抓包，交流外部污染的数据。

三、电商场景的血统运行通常

接上去重点引见一下血统运行在电商场景的通常，蕴含新旧表切换、字段口径探查、目的智能化拆解三个局部。

开发人员经常使用 IDE 修正一个方法时，会改方法名、方法的入参以及方法的出参，IDE 则提供代码级的交流才干。

而关于数仓研发人员来说，没有相似的才干可以做切换的操作。普通在重构中，数仓研发人员拿到要切换的表，经过人工查问，失掉切换旧表影响的义务，进而手动拉群，做切换表的通知，下游的接纳人收到信息后，更改义务代码，并启动数据比对，假设发现有疑问须要再与抢先启动沟通，假设没有疑问则上线代码。

基于一站式新旧表切换性能，上述人工操作可以由平台智能成功，大幅降落了切换的上班量，提高了上班效率和品质。

经过平台才干，数仓研发人员只有要在系统中录入旧表信息，以及新旧表的映射相关，就可以智能生成切换后的代码。在生成代码、跑数之后，平台还允许与旧表的历史数据启动比对。对比结果无误的状况下，下游无需做任何调整。除此之外，平台还提供了批量切换的才干，可以同时启动多张表的切换。

关于下游切换者来说，本因因为切换收益不大，造成操作志愿不强。但如今经过平台提供的切换收益量化的才干，如 SLA 和稳固性优化，优化下游切换志愿。

上方引见技术成功。用户输入须要切换的旧表之后，平台经过旧表的产出义务启动解析，失掉语法树文件，并基于语法树文件做裁剪、交流。基于用户输入的新旧表映射相关生成切换后的 SQL，再提交到比对平台，最终成功全体比对。

在这一环节中，用户不宿愿原生代码受到太多破坏，如注释被溶解，或对一些写法形成影响。针对这种状况，咱们会在 SQL 解析前把注释的关键信息保管上去，拿到比对成功的 SQL 之后再做补全，最终把原始义务的 SQL 尽或许相似地提供进去。

作为一名数仓研发人员或 BI 剖析师，经常须要浏览其他人代码，假设代码复杂度高，对读码的专业性要求会比拟高。为处置这个疑问，平台提供可视化页面辅佐转译。

如上图中的例子，将一段 SQL 转译成图的方式，可以更好协助不写代码的角色更好了解这段 SQL。

在大少数经常使用场景中，用户只想看到某个字段，或许某几个字段在义务中的加工逻辑。平台才干成功了在义务中裁剪出所需字段加工逻辑的才干，最终裁剪掉超 90%的有关代码。原本须要从 100 行代码中提取进去某个字段的加工口径，如今借助平台才干，只有要浏览几行代码就可以成功需求。

此外，咱们宿愿将整个数仓链路中分层保养的 SQL 启动溶解。

一个传统数仓链路有 ODS 层、DWD 层、DWM 层、APP 层等等，每层都会保养一段 SQL。用户须要梳理 APP 层的 SQL 外面的某个字段从 ODS 层哪里来的，环节比拟复杂。

基于平台的才干，咱们把 4 个义务的 SQL 先开展成一段大 SQL，再启动内敛，最终变成从 ODS 层溯源到 APP 层的字段。平台内敛之后启动裁剪。代码的开展和收敛，是经过自研的一套语义解析引擎成功，该引擎曾经放开了专利。

目的体系化树立的外围目的就是保证目的的分歧性，防止目的重复树立。

在电商场景中，咱们早期推进目的体系化树立有一个外围的步骤——目的拆解，即把字段关联到录入好的性能信息外面。假设发现绑定已有的衍生目的，则防止了重复树立的上班。

在该环节中，经过启动用户调研，咱们发现，在做拆解的环节中，用户有几个外围环节，如经过字段口径了解字段实在的起源链路，同时还要看字段全体的加工逻辑，再人工用该 SQL 做拆解上班。最后，用户在目的平台外面保养好元信息。运行层的目的开发成功之后，再去评审最终拆解结果的品质。

目的智能化拆解-技术成功

上图为目的智能化拆解-技术成功环节。

第一，工程才干。工程才干底层是字段口径探查的才干，将运行层的目的透传到明细数据层表，同时平台启动单目的粒度的裁剪，裁剪成功之后拿到字段应该绑定的 DWD 表，最终内敛到 DWD 表的极简 SQL，环节中不须要人为查问代码成功逻辑梳理。

第二，底层数据才干。关键是肯定保养好高品质的元数据。在电商场景中，咱们保养了万级别的目的相关，在目的相关中再保养相似于业务过水平量的 SQL 逻辑，如 where 条件。

第三，大模型的才干。基于大模型才干，咱们联合裁剪之后的 SQL、待选 SQL 成功召回。裁剪之后的 SQL，基于元数据及大模型才干，与规定方法论启动婚配，最终把标的元素判别进去。也就是说，研发人员只有要输入新开发的表，就可以知道该表能否存在重复开发的疑问。

判别环节：依据拆解环节找到对应 SQL，原子目的、润色词、期间周期三个元素生成衍生目的，该衍生目的假设存在，就是存在重复开发，假设不存在，则可以在系统里绑定，供应数据运行经常使用。

数据血统底座是优化数据控制效率和数据品质的关键。咱们宿愿能始终优化全链路数据血统的才干，在上文提到的新旧表切换、数仓价值评价、目的拆解等场景中，更好联合大模型等才干优化性能和用户体验，为业务提供更多价值。