字节跳动DataLeap数据血缘实践

2. 数据查询优化
第二个优化点是查询 。目前字节数据血缘查询依赖Atlas 。在使用该血缘查询服务时,有一个很普遍的场景,就是多节点查询的场景 。在影响分析的过程中,我们经常会查询一张表的全部字段血缘,会转化成查询多个节点的血缘上下游关系,需要解决查询效率的问题 。
有两种基本的解决方案:
一种是直接在应用层进行封装,对Atlas 血缘服务的暴露层新增一个接口,比如通过循环遍历去执行单个查询,这样改造的内容是很少的,但是其实性能并没有提升,而且实现比较暴力 。
另外一种方式是改造Atlas 血缘服务对图库查询的调用 。因为 Atlas 使用作为底层的实现,提供了一部分的抽象,但是只暴露了单节点的查询,而没有批量查询的方法,我们只需要适配这边批量查询的接口,就可以达到提速的效果 。
所以我们在图数据库的操作入口增加了一个新的批量查询的方法,通过这种方式对血缘节点进行批量查询,来进一步提升性能 。同时 Atlas 在查询血缘节点回来之后,需要进行一个映射,映射到具体的实体上去拿回它的一些属性,在这个过程中我们也加入了异步批量的操作方式来进一步的提升性能 。经过优化之后,我们在对一些引用热度比较高的表资产节点或者查询表资产或者对应列的时候,效率都可以得到明显提升 。
3. 血缘数据开放式导出
第三个优化点是在血缘的导出上提供了多种方式,除了在页面上可视化的查询血缘的能力之上,我们也陆续提供了很多使用血缘的方式,包括下载到 Excel,或者查询这个血缘数据导出的数仓表,或者直接使用服务平台侧开放的 API,还可以订阅血缘变更的 topic,来直接监听血缘的变更,下游的用户可以根据自己的开发场景,以及业务对准确率、覆盖率的要求,来决定到底使用哪种方式来消费血缘数据 。
03
数据血缘用例
接下来第三部分主要介绍数据血缘的具体用例,介绍字节内部是如何使用数据血缘的 。在字节内部数据血缘用例的典型使用领域主要包括:资产领域、开发领域、治理领域和安全领域 。
1. 数据血缘用例 – 资产领域
首先在资产领域,数据血缘主要应用在资产热度的计算 。在资产热度计算时,有些资产会被频繁消费和广泛引用 。某个资产被众多下游引用,是自身权威性的证明,而这种权威性的证明需要一种定量的度量,因此需要引入了“资产热度”的概念 。资产热度本身是参考网页排名算法算法实现的,同时我们也提供了资产热度值,根据资产的下游血缘依赖的情况,定义了资产引用的热度值,如果某个资产引用热度值越高,就代表了这个资产更应该被信任,数据更可靠 。
另外,血缘也可以帮助我们理解数据 。比如用户在元数据平台或者血缘平台上查询数据资产节点的时候,可能是想要进行下一步的作业开发或者是排查一些问题,那么他就需要首先找到这个数据资产 。用户不了解数据产生的过程,就无法了解数据的过去和未来 。也就是哲学上经典的问题:这个表到底是怎么来的?它具体有哪些含义?我们就可以通过数据血缘来找到具体表的上下游信息 。
2. 数据血缘用例 – 开发领域
数据血缘的第二个用例是开发领域 。在开发领域中会有两个应用:影响分析和归因分析 。
(1)影响分析应用
影响分析应用是事前分析 。也就是当我们对表资产做一些变更的时候,在事前需要感知这个变更的影响,处于血缘上游的资产负责人在修改对应的生产任务的时候s,就需要通过血缘来查看自己资产的下游,来判断这个资产修改的影响,针对修改的兼容性或者某条链路的重要性,来对应的做一些通知的操作,否则会因为缺少通知而造成严重的生产事故 。