火山引擎DataLeap：三个数据血缘优化方向

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

数据血缘是帮助用户找数据、理解数据以及使数据发挥价值的基础能力。本文介绍的数据血缘能力和实践,目前大部分已通过火山引擎DataLeap对外提供服务。

本文将主要介绍在火山引擎DataLeap中典型的数据血缘优化,包括实时数据血缘更新优化、血缘查询优化和血缘数据开放式导出。

首先,实时数据血缘的更新。字节内部现在数据血缘的更新方式是通过T+1的链路和实时链路来更新。由于内部有很多场景对时效性的要求特别高,如果数据血缘更新不太及时,就会影响血缘准确率,甚至影响业务使用。

在数据血缘的架构设计之初就已经支持了T+1的导入,不过时效性始终是按天为周期的。

●数据血缘任务周期性的拉取所有在运行任务的配置信息,调用平台的API拉取对应任务相关的配置或者SQL

●对于SQL类型的任务会调用另外一个解析引擎服务提供的解析能力来去解析数据血缘的信息

●再和元数据平台登记的资产信息相匹配,最后构建出一个任务资产节点的上下游,把这个任务资产节点和表资产节点之间的边更新到图数据库中去。

在实时更新的时候,我们有两种方案:

方案一:是在引擎侧,即在任务运行时,通过任务执行引擎把该任务在构建DAG后生成的血缘信息通过Hook送入。

●优点:在引擎侧的血缘采集是相对独立的,每个引擎在采集血缘的时候不会互相影响。

●缺点:

○每个引擎都需要适配一个血缘采集的Hook,一些中小企业在引擎侧都可能面临的一个问题是同一个引擎可能在线上运行会有多个版本,那么适配的成本就会比较高,需要每个版本都适配一次。

○Hook还有一定的侵入性,会对本身的作业有一定的负担。

方案二:在任务开发的平台上把这个任务变更的消息送出,当任务的生命周期变化的时候,通过Hook消息把任务状态变更消息通过调用API进行登记或者发送到MQ进行解耦,血缘服务收到这份通知之后,再主动调用解析服务来更新这个任务血缘。

●优点:扩展性好,不会受到引擎侧限制,未来要接入新的引擎时,只需要在这个任务平台上去创建对应的任务,把这个任务变更的消息送出,就可以得到这个血缘更新的通知,然后去更新血缘。

●缺点:对血缘解析服务平台会有一定的改造成本,任务间的消息可能会互相影响

综合比较,我们采用了第二种方案,并且引入了MQ进一步的降低任务平台和血缘平台的耦合,这种做法可能牺牲了部分的延迟,但是会让整个链路变得更加可靠,最终减低了血缘这边整体的延迟,时间周期从天减低到了分钟级别。

以上就是我们在血缘时效性上的优化。

(图:实时数据血缘优化)

第二个优化点是查询。目前字节数据血缘查询依赖Apache Atlas。在使用该血缘查询服务时,有一个很普遍的场景,就是多节点查询的场景。在影响分析的过程中,我们经常会查询一张表的全部字段血缘,会转化成查询多个节点的血缘上下游关系,需要解决查询效率的问题。

有两种基本的解决方案:

一种是直接在应用层进行封装,对Apache Atlas血缘服务的暴露层新增一个接口,比如通过循环遍历去执行单个查询,这样改造的内容是很少的,但是其实性能并没有提升,而且实现比较暴力。

另外一种方式是改造Apache Atlas血缘服务对图库查询的调用。因为Atlas使用JanusGraph作为底层的实现,提供了一部分的抽象,但是只暴露了单节点的查询,而没有批量查询的方法,我们还需要适配JanusGraph这边批量查询的接口,才可以达到提速的效果。

所以我们在图数据库的操作入口增加了一个新的批量查询的方法,通过这种方式对血缘节点进行批量查询,来进一步提升性能。同时Atlas在查询血缘节点回来之后,需要进行一个映射,映射到具体的实体上去拿回它的一些属性,在这个过程中我们也加入了异步批量的操作方式来进一步的提升性能。经过优化之后,我们在对一些引用热度比较高的表资产节点或者查询表资产或者对应列的时候,效率都可以得到明显提升。

(图:数据查询优化)

第三个优化点是在血缘的导出上提供了多种方式,除了在页面上可视化的查询血缘的能力之上,我们也陆续提供了很多使用血缘的方式,包括下载到Excel或者查询这个血缘数据导出的数仓表,或者直接使用服务平台侧开放的API,还可以订阅血缘变更的topic,来直接监听血缘的变更,下游的用户可以根据自己的开发场景,以及业务对准确率、覆盖率的要求,来决定到底使用哪种方式来消费血缘数据。

(图:血缘数据开放式导出)

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