CN114895850A - 一种数据湖优化写的方法 - Google Patents

Abstract

本发明公开了一种数据湖优化写的方法，包括步骤：数据通过客户端写入，或直接消费kafka读取数据；数据写入后进行分区，分区数据会通过历史index判断当前数据是更新还是新增的结果，更新数据和新增数据分开缓存在内存中,同时会更新index数据，分区数据还写成日志文件，当数据达到一定规模或时间达到一定阈值，将内存flush进入数据湖的文件系统中，新增数据写入insert文件中，更新数据写入update文件中；写入成功后，删除历史日志文件。本发明相对现有的spark/flink写入方案能节约约90％的内存和cpu资源。

Description

一种数据湖优化写的方法

技术领域

本发明属于大数据技术领域，尤其涉及一种数据湖优化写的方法。

背景技术

数据湖在大数据场景中越来越多，开源数据湖例如iceberg，hudi，kudu等提供了高效的存储和大数据兼容。以Hudi为例，Hudi是一种数据湖的存储格式，在Hadoop文件系统之上提供了更新数据和删除数据的能力以及消费变化数据的能力。但是，在数据写入方面存在严重的不足，目前社区提供的数据导入方式主要是基于spark和flink等，在实际写入中，不管多少数据，一个数据表至少需要1个core，1g内存(简称1c1g)，如果算上spark的Dirver或者flink ResouceManger等，需要2c2g内存。

另外，以hudi(参见图1)为例，实际写入过程中链路很长，对于MOR场景，每次写入数据必须和现有数据进行tag(判断数据是否已经存在)，严重影响了写入的性能。在实际案例中，写入的数据竟然慢到28kB/s/1c3g。对于高代价，低产出的情况下，急需优化。

综上，目前的数据湖写入主要有两个问题：1、采用主流的spark和flink等大数据工具写入小量数据到数据湖时有存在资源的浪费，哪怕每天只有几条数据写入，至少需要2c2g来完成该功能。2、对于MOR表，每次写入数据都必须tag已有磁盘数据，严重影响的写入性能。

发明内容

有鉴于此，本发明提出了一种数据湖优化写的方法。针对上述问题，提高优化方案和实施方案，以达到资源的节约。

针对spark和flink等大数据工具写入小量数据到数据湖时有存在资源的浪费的问题，本发明采用java常驻服务集群服务来解决该问题(参考图2)，常驻服务内，cpu和内存可以共享，用时申请，不用时不占用资源。少量数据使用少量资源，没有最小限制，解决了spark/flink资源长期占用，且有最小资源限制的问题。

针对对于MOR表，每次写入数据都必须tag已有磁盘数据的问题，本发明采用提前建好索引方式去解决，减少每次都去加载历史数据的情况。

本发明公开的一种数据湖优化写的方法，采用一台服务器管理一个或多个表，一个表有一个或多个分区，一个分区管理一个index，两片内存区，一个日志通道，所述方法包括以下步骤：

数据通过客户端写入，或直接设置kafka consumer读取数据；

数据写入后进行分区，对于分区数据通过历史index判断当前数据是更新还是新增的结果，更新数据和新增数据分开缓存在两片内存区中,同时更新index数据，并将分区数据写成log文件；

当数据达到一定规模，将内存flush进入数据湖的文件系统中，新增数据写入insert文件中，更新数据写入update文件中，index写入upsert文件中；写入成功后删除日志，日志保障可靠性。

该链路也可以通过通过kafka consumer的offset管理数据，采用批处理方式来进行，数据写入后进行分区，分区数据会通过历史index判断当前数据是更新还是新增的结果，更新数据和新增数据分开缓存在内存中,同时会更新index数据。此时直接flush到数据湖的文件储存系统中，写入成功后更新kafka consumer的offset，保证数据的一致性。

index采用bloomfilter+rocksdb构建，按分区构建index，index只保留一段周期，一般为一周或一个月，定时删除历史index。

进一步的，写入hudi的文件系统时，控制所有底层元数据文件的生成，所有的文件按照数据湖定义规则存放。

进一步的，将更新数据和新增数据分开缓存在内存时，kafka consumer链路不写log文件。

进一步的，所述当数据达到一定规模，为符合如下规则时：

其中，a为更新数据长度，b为新增数据长度，c为log文件的长度，a₀为预设的更新数据长度基准值，b₀为预设的新增数据长度基准值，P为阈值，λ为根据实验确定的调整系数。

本发明的有益效果如下：

本发明提供的基于服务化的数据湖产品，能够节约90％的写入资源内核和cpu。主要节约点在于通过资源共享来节约资源，小数据量任务不需要像spark stream或者flink一样长期占用资源，而且可以只申请少量资源，用完释放，没有最小限制。大任务加快了tag过程，同时通过缓存元数据，能加速写入过程。通过提高效率来节约资源。实际测试结果从28KB/s/1c3g提升到10MB/s/1c1g。提升效果300倍以上，考虑到index对资源消耗，综合考虑，资源情况也在10倍以上的优化效果。

