具体实施方式

下面结合附图和具体实施方式对本发明做进一步详细的说明。

本实施例公开了一种数据湖系统的数据存储方法，包括以下步骤：

S1.将文件转成文件流；

S2.将文件流转成一个数组嵌套多个子数组的形式；

S3.将所述的数组转成RDD，使其满足数据湖的parquet格式要求后存储至数据湖的存储层中。

优选地，本方案通过读取配置文件的方式获取当前硬件环境CPU内核数量从而动态确定相应的嵌套数量，具体为，将文件流转成然后将该数组嵌套子数组的数量与当前硬件环境CPU内核数量相一致的数组。如一个文件流以非嵌套方式转换的数组形式为[1,2,3,4,5,6,7,8]，则，若当前硬件环境CPU内核数量为2核，经过本方案嵌套方式转换后的数组形式为嵌套两个子数组的形式，即[[1,2,3,4],[5,6,7,8]]；若当前硬件环境CPU内核数量为4核，经过本方案嵌套方式转换后的数组形式为嵌套四个子字数组的形式，即[[1,2],[3,4][5,6],[7,8]]。其它内核数量的情况依此类推。当嵌套数量与CPU内核数量一致时，可以获得最快的读出速度，经过前述自适应方式，能够使数组的嵌套数量与CPU内核相适配，从而保持最佳的读出速度，有效提高出湖性能。

优选地，本实施例步骤S2与S3之间还包括：

检测当前数组大小，若在设定值之内，则以单行形式存储当前数组；若超过设定值，则将当前数组切分以分行存储，且每行的数组大小均小于设定值。且当数组大小大于设定值时，分行数量n为n=m/s+1，其中m表示数组大小，s表示设定值，/表示整除取商。如数组大小为50Mb，设定值为60Mb，则n=50/60+1=0+1=1;

如数组大小为100Mb，设定值为60Mb，则n=100/60+1=1+1=2。在切分为多行时，可以使前面几行每行大小为设定值，最后一行为当前数组的剩余字节，也可以每一行平均分配，还可以根据数组情况自由分配，例如可以优选使属于同一子数组的字节放在同一行。

进一步地，对大于设定值的数组切分成多个后返回包含多个RDD的迭代器。将数组按照指定大小切分成多个后通过迭代器返回，不使用列表返回，能够有效避免OutOfMemoryError（产生栈内存溢出）错误。

进一步地，本方法还包括通过轮询自动存储方法，主要是在代码层面，通过轮询(polling)的方式，监听某文件夹下的文件是否有新增，若有新增则将新增文件存入数据湖，具体过程如下：

A1.在每次轮询中，获得指定路径下所有文件的绝对路径，将其放入到一个数组中，作为最新的偏移量；

A2.取上一次轮询的结果，两个数组做差集；

A3.根据差集结果获得在此次轮询中， 新增文件的绝对路径，随后通过步骤S1-S3将新增文件存入数据湖。

本方案通过轮询的方式监听文件夹，能够主动将新增文件加入到数据湖，在将数据湖连接数据源后，用户启动针对该数据源的轮询自动存储功能，无需用户手动将新增文件，满足实际业务需求，进一步提高数据湖存储性能。

进一步地，本方法还通过继承FileFormat类对数据湖系统重写buildReader（批读）和prepareWrite（批写）两个方法来实现批读和批写功能。

buildReader的实现与目前spark公司的类似，但数据湖底层将RDD以parquet进行存储后向数据湖返回RDD格式的类型不同，spark返回单个RDD，本方案返回多个迭代器，包含多个RDD，每次返回一小部分，计算机处理完成当前部分后再返回下一部分进行处理，能够有效避免OutOfMemoryError。

prepareWrite的实现方法为，获取多个相关数组，将多个相关数组拼接成一个数组，并通过输出流输出。

本实施例还提供一种采用上述存储方法进行数据存储的高性能的数据湖系统。

为了验证本方案数据湖系统的数据存储方法的优越性，对基于本方法存储的数据湖系统和现有普通存储的数据湖系统进行出入湖实验对比：

实验环境：

硬件环境，li7 10代8核，l16G内存；

软件环境，lhadoop 伪分布式存储，lubuntu 18.04；

JVM环境，l-Xms2048m(初始堆大小)，l-Xmx4096m(最大堆大小)。

部分测试数据：

不同格式文件的单个写入写出测试：

文本文件(txt,pdf)；视频文件(mp4)；压缩文件(gz)

