火山引擎DataLeap：数据血缘架构演进以及未来展望

DataLeap是火山引擎数智平台VeDI旗下的大数据研发治理套件产品,帮助用户快速完成数据集成、开发、运维、治理、资产、安全等全套数据中台建设,降低工作成本和数据维护成本、挖掘数据价值、为企业决策提供数据支撑。

数据血缘是帮助用户找数据、理解数据以及使数据发挥价值的基础能力。基于字节跳动内部沉淀的数据治理经验,火山引擎DataLeap具备完备的数据血缘能力,本文主要讲述架构演进以及未来趋势展望。

接下来介绍血缘架构的演进。

第一版血缘架构:建立血缘基本能力,初探使用场景

(图:第一版血缘架构)

●在数据来源方面,目前血缘主要包括两个数据来源(见上图左上角):

○第一,数据开发平台:用户在开发平台写任务,并对数据加工,由此产生血缘数据。

○第二,追踪数据:第三方平台(即任务平台)对用户埋点等数据进行计算,也会产生血缘信息。

●在血缘加工任务方面(见上图中间部分):

这部分会对任务进行血缘解析,产生血缘快照文件。由于第一版采用离线方式运行,每天该血缘任务均会生成对应的血缘快照文件。我们通过对比前后两天的血缘快照文件,来获取血缘的变更情况,然后把这些变更加载到图中。

除此之外,血缘中涉及的元数据会冗余一份,并存储到图里。

●在血缘存储方面(见上图右边部分),除了图数据库之外,血缘本身也会依赖元数据的存储,如 Mysql 以及索引类存储。

●在血缘消费层面,第一版只支持通过API 进行消费。

最后总结该版本的三个关键点:

●血缘数据每天以离线方式全量更新。

●通过对比血缘快照来判断血缘更新操作,后面将为大家详细解答为什么要通过对比的方式。

●冗余一份元数据存储到图数据库中。

(图:第一版存储模型)

图中上半部分为表级血缘,只包括一种类型节点,即表节点,比如Hive 表、 ClickHouse 表等。

图中下半部分为字段血缘,第一版主要是提供构建血缘的基本能力,因此用彼此分离的两张图来实现。由于血缘中元数据进行了冗余,每个图里面的每个节点里面都存储表相关的元数据,包括业务信息以及其他信息。

除此之外,我们会预先计算一些统计信息,保存到图的节点中,如当前节点下游总节点数量、下游层级数量等。

采用预先计算的目的是为了“用空间换时间”,在产品对外展示的功能上可能要露出数据信息,如果从图里实时查询可能影响性能,因此采用空间换时间的方式来支持产品的展示。

第二版血缘架构:血缘价值逐步体现,使用场景拓宽

(图:第二版血缘架构)

经过1年的使用,血缘在数据资产中的价值逐步体现,且不断有应用场景落地,由此我们进行了第二版本升级。升级点具体包括:

●第一,去除第一版本中元数据冗余。元数据冗余在图提升了性能,但是可能导致 Metadata Store 的元数据不一致,给用户带来困扰。

●第二,去掉了预计算的统计信息。随着血缘的数据量增多,预计算的信息透出不能给很好辅助用户完成业务判断,且导致任务负担重。比如,即使知道某一节点的下游数据量,还是要拉出所有节点才能进一步分析或决策。

●第三,支持一条全新链路,在新增链路上,我们把血缘快照文件导入离线数仓,主要应用于两个场景:

○离线分析场景或全量分析场景。

○基于离线数仓的血缘数据实现数据监控,尽早发现血缘异常情况。

因此,从第二版开始,数据血缘新增了很多离线消费方式。

(图:第二版存储模型)

第二个版本引入了全新血缘存储模型(如上图所示),并将第一个版本两张图融合成一张图,解决了无法通过表遍历字段血缘的问题。

除此之外,第二个版本还引入了任务类型节点,服务于以下三种遍历场景:

●单纯遍历数据血缘,即从数据节点到数据节点。

●数据血缘和任务血缘混合方式。

●单纯任务之间血缘关系。