附图说明

图1现有技术中spark写hudi数据流图；

图2本发明的服务化hudi写入数据方式示意图；

图3本发明的数据湖服务化设计图。

具体实施方式

下面结合附图对本发明作进一步的说明，但不以任何方式对本发明加以限制，基于本发明教导所作的任何变换或替换，均属于本发明的保护范围。

针对spark和flink等大数据工具写入小量数据到数据湖时有存在资源的浪费的问题，本发明采用java常驻服务集群服务来解决该问题(参考图2)，kafka和java客户端通过写服务化处理，参照数据湖的存储格式输出，该存储格式可以被flink、spark、或hive等集群服务读取。通过集群化可以多个写流程共享内存和cpu，实现对小量数据任务的资源合并。Spark是一种与Hadoop相似的开源集群计算环境，但是两者之间还存在一些不同之处，这些有用的不同之处使Spark在某些工作负载方面表现得更加优越，换句话说，Spark启用了内存分布数据集，除了能够提供交互式查询外，它还可以优化迭代工作负载。Flink是一个框架和分布式处理引擎，用于在无边界和有边界数据流上进行有状态的计算。Flink能在所有常见集群环境中运行，并能以内存速度和任意规模进行计算。

在MOR表格式中，更新被写入到增量日志文件中，该文件以avro格式存储。这些增量日志文件始终与基本文件相关联。假设有一个名为data_file_1的数据文件，对data_file_1中记录的任何更新都将写入到新的增量日志文件。在服务读取查询时，Hudi将实时合并基础文件及其相应的增量日志文件中的记录。针对对于MOR表，每次写入数据都必须tag(标注)已有磁盘数据的问题，本发明采用提前建好索引方式去解决，减少每次都去加载历史数据的情况。

索引历史数据过多同样会带来问题，本发明为解决该问题，提供一种解决方案。以解决实际处理数据量(参考表1)的和处理策略复杂的问题。在实际场景中99.9％都是前5种场景，前五种情况的结论是：只需要正对少量的数据进行索引即可。至于最后一种场景，因为情况特殊，本发明不对该情况进行优化。

表1数据分布和索引策略

数据量	更新方式	索引策略
			小	不更新，只追加	无需索引
小	更新，只更新最近时间段	索引最近一段时间的数据
			小	更新，全量更新	索引全量数据
大	不更新，只追加	无需索引
			大	更新，只更新最近时间段	索引最近一段时间的数据
大	更新，全量更新	索引全量数据

数据湖产品产品众多，本实施例以hudi的实现为例进行描述，本实施例并不对数据湖的类型进行限制。

hudi的数据湖服务化设计流程图参考图3，数据通过客户端写入，或者直接设置kafka consumer读取数据，数据写入后首先会进行分区，分区数据分为delta data(更新数据)和newData(新增数据),并将数据结果分开缓存在内存中，同时会写log(kafkaconsumer链路不会)文件，当数据达到一定规模时，将内存flush进入数据湖hudi的文件系统中，newData写入insert文件中，delta data写入update文件中，分区数据会写入index系统中；最后Kafka consumer写入方式会更新kafka commit，然后滚动日志。

index采用bloomfilter+rocksdb构建，按分区构建index，index只保留一段周期，一般为一周或一个月，定时删除历史index。

bloomfilter创建index的语法如下：

CREATE BLOOMFILTER INDEX

ON[TABLE]table_name

在rocksdb中，每个SST file只有一个index/filter block。Index/filter的大小是由配置决定的。如果要分片的话，SST file的index/filter会被分片为多个小block，并会配备一个索引。当需要读取index/filter时，只有top-level index会load到内存。然后，通过top-level index找出具体需要查询的那个分片，然后加载那个分片数据到blockcache。top-level index占用的内存空间很小，可以存储在heap或block cache中。

当数据达到一定规模时，将内存flush进入数据湖hudi的文件系统中，即当数据规模符合如下规则时，将内存flush：

其中，a为更新数据长度，b为新增数据长度，c为log文件的长度，a₀为预设的更新数据长度基准值，b₀为预设的新增数据长度基准值，P为阈值，λ为根据实验确定的调整系数。当log文件大小大于5兆时，或更新数据长度与预设的更新数据长度基准值的变化的平方，与新增数据长度与预设的新增数据长度基准值的变化的平方之和，大于预设阈值，说明内存文件大小增长到一定规模，则需要将内存flush到hudi的文件系统。当log文件大小小于5兆时，并且更新数据长度与预设的更新数据长度基准值的变化与新增数据长度与预设的新增数据长度基准值的变化的比值大于调整系数，说明数据增长较快，需要及时flush。这样本实施例可以将内存中的数据及时flush到hudi文件系统中，避免内存中的数据被覆盖。

