火山引擎DataLeap：数据血缘模型的分层架构

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

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

首先介绍一下字节内部数据血缘遇到的挑战。

随着公司业务扩张、用户数量持续增长以及数仓建设不断完善,元数据种类和数量也经历了非线性增长,并在此期间涌现出一些问题。

第一,扩展性。好的扩展性可以在面对新型元数据血缘时保证快速接入和迭代,而扩展性不佳则会导致在业务变化时需要不停地重构来适应业务,对业务造成很多影响。

第二,性能。一个模型本身的插入和更新效率会直接影响数据的导入导出的流程,这些都会带来更直观的业务上的感受,所以需要考虑如何保证环节高效性。

第三,时效性。很多应用场景对正确率格外敏感,如果血缘数据有延迟,其实就等于血缘的不准确,会对业务造成影响。

最后,赋能业务。技术服务于业务,业务增长会帮助技术升级迭代,技术创新也会促进业务发展。在字节内部,我们会根据业务特点,考虑业务需要,将技术成本与业务收益做平衡,最终做出数据模型决策。总而言之,数据模型没有完美的方案,只有最适合企业自身业务、适合当前阶段的数据血缘方案。

字节内部有很多种元数据类型,包括线上传统的离线数仓Hive、OLAP分析引擎ClickHouse,以及实时侧元数据,如Kafka和ES以及Redis。这些元数据所对应的表/Topic都统一维护在元数据平台上,目前血缘展示层是以这些数据资产作为主视角。

如下图所示,中心数据资产包含普通字段和分区字段等信息,还可以从图中看到中心资产上下游资产信息。图中资产和资产之间连接的边,代表的是生产关系:1个任务读取了上游的资产,产生了下游的资产。

(图: 数据血缘模型-展示层)

接下来介绍,火山引擎DataLeap如何设计抽象层。

抽象层是整个数据血缘的数据模型,主要包含两种节点,一种是资产节点,另外一种是任务节点。

在图中,资产节点用圆形表示,任务节点用菱形表示。具体举个例子:

●一个FlinkSQL任务消费了Kafka的topic,然后写入到一个Hive的表里,那么Kafka的topic和hive表就是表资产节点,而FlinkSQL消费任务就是中间的任务节点。

●一个Kafka的topic里面可能会定义自己的schema,包括多个字段,例如schema里包含字段a、b、c,通过FlinkSQL任务,比如一个SQL:insert into hiveTable select a,b,c from kafka Topic,通过进行这样的处理,字段a、b、c和这个hive的字段d就产生了血缘关系。

●创建子任务的节点,把几个字段节点连接起来,每个子任务节点会和子任务节点通过从属关系的边来进行连接,字段节点和每一个表资产节点也会通过从属关系的边进行连接。本身这个任务和资产之间会有消费生产关系的边连接。

以上就是整个血缘数据模型在抽象层的展现。

这样设计有以下好处:

首先,任务资产的抽象是对生产平台上和在各种任务平台上广泛直接的任务关系的抽象,当再去接入新元数据或新任务类型时,我们只需要扩展当前抽象的资产节点和任务节点,即可把新加入进来的任务链路所对应的血缘接入到存储中。这种数据模型也能方便地更新和删除血缘链路,维持时效性。

其次,在字节内部的血缘建设中,还存在接入各种血缘链路的难点。基于目前设计可以减少开发成本,在更新血缘的时只需要更新中心任务节点,并且把中心任务节点所对应的子任务节点的边也做相应的更新和删除,就完成了血缘信息的插入和更新。

(图: 数据血缘模型-抽象层)

在实现层,火山引擎DataLeap主要基于Apache Atlas来实现。Apache Atlas本身也是一个数据治理的产品,它预定义了一些元数据的类型,整个类型系统有比较好的扩展性。在Atlas本身的DataSet和Process元数据定义上,我们引入了字节内部独有的业务元数据的属性和子任务定义,最终把任务相关的元数据存储起来。

Atlas本身也支持血缘的查询能力,通过Apache Atlas暴露的接口来转换成图上查找某个节点对应血缘关系的边,以此实现血缘查询。

(图:数据血缘模型-实现层)

在存储层,目前主要基于Apache Atlas原生图数据库——JanusGraph。JanusGraph底层支持HBase。我们将每条边的关系作为两边的资产节点的属性,存入到对应RowKey的独立cell中。

另外,我们也对存储做了相关的改造,如字节内部自研的存算分离key-value存储。我们也在独立环境中会做轻量级部署,同时基于性能或成本,以及部署复杂度,把存储切换为OLTP数据库,比如MYSQL数据库。

(图:数据血缘模型-存储层)

以上就是整个数据血缘模型的设计部分。通过这样的数据血缘模型,我们可以减少新的数据血缘链路接入开发成本,同时也很方便更新和删除血缘。

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