本次采用真实实验数据，没有采用代码随机生成的文件，每组数据写入写出重复3-5次,取平均值为结果。

部分实验结果如图2-13所示，图2-图5为现有技术普通存储方式的出入湖系统的出入湖实验结果图，其中，

图2为单个txt文件写入写出耗时，由图可知，在写入写出文件达到356张时，写出耗时143347ms，写入耗时13240ms。

图3为单个pdf文件写入写出耗时，由图可知，在写入写出文件达到200.8MB时，写出耗时78663ms，写入耗时8796ms。

图4为单个mp4文件写入写出耗时，由图可知，在写入写出文件达到391MB时，写出耗时44242ms，写入耗时11003ms。

图5为单个gz文件写入写出耗时，由图可知，在写入写出文件达到325MB时，写出耗时309683ms，写入耗时9754ms。

图6-图13为采用本方案存储方式的出入湖系统的出入湖实验结果图，其中，

图6为单个txt文件写入耗时，由图可知，在写入文件达到356张时，嵌套子数组数量为2、4、6和8的数组结构写入耗时分别需要10417ms、11328ms、10636ms、9978ms。与图2对比可以看到写入速度比普通数据湖系统稍快。

图7为单个txt文件读出耗时，由图可知，在读出文件达到356张时，嵌套子数组数量为2、4、6和8的数组结构读出耗时分别需要42439ms、14849ms、12103ms、9868ms。与图2对比可以看到，各嵌套数量情形的读出速度均比普通数据湖系统提高很多。

图8为单个pdf文件写入耗时，由图可知，在写入文件达到200.8Mb时，嵌套子数组数量为2、4、6和8的数组结构写入耗时分别需要7664ms、77107ms、7038ms、7307ms。与图3对比可以看到写入速度比普通数据湖系统稍快。

图9为单个pdf文件读出耗时，由图可知，在读出文件达到200.8Mb时，嵌套子数组数量为2、4、6和8的数组结构读出耗时分别需要22114ms、7724ms、5702ms、6549ms。与图3对比可以看到，各嵌套数量情形的读出速度均比普通数据湖系统提高很多。

图10为单个mp4文件写入耗时，由图可知，在写入文件达到391Mb时，嵌套子数组数量为2、4、6和8的数组结构写入耗时分别需要11732ms、9702ms、10861ms、11008ms。与图4对比可以看到写入速度接近于普通数据湖系统。

图11为单个mp4文件读出耗时，由图可知，在读出文件达到391Mb时，嵌套子数组数量为2、4、6和8的数组结构读出耗时分别需要114045ms、33027ms、16389ms、14851ms。与图4对比可以看到，嵌套数量为2的读出速度比普通数据湖系统要慢，但是其余嵌套数量为4、6和8时均比普通数据湖系统快，尤其是嵌套数量为8时，读出速度明显比普通数据湖系统快。

图12为单个gz文件写入耗时，由图可知，在写入文件达到325Mb时，嵌套子数组数量为2、4、6和8的数组结构写入耗时分别需要10002ms、9415ms、8633ms、8417ms。与图5对比可以看到写入速度接近于普通数据湖系统。

图13为单个gz文件读出耗时，由图可知，在读出文件达到325Mb时，嵌套子数组数量为2、4、6和8的数组结构读出耗时分别需要81297ms、25790ms、12503ms、9386ms。与图5对比可以看到各嵌套数量情形的读出速度均比普通数据湖系统提高很多。

由以上实验图可以看到，采用本方案方式存储的数据湖系统相较于现有技术的数据湖系统在入湖性能上略有提升，但是在出湖性能上却能够大幅度提升，所以本方案能够有效提高数据湖出湖性能。另外，本实验的实验环境是8核内核，所以嵌套数量为8的数组结构具有最高的出入湖性能，这可以从图6-13中与嵌套数量分别为2、4和6的对比可以明显看出。

本文中所描述的具体实施例仅仅是对本发明精神作举例说明。本发明所属技术领域的技术人员可以对所描述的具体实施例做各种各样的修改或补充或采用类似的方式替代，但并不会偏离本发明的精神或者超越所附权利要求书所定义的范围。

尽管本文较多地使用了数组、存储层、文件流、嵌套、迭代器等术语，但并不排除使用其它术语的可能性。使用这些术语仅仅是为了更方便地描述和解释本发明的本质；把它们解释成任何一种附加的限制都是与本发明精神相违背的。