upsert是hudi默认的写操作，通过查找索引，输入记录首先被标记为插入或者更新，并最终在运行启发式操作后写入记录，以确定如何最好地将他们打包到存储上，以优化诸如文件大小之类的事情。这个操作推荐用于数据库更改捕获这样的用例，因为输入几乎肯定包含更新。insert操作在启发式/文件大小方面与upsert非常相似，但完全跳过了索引查找步骤。因此，对于日志重复删除之类的用例，它可能比upserts快得多。这也适用于数据集可以容忍重复，但只需要Hudi的事务性写/增量拉取/存储管理功能的用例。

在写入hudi的文件系统时，会控制所有底层元数据文件的生成，比如控制commit文件和fileId文件等，所有的文件完全按照数据湖定义规则来存放，因此不会对后续的查询带来任何影响。

本发明的有益效果如下：

本发明提供的基于服务化的数据湖产品，能够节约90％的资源内核和cpu。主要节约点在，小数据量任务不需要像spark stream或者flink一样长期占用资源，通过资源共享来节约资源。大任务加快了tag过程，同时通过缓存元数据，能加速写入过程。通过提高效率来节约资源。实际测试结果从28KB/s/1c3g提升到10MB/s/1c1g。提升效果300倍以上，考虑到index对资源消耗，综合考虑，资源情况也在10倍以上的优化效果。

本文所使用的词语“优选的”意指用作实例、示例或例证。本文描述为“优选的”任意方面或设计不必被解释为比其他方面或设计更有利。相反，词语“优选的”的使用旨在以具体方式提出概念。如本申请中所使用的术语“或”旨在意指包含的“或”而非排除的“或”。即，除非另外指定或从上下文中清楚，“X使用A或B”意指自然包括排列的任意一个。即，如果X使用A；X使用B；或X使用A和B二者，则“X使用A或B”在前述任一示例中得到满足。

而且，尽管已经相对于一个或实现方式示出并描述了本公开，但是本领域技术人员基于对本说明书和附图的阅读和理解将会想到等价变型和修改。本公开包括所有这样的修改和变型，并且仅由所附权利要求的范围限制。特别地关于由上述组件(例如元件等)执行的各种功能，用于描述这样的组件的术语旨在对应于执行所述组件的指定功能(例如其在功能上是等价的)的任意组件(除非另外指示)，即使在结构上与执行本文所示的本公开的示范性实现方式中的功能的公开结构不等同。此外，尽管本公开的特定特征已经相对于若干实现方式中的仅一个被公开，但是这种特征可以与如可以对给定或特定应用而言是期望和有利的其他实现方式的一个或其他特征组合。而且，就术语“包括”、“具有”、“含有”或其变形被用在具体实施方式或权利要求中而言，这样的术语旨在以与术语“包含”相似的方式包括。

本发明实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以多个或多个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。上述提到的存储介质可以是只读存储器，磁盘或光盘等。上述的各装置或系统，可以执行相应方法实施例中的存储方法。

综上所述，上述实施例为本发明的一种实施方式，但本发明的实施方式并不受所述实施例的限制，其他的任何背离本发明的精神实质与原理下所做的改变、修饰、代替、组合、简化，均应为等效的置换方式，都包含在本发明的保护范围之内。

Claims (5)

1.一种数据湖优化写的方法，其特征在于，采用一台服务器管理一个或多个表，一个表有一个或多个分区，一个分区管理一个index，两片内存区，一个日志通道，所述方法包括以下步骤：

数据通过客户端写入，或直接设置kafka consumer读取数据；

数据写入后进行分区，对于分区数据通过历史index判断当前数据是更新还是新增的结果，更新数据和新增数据分开缓存在两片内存区中,同时更新index数据，并将分区数据写成log文件；

当数据达到一定规模，将内存flush进入数据湖的文件系统中，新增数据写入insert文件中，更新数据写入update文件中，index写入upsert文件中；写入成功后删除日志。

2.根据权利要求1所述的数据湖优化写的方法，其特征在于，index采用bloomfilter和rocksdb构建，按分区构建index，index只保留一段周期，定时删除历史index。

3.根据权利要求1所述的数据湖优化写的方法，其特征在于，写入hudi的文件系统时，控制所有底层元数据文件的生成，所有的文件按照现有的数据湖定义规则存放。

4.根据权利要求1所述的数据湖优化写的方法，其特征在于，当通过kafkaconsumer的offset读取数据时，采用批处理方式处理，数据写入后进行分区，对于分区数据通过历史index判断当前数据是更新还是新增的结果，将更新数据和新增数据分开缓存在两片内存区中，kafka consumer链路不写log文件，更新index数据，并直接flush到数据湖的文件储存系统中，写入成功后更新kafka consumer的offset，保证数据的一致性。

5.根据权利要求1所述的数据湖优化写的方法，其特征在于，所述当数据达到一定规模，为符合如下规则时：

其中，a为更新数据长度，b为新增数据长度，c为log文件的长度，a₀为预设的更新数据长度基准值，b₀为预设的新增数据长度基准值，P为阈值，λ为根据实验确定的调整系数。

Images