第三版血缘架构:血缘成为数据发挥价值的重要基础能力

(图:第三版血缘架构)

2021年初,火山引擎DataLeap数据血缘迭代到第三版,也成为公司内部数据发挥价值的重要基础能力。

服务于业务方对数据高质量要求,第三版升级点如下:

●血缘数据来源:除了支持两个平台之外,还支持包括报表、第三方用户画像等其他平台 。

●血缘任务:之前版本只支持每天定时运行的离线调度方式,第三版引入实时消费方式,支持实时解析血缘,并提取通用逻辑,复用离线血缘任务和实时血缘任务。

●血缘解析:不同类型任务需要使用不同解析逻辑。在之前版本中,Hive SQL 任务和Flink SQL任务的解析逻辑是集成到血缘任务中。从第三版开始,我们把解析服务拆解成可配置的插件,实现了插件化。当某一种任务类型的血缘解析逻辑需要调整的时候,只用改动其中一个解析服务,其他解析服务不受影响,同时也让血缘任务更好维护。

●元数据存储统一:只依赖图数据库和索引存储,同时支持从系统中把所有相关的数据导出离线数仓。

●实时消费:血缘发生变更的信息会被同步到消息队列。

●血缘的验证模块:使用方对血缘数据质量有高要求,因此第三版引入新的血缘的验证模块。

○验证的前提是要有引擎埋点数据,该埋点数据能清楚知道某一个任务具体读取数据情况、写入数据情况

○在离线数仓中,通过埋点数据与血缘数据中对比,生成血缘数据质量报表。

○数据质量报表对血缘消费者开放,消费者能够清晰了解每个血缘链路准确性和覆盖情况。

●血缘标准化接入:即让用户快速接入数据,不用每一种血缘接入都重复写逻辑。

(图:第三版存储模型)

第三版血缘存储模型相对于前两版的升级点如下:

●以任务为中心。黄色圆圈为任务节点,数据加工逻辑产生血缘,因此我们把数据加工逻辑抽象为任务节点,血缘的建立则以任务为媒介,任务成为血缘中心。也就是说,表1、表2、表3之间的血缘,是通过任务 a 完成构建。假设没有任务 a ,则三个表之间的血缘也不存在。

●表血缘和字段血缘模型统一,在字段血缘之间没有具体任务的情况下,我们会抽象出虚拟的任务来统一模型。由此,任务和任务之间的血缘采用新的边来表示依赖关系。

(图:血缘架构对比)

上图为三个版本对比情况:

●血缘的消费方式:第一版只支持 API 的方式,用户需要在数据资产平台上查看血缘信息;第二版支持离线数仓,让用户可以全量分析血缘;第三版支持消息队列,使用户可以获取血缘增量的变化。

●增量更新:第三版开始支持增量更新。

●血缘任务:第二个版本开始支持任务血缘,第三个版本支持数据质量。

●元数据存储统一:第三版进行了元数据架构升级,使得元数据和血缘存储在同一个地方。

●新血缘接入耗时:前两个版本大概需要花费7-10天左右。第三版本引入标准化,外部业务方或字节内部用标准化流程,实现3、4天左右完成开发、测试、上线。

未来展望

第一,持续对架构和流程进行精简。目前,血缘任务分为离线和实时两部分,但没有完全统一。在插件化、横向扩展等方面也需要加强。

第二,生态化支持。目前支持公司内部的元数据,未来计划拓展对开源或外部元数据的支持。在血缘标准化方面,提供一站式数据血缘能力,作为基础能力平台为业务方提供服务。

第三,提升数据质量。除了血缘数量,还需要持续提升质量。同时由于数据链路复杂,导致链路问题排查异常困难,未来我们也会支持快速诊断。

最后,支持智能化场景。结合元数仓等数据,提供包含关键链路梳理在内的智能化能力。目前,当业务方发现数据有问题之后,主要通过按照血缘数据一个一个排查方式解决,导致效率低下。未来,我们将考虑透出血缘关键链路,提升排查效率。

以上介绍的数据血缘能力和实践,目前大部分已通过火山引擎DataLeap对外提供服务。