数据存储方法及装置、计算机可读存储介质、电子设备与流程

1.本公开的实施方式涉及大数据处理领域，更具体地，本公开的实施方式涉及一种数据存储方法、数据存储装置、计算机可读存储介质以及电子设备。


背景技术：

2.本部分旨在为权利要求书中陈述的本公开的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。
3.在一些数据存储方案中，可以基于如下技术方案实现：通过计算引擎将待存储数据拆分成若干条的小数据，然后同时执行多个任务，将每一条小数据通过存储引擎提供的远程调用接口写入，直至所有的小数据均被写入到存储引擎中。
4.但是，由于待存储数据的数据量过大，所拆分得到的小数据数量也大，采用远程调用接口的方式会使得写入效率较低。


技术实现要素：

5.为此，非常需要一种改进的数据存储方法，以根据待存储分片的键确定其待存储分片所属的存储区间，进而根据存储区间所属的存储引擎节点，将根据待存储分片得到的待存储文件存储至该存储引擎节点。
6.在本上下文中，本公开的实施方式期望提供一种数据存储方法、数据存储装置、计算机可读存储介质以及电子设备。
7.根据本公开的一个方面，提供一种数据存储方法，包括：
8.对待存储数据进行分片处理，得到包括键值对的待存储分片，并根据所述待存储分片的键，确定所述待存储分片所属的存储区间；
9.将属于同一存储区间的待存储分片转换成待存储文件；
10.根据所述存储区间所属的存储引擎节点，将所述待存储文件存储至所述存储引擎节点中。
11.在本公开的一种示例性实施例中，对待存储数据进行分片处理，得到多个包括键值对的待存储分片，包括：
12.获取待存储数据，并对所述待存储数据的键进行哈希运算，得到所述待存储数据的键的哈希值；
13.根据所述待存储数据的键的哈希值以及与所述待存储数据的键对应的值，得到所述包括键值对的待存储分片。
14.在本公开的一种示例性实施例中，获取待存储数据包括：
15.根据数据文件的路径，从分布式文件系统中获取包括键值对的待存储数据；和/或
16.从hive集群中获取包括键值对的待存储数据。
17.在本公开的一种示例性实施例中，根据所述待存储分片的键，确定所述待存储分片所属的存储区间，包括：
18.根据所述待存储分片的键的哈希值的第一个字符在预设的字典序中的顺序，确定所述待存储分片所属的存储区间。
19.在本公开的一种示例性实施例中，所述数据存储方法还包括：
20.根据所述待存储分片的键的哈希值的第一个字符在预设的字典序中的顺序，对属于同一存储区间的待存储分片进行排序。
21.在本公开的一种示例性实施例中，将属于同一存储区间的待存储分片转换成待存储文件，包括：
22.根据所述待存储分片所属的存储区间，对所述待存储分片进行归类；
23.获取属于同一存储区间的待存储分片的场景编号以及所述存储区间的区间编码，并将所述场景编号以及所述区间编码写入所述待存储分片的键中；
24.获取属于同一类别的待存储分片的版本号、过期时间以及写入时间，并将所述版本号、过期时间以及写入时间，写入所述待存储分片的值中；
25.对属于同一存储区间的待存储分片进行格式转换，得到所述待存储文件。
26.在本公开的一种示例性实施例中，所述数据存储方法还包括：
27.计算当前待存储文件的数据量，并判断所述数据量是否大于预设阈值；
28.若是，则将剩余的待存储分片写入下一个待存储文件。
29.在本公开的一种示例性实施例中，根据所述存储区间所属的存储引擎节点，将所述存储区间中包括的待存储文件存储至所述存储引擎节点中，包括：
30.根据分布式存储引擎的路由表，确定所述存储区间所对应的存储引擎节点；
31.根据所述存储区间中包括的待存储文件以及所述存储区间所对应的存储引擎节点，确定所述待存储文件所对应的存储引擎节点；
32.调用所述存储引擎节点所在的存储引擎服务器，拉取所述待存储文件，并将拉取到的待存储文件加载至对应的存储引擎节点中。
33.在本公开的一种示例性实施例中，拉取所述待存储文件，包括：
34.为所述存储引擎节点配置拉取速度值，并在所述存储引擎服务器上部署代理服务；
35.通过所述代理服务控制所述存储引擎节点以所述拉取速度值拉取所述待存储文件。
36.在本公开的一种示例性实施例中，将拉取到的待存储文件加载至对应的存储引擎节点中，包括：
37.读取所述拉取到的待存储文件的元信息；
38.基于所述元信息，将所述待存储文件添加至所述存储引擎节点中包括的日志结构的合并树中。
39.在本公开的一种示例性实施例中，所述数据存储方法还包括：
40.根据所述待存储文件的值中包括的版本号，确定所述日志结构的合并树中是否存在与所述待存储文件对应的历史版本文件；
41.若存在，则对所述历史版本文件进行删除。
42.在本公开的一种示例性实施例中，所述数据存储方法还包括：
43.根据已存储分片的键，确定所述已存储分片所在的存储引擎节点，并从所述存储
引擎节点中获取与所述已存储分片对应的已存储文件；
44.从所述已存储文件中获取所述已存储分片。
45.根据本公开的一个方面，提供一种数据存储装置，包括：
46.存储区间确定模块，用于对待存储数据进行分片处理，得到包括键值对的待存储分片，并根据所述待存储分片的键，确定所述待存储分片所属的存储区间；
47.待存储文件转换模块，用于将属于同一存储区间的待存储分片转换成待存储文件；
48.文件存储模块，用于根据所述存储区间所属的存储引擎节点，将所述待存储文件存储至所述存储引擎节点中。
49.在本公开的一种示例性实施例中，对待存储数据进行分片处理，得到多个包括键值对的待存储分片，包括：
50.获取待存储数据，并对所述待存储数据的键进行哈希运算，得到所述待存储数据的键的哈希值；
51.根据所述待存储数据的键的哈希值以及与所述待存储数据的键对应的值，得到所述包括键值对的待存储分片。
52.在本公开的一种示例性实施例中，获取待存储数据包括：
53.根据数据文件的路径，从分布式文件系统中获取包括键值对的待存储数据；和/或
54.从hive集群中获取包括键值对的待存储数据。
55.在本公开的一种示例性实施例中，根据所述待存储分片的键，确定所述待存储分片所属的存储区间，包括：
56.根据所述待存储分片的键的哈希值的第一个字符在预设的字典序中的顺序，确定所述待存储分片所属的存储区间。
57.在本公开的一种示例性实施例中，所述数据存储装置还包括：
58.待存储分片排序模块，用于根据所述待存储分片的键的哈希值的第一个字符在预设的字典序中的顺序，对属于同一存储区间的待存储分片进行排序。
59.在本公开的一种示例性实施例中，将属于同一存储区间的待存储分片转换成待存储文件，包括：
60.根据所述待存储分片所属的存储区间，对所述待存储分片进行归类；
61.获取属于同一存储区间的待存储分片的场景编号以及所述存储区间的区间编码，并将所述场景编号以及所述区间编码写入所述待存储分片的键中；
62.获取属于同一类别的待存储分片的版本号、过期时间以及写入时间，并将所述版本号、过期时间以及写入时间，写入所述待存储分片的值中；
63.对属于同一存储区间的待存储分片进行格式转换，得到所述待存储文件。
64.在本公开的一种示例性实施例中，所述数据存储装置还包括：
65.第一计算模块，用于计算当前待存储文件的数据量，并判断所述数据量是否大于预设阈值；
66.第一写入模块，用于若是，则将剩余的待存储分片写入下一个待存储文件。
67.在本公开的一种示例性实施例中，根据所述存储区间所属的存储引擎节点，将所述存储区间中包括的待存储文件存储至所述存储引擎节点中，包括：
68.根据分布式存储引擎的路由表，确定所述存储区间所对应的存储引擎节点；
69.根据所述存储区间中包括的待存储文件以及所述存储区间所对应的存储引擎节点，确定所述待存储文件所对应的存储引擎节点；
70.调用所述存储引擎节点所在的存储引擎服务器，拉取所述待存储文件，并将拉取到的待存储文件加载至对应的存储引擎节点中。
71.在本公开的一种示例性实施例中，拉取所述待存储文件，包括：
72.为所述存储引擎节点配置拉取速度值，并在所述存储引擎服务器上部署代理服务；
73.通过所述代理服务控制所述存储引擎节点以所述拉取速度值拉取所述待存储文件。
74.在本公开的一种示例性实施例中，将拉取到的待存储文件加载至对应的存储引擎节点中，包括：
75.读取所述拉取到的待存储文件的元信息；
76.基于所述元信息，将所述待存储文件添加至所述存储引擎节点中包括的日志结构的合并树中。
77.在本公开的一种示例性实施例中，所述数据存储装置还包括：
78.历史版本文件确定模块，用于根据所述待存储文件的值中包括的版本号，确定所述日志结构的合并树中是否存在与所述待存储文件对应的历史版本文件；
79.历史版本文件删除模块，用于若存在，则对所述历史版本文件进行删除。
80.在本公开的一种示例性实施例中，所述数据存储装置还包括：
81.已存储文件获取模块，用于根据已存储分片的键，确定所述已存储分片所在的存储引擎节点，并从所述存储引擎节点中获取与所述已存储分片对应的已存储文件；
82.已存储分片获取模块，用于从所述已存储文件中获取所述已存储分片。
83.根据本公开的一个方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一项所述的数据存储方法。
84.根据本公开的一个方面，提供一种电子设备，包括：
85.处理器；以及
86.存储器，用于存储所述处理器的可执行指令；
87.其中，所述处理器配置为经由执行所述可执行指令来执行上述任意一项所述的数据存储方法。
88.根据本公开实施方式的提供的一种数据存储方法和数据存储装置，可以对待存储数据进行分片处理，得到包括键值对的待存储分片，并根据待存储分片的键，确定待存储分片所属的存储区间；再将属于同一存储区间的待存储分片转换成待存储文件；最后根据存储区间所属的存储引擎节点，将待存储文件存储至存储引擎节点中，而无需调用存储引擎提供的远程调用接口进行写入，从而显著地降低了由于待存储数据的数据量过大，所拆分得到的小数据数量也大，采用远程调用接口的方式会使得写入效率较低的问题，并且减少了由于采用远程调用接口的写入方式，需要将小数据保存至内存，然后再从内存中将小数据写入磁盘导致的写入程序繁琐的问题，为用户带来了更好的体验。
附图说明
89.通过参考附图阅读下文的详细描述，本公开示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本公开的若干实施方式，其中：
90.图1示意性地示出了根据本公开示例实施例的一种数据存储方法的流程图；
91.图2示意性地示出了根据本公开示例实施例的一种数据存储系统的框图；
92.图3示意性地示出了根据本公开示例实施例的一种将属于同一存储区间的待存储分片转换成待存储文件的方法流程图；
93.图4示意性地示出了根据本公开示例实施例的一种键值对的示例图；
94.图5示意性地示出了根据本公开示例实施例的一种根据所述存储区间所属的存储引擎节点，将所述存储区间中包括的待存储文件存储至所述存储引擎节点中的方法流程图；
95.图6示意性地示出了根据本公开示例实施例的一种数据获取方法的流程图；
96.图7示意性地示出了根据本公开示例实施例的另一种数据存储方法的流程图；
97.图8示意性地示出了根据本公开示例实施例的一种数据存储装置的框图；
98.图9示意性地示出了根据本公开示例实施例的一种用于对上述数据存储方法进行存储的计算机可读存储介质；
99.图10示意性地示出了根据本公开示例实施例的一种用于实现上述数据存储方法的电子设备。
100.在附图中，相同或对应的标号表示相同或对应的部分。
具体实施方式
101.下面将参考若干示例性实施方式来描述本公开的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本公开，而并非以任何方式限制本公开的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。
102.本领域技术人员知道，本公开的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。
103.根据本公开的实施方式，提出了一种数据存储方法、数据存储装置、计算机可读存储介质以及电子设备。
104.在本文中，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。
105.下面参考本公开的若干代表性实施方式，详细阐释本公开的原理和精神。
106.发明概述
107.本发明人发现，当向分布式kv存储引擎中导入数据时，现有技术会通过spark计算引擎或者其他分布式计算引擎，将原始数据拆分成若干份的小数据，然后同时执行很多个任务，将每一条key
‑
value数据通过存储引擎提供的远程调用接口写入；当然，也可以是通过一次远程调用接口写入多条key
‑
value数据，比如一次写入20条。这样，每条数据都会被
某一个执行任务写入到存储引擎中。直到所有的数据全部被处理后，导入数据的过程就完成了。
108.但是，现有技术虽然能完成导入数据，但是导入效率很低。具体表现在以下几个方面：
109.首先，对于大规模的数据，key
‑
value的条数在亿级别，数据量在百gb级别甚至tb级别；若通过存储引擎的远程调用接口单条或多条写入数据，整个过程的处理时间是很长的；例如，当数据导入需要耗时10个小时，那就意味着在spark集群中会占用很多的任务资源长达10个小时，进而增加了spark集群的系统负担，同时也降低了spark集群的利用率；
110.其次，通过远程调用接口写入数据，存储引擎本身也需要经过若干步骤的处理。具体的，数据会先保存在内存，并且追加记录到日志文件中防止内存数据丢失；当内存中的数据积累到一定量时，再将数据写到磁盘中，并清除日志文件；因此，调用接口写入数据的效率较低；
111.另外，存储引擎为了更好地提供读取服务，在新数据写入之后，还会通过不同的方式对数据做排序处理。其中，日志结构的合并树类型的存储引擎，会将新写入的数据和老数据做合并，通过归并排序的方式，清除重复的key，并保持数据的整体有序；但是，该过程会占用中央处理器和磁盘读写的资源，导致读取数据的性能下降；同时，由于现有技术没有对原始数据做过处理(比如排序)，导入数据时存储引擎的读取性能会明显下降。
112.基于此，本公开示例实施例提供了一种数据存储方法，一方面，由于可以根据待存储分片的键确定待存储分片所属的存储区间，进而根据存储区间所属的存储引擎节点，将存储区间中根据待存储分片转换的待存储文件存储至该存储引擎节点中，无需调用存储引擎的远程调用接口进行存储，提高了待存储文件的存储效率；另一方面，由于可以直接根据存储区间所属的存储引擎节点，将待存储文件存储至存储引擎节点中，无需将待存储文件保存至存储引擎的内存中，也无需清除日志文件，减少了待存储文件的存储流程；再一方面，由于提高了存储效率，进而降低了spark集群的系统负担，同时也提高了spark集群的利用率。
113.示例性方法
114.本示例实施方式中首先提供了一种数据存储方法，该方法可以运行于spark引擎所在的服务器、服务器集群或云服务器等；当然，本领域技术人员也可以根据需求在其他平台运行本公开的方法，本示例性实施例中对此不做特殊限定。参考图1所示，数据存储方法可以包括以下步骤：
115.步骤s110.对待存储数据进行分片处理，得到包括键值对的待存储分片，并根据所述待存储分片的键，确定所述待存储分片所属的存储区间；
116.步骤s120.将属于同一存储区间的待存储分片转换成待存储文件；
117.步骤s130.根据所述存储区间所属的存储引擎节点，将所述待存储文件存储至所述存储引擎节点中。
118.上述数据存储方法中，可以对待存储数据进行分片处理，得到包括键值对的待存储分片，并根据待存储分片的键，确定待存储分片所属的存储区间；再将属于同一存储区间的待存储分片转换成待存储文件；最后根据存储区间所属的存储引擎节点，将待存储文件存储至存储引擎节点中，而无需调用存储引擎提供的远程调用接口进行写入，从而显著地
降低了由于待存储数据的数据量过大，所拆分得到的小数据数量也大，采用远程调用接口的方式会使得写入效率较低的问题，并且减少了由于采用远程调用接口的写入方式，需要将小数据保存至内存，然后再从内存中将小数据写入磁盘导致的写入程序繁琐的问题，为用户带来了更好的体验。
119.以下，将结合附图对本公开示例实施例数据存储方法进行详细的解释以及说明。
120.分布式键值(kv)存储引擎：存储引擎是一种线上的系统，它提供数据存储服务，能够允许使用者对数据进行写入和查询，通常会在毫秒级的时间内作出响应。键值存储引擎是指存储格式为key
‑
value类型的存储引擎，key是关键字，value是值。由于单机的kv存储引擎存储空间有限，需要将数据分散存储在多个相同类型的kv存储引擎上，达到扩展存储容量和服务能力的目的，这就是分布式kv存储引擎。数据分散的方式有多种，可以将key作哈希计算后划分到不同的桶(也即存储区间)，每个桶对应到一个存储引擎节点；当然，也可以将key按顺序排列后划分到不同的区间，每个区间对应到一个存储引擎节点。
121.数据导入：很多时候需要将一份完整的大规模数据，增加或者更新到存储引擎中，该过程可以称为数据导入，也即数据存储。
122.spark：apache下的一个开源的专为大规模数据处理而设计的快速通用的计算引擎。spark是用scala语言中实现的，它将scala用作其应用程序框架，应用程序只需开发相应的计算逻辑代码，便可以在spark集群上通过多个任务同时对数据处理并得到最终结果。
123.lsm树：lsm树即日志结构的合并树(log
‑
structured merge tree)，是一种专门设计的将key
‑
value数据存储在磁盘中的方案；其通过牺牲部分读性能，大幅提升了写性能。
124.其次，对本公开示例实施例的发明目的进行解释以及说明。具体的，本公开示例实施例提供一种高效的分布式kv存储引擎导入数据方案，其与多任务同时调用存储引擎远程接口写入数据的方式不同，本公开对要导入的数据(待存储数据)做预处理，计算生成若干个文件，再由存储引擎直接加载这些文件。这样，解决了spark多任务长时间占用队列资源的问题，同时也大幅减轻了存储引擎对写入后的数据做合并的压力，从而也提高了导入数据的速度。
125.进一步的，对本公开示例实施例的数据存储系统进行解释以及说明。参考图2所示，该数据存储系统可以包括spark引擎210、分布式文件系统220、hive集群230、调度中心240以及存储引擎250。其中，分布式文件系统以及hive集群分别与spark引擎连接，存储引擎通过调度中心与spark引擎连接。其中，分布式文件系统以及hive集群可以用于存储待存储数据，spark引擎、调度中心以及存储引擎用于实现本公开示例实施例所记载的数据存储方法。
126.以下，结合图2对本公开示例实施例的数据存储方法进行解释以及说明。具体的，在本公开示例实施例的一种数据存储方法中：
127.在步骤s110中，对待存储数据进行分片处理，得到包括键值对的待存储分片，并根据所述待存储分片的键，确定所述待存储分片所属的存储区间。
128.在本示例实施例中，首先，对待存储数据进行分片处理，得到多个包括键值对的待存储分片。具体的，可以包括：首先，获取待存储数据，并对所述待存储数据的键进行哈希运算，得到所述待存储数据的键的哈希值；其次，根据所述待存储数据的键的哈希值以及与所述待存储数据的键对应的值，得到所述包括键值对的待存储分片。
129.其中，待存储数据的获取可以通过如下方式获取：根据数据文件的路径，从分布式文件系统中获取包括键值对的待存储数据；和/或从hive集群中获取包括键值对的待存储数据。具体的，最初的kv数据(也即待存储数据)存储在数据仓库中，需要通过大数据平台获取；比如，分布式文件系统(hdfs，hadoop distributed file system)上的数据文件，则需要指定hdfs上的数据文件的路径，以及哪一列作为key，哪一列作为value；又比如hive上的数据表，则可以指定hiveql读取对应的数据表，并在数据表中指定key和value；一般来说，线上使用的kv数据还需要做一些加工处理，比如key会加上前缀或后缀(例如在key中增加业务名称作为前缀)，比如value需要经过指定格式的序列化或者压缩处理，进而可以减少value的数据量，进而进一步的提高数据存储效率。此处需要补充说明的是，为了便于获取上述待存储数据，针对每个场景，通过配置shema指定如何从数据仓库中得到key和value，以及key的格式和value的序列化方式、value的压缩方式等等；在具体的数据获取过程中，在spark处理时经过通用的过程处理后即得到了待存储数据。
130.其次，在得到待存储数据以后，即可对待存储数据的键进行哈希运算，得到待存储数据的键的哈希值；再根据待存储数据的键的哈希值以及与待存储数据的键对应的值，得到包括键值对的待存储分片。此处需要补充说明的是，每一个存储引擎都会有一个数据分片的规则，本示例实施例的存储引擎采用哈希规则，当然也可以采用其他规则，本示例对此不做特殊限制。
131.进一步的，当得到待存储分片以后，即可根据待存储分片的键，确定待存储分片所属的存储区间。具体的，可以包括：根据所述待存储分片的键的哈希值的第一个字符在预设的字典序中的顺序，确定所述待存储分片所属的存储区间。举例来说，为了可以确定待存储分片所属的存储区间，首先需要划分出若干个存储区间(也即存储桶，bucket)，比如1024个，然后再根据键的哈希值的第一个字符在预设的字典序(该字典序例如可以是字母排序表)中的顺序，将每个key分散到某一个bucket中；通过该方法，只要写数据和读数据用的哈希规则相同，写入的数据就能被准确地从对应的bucket中读取到，进而可以提高数据的读取效率。
132.此处需要进一步补充说明的是，在获取到待存储数据以后，将全部数据做分片处理，以根据待存储分片的键提前计算出每条kv数据所属的bucket，进而根据bucket所属的存储引擎节点确定各待存储分片的存储引擎节点，进而在不调用远程调用接口的基础上，实现对待存储数据的存储，提高调用效率。
133.更进一步的，为了解决现有技术中有没有对原始数据进行排序，进而使得存储数据时存储引擎的读取性能会明显下降的问题，在确定各待存储分片所属的存储区间之后，还需要对每个存储区间中包括的待存储分片进行排序。具体的，该数据存储方法还可以包括：根据所述待存储分片的键的哈希值的第一个字符在预设的字典序中的顺序，对属于同一存储区间的待存储分片进行排序。其中，排序的规则默认是按key从小到大(也即key中的第一个字符在字母顺序表中的位置)排序；当然，如果某两个待存储分片的键的哈希值的第一个字符相同，则可以以此类推根据第二个、第三个字符进行排序等等；当然，如果存储引擎中有自定义的排序方法，那就不是默认的按key从小到大排序了，而是和存储引擎的排序方法保持一致。此处需要补充说明的是，数据排序的目的是为了进一步减少存储引擎在导入数据过程中因为数据合并带来的磁盘压力；由于本公开示例实施例中的存储引擎采用的
是lsm树结构，因为lsm树存储引擎存在磁盘上的数据本身就是有序的，而且数据合并的机制也是有序合并，所以先排序可以非常有效地减小数据合并过程的读写量和计算量，从而提高存储引擎的服务性能。
134.在步骤s120中，将属于同一存储区间的待存储分片转换成待存储文件。
135.在本示例实施例中，参考图3所示，将属于同一存储区间的待存储分片转换成待存储文件，可以包括以下步骤：
136.步骤s310，根据所述待存储分片所属的存储区间，对所述待存储分片进行归类；
137.步骤s320，获取属于同一存储区间的待存储分片的场景编号以及所述存储区间的区间编码，并将所述场景编号以及所述区间编码写入所述待存储分片的键中；
138.步骤s330，获取属于同一类别的待存储分片的版本号、过期时间以及写入时间，并将所述版本号、过期时间以及写入时间，写入所述待存储分片的值中；
139.步骤s340，对属于同一存储区间的待存储分片进行格式转换，得到所述待存储文件。
140.以下，将对步骤s310
‑
步骤s340进行解释以及说明。具体的，当待存储数据经过分片处理和排序处理之后，就可以根据一条条的待存储分片所属的存储区间对其进行归类，然后再将归类完成的待存储分片转换成存储引擎可以直接加载的待存储文件；其中，本公开示例实施例所采用的lsm存储引擎，比如rocksdb程序库，可以直接生成对应格式的待存储文件，该待存储文件可以是sst格式的文件；当然，为了可以根据场景编号以及存储容器的编号对数据进行查询，存储引擎除了保存key和value外，还会记录一些元信息，比如场景编号、bucket编码(区间编码)、写入时间、过期时间等等。同时，由于上述元信息是在每条kv写入时补充的，但是本公开示例实施例所记载的数据存储方法，无需调用远程调用接口进行写入，因此可以直接将其写入键值对，进而生成待存储文件。具体的，写了入了元信息的键值对具体的格式可以如图4所示。
141.此处需要进一步补充说明的是，考虑到要导入的数据规模非常大，虽然经过分片但每个bucket的数据仍然非常大，比如1gb甚至10gb；因此，在生成sst文件的过程中，该数据存储方法还可以包括：计算当前待存储文件的数据量，并判断所述数据量是否大于预设阈值；若是，则将剩余的待存储分片写入下一个待存储文件。也就是说，在生成sst文件的过程中，需要进行截断处理，在当前sst文件已经积累到一定大小时(比如64mb)，需要将数据写到新的sst文件中；基于此可以得知，每个bucket(存储区间)下会生成若干个不大于上述预设阈值的sst文件。另外，由于sst文件的总数据量非常大，可以将它们都保存到分布式文件系统上，进而可以直接从分布式文件系统上拉取对应的sst文件进行存储。
142.在步骤s130中，根据所述存储区间所属的存储引擎节点，将所述待存储文件存储至所述存储引擎节点中。
143.在本示例实施例中，参考图5所示，根据所述存储区间所属的存储引擎节点，将所述存储区间中包括的待存储文件存储至所述存储引擎节点中，可以包括以下步骤：
144.步骤s510，根据分布式存储引擎的路由表，确定所述存储区间所对应的存储引擎节点。
145.在本示例实施例中，首先，分布式存储引擎中除了有定义好的哈希分片规则外，还会确定每个存储区间中包括的待存储文件应该存储在哪些存储引擎节点上，进而根据区间
编码以及节点编码形成一个路由表；当路由表形成后，可以直接根据存储区间的区间编码从表1中确定其对应的存储引擎节点。其中，具体的路由表可以如下表1所示。
146.表1
147.bucket主节点从节点1server1server32server2server43server3server2
………………
1024server4server1
148.此处需要补充说明的是，每一个存储引擎节点是上，一般会有1个主节点，0或多个从节点，当主节点数据丢失后，可以用从节点上的备份数据来恢复，进而避免数据读取失败的问题。
149.步骤s520，根据所述存储区间中包括的待存储文件以及所述存储区间所对应的存储引擎节点，确定所述待存储文件所对应的存储引擎节点。
150.具体的，当存储区间的对应的存储引擎节点确定以后，即可根据该存储区间的存储引擎节点为各待存储文件分配存储引擎节点，以为后续的文件存储做准备。
151.步骤s530，调用所述存储引擎节点所在的存储引擎服务器，拉取所述待存储文件，并将拉取到的待存储文件加载至对应的存储引擎节点中。
152.在本示例实施例中，首先，通过调度中心调用存储引擎节点所在的存储引擎服务器；其中，调度中心的作用，就是调度每个sst文件加载到相应的存储引擎节点；具体的，调度中心会先读取分布式文件系统上的sst文件列表，再根据分布式存储引擎的路由表，计算出每一个存储引擎节点需要拉取和加载哪些存储区间下的待存储sst文件，再并发地去调度各个存储引擎依次执行文件的拉取；其中，sst文件列表可以如下表2所示：
153.表2
154.节点sst文件列表server1bucket1_sst1，bucket1_sst2，...，bucket1024_sst1，bucket1024_sst2，...server2bucket2_sst1，bucket2_sst2，...，bucket3_sst1，bucket3_sst2，...server3bucket1_sst1，bucket1_sst2，...，bucket3_sst1，bucket3_sst2，...server4bucket2_sst1，bucket2_sst2，...，bucket1024_sst1，bucket1024_sst2，...
155.其次，通过存储引擎服务器拉取所述待存储文件。具体的，可以通过如下方式实现：为所述存储引擎节点配置拉取速度值，并在所述存储引擎服务器上部署代理服务；通过所述代理服务控制所述存储引擎节点以所述拉取速度值拉取所述待存储文件。具体的，为了可以在降低存储引擎服务器的系统负担同时又确保拉取的效率，则需要对拉取速度进行控制；因此，设定一个拉取速度值，指定每个存储引擎节点每秒钟拉取多少个sst文件(实际情况下这个值会小于1，如0.2)，调度中心对每一个存储引擎的节点维护一个并发线程，并且控制其执行的速度；进一步的，可以通过设置代理服务来完成待存储文件的拉取过程；其中，每台存储引擎的服务器上虽然有多个节点，但只部署一个代理服务，该代理服务在接收到调度中心拉取文件的请求后，便开始从分布式文件系统上拉取文件，拉取文件一般会长达几秒甚至十几秒，为了避免调度中心的线程在不停地等待，这个过程对调度中心是异步
的；也就是说，代理服务在收到拉取文件的请求后会立即返回一个结果，然后调度中心会定期(每隔1秒)询问是否拉取完成。
156.此处需要补充说明的是，上述拉取文件的过程，也可以通过一个推送服务器将文件推送到各个存储引擎节点来实现，这样可以减少调度中心的工作，调度中心只需要将文件信息和存储引擎的地址信息发送给推送服务器。
157.进一步的，当拉取到待存储文件以后，还需要将拉取到的待存储文件加载至对应的存储引擎节点中。具体的加载过程可以包括：首先，读取所述拉取到的待存储文件的元信息；其次，基于所述元信息，将所述待存储文件添加至所述存储引擎节点中包括的日志结构的合并树中。具体的，当存储引擎拉取待存储文件完成之后，就是加载的过程了；该记载过程会比较快，1个待存储文件的加载一般在1秒之内；其中，加载文件的过程主要是读取sst文件的元信息(比如key的最小值和最大值)，并将文件添加到lsm中尽量靠上层的位置，以便于用户读取到最新存储的数据了。
158.此处需要进一步补充说明的是，为了可以进一步的提高数据存储效率，还需要对存储完成的数据进行合并，具体的合并过程可以包括：首先，根据所述待存储文件的值中包括的版本号，确定所述日志结构的合并树中是否存在与所述待存储文件对应的历史版本文件；其次，若存在，则对所述历史版本文件进行删除。具体的，如果每次加载新的待存储文件之后历史已存储文件可以清除，这种情况下可以通过两个版本来回切换来进一步提高导入数据效率；也就是说，为了避免存储引擎做数据合并的过程导致存储引擎的系统负担较重，导入待存储文件的时候可以将该待存储文件存储在一个新的版本中，导完之后再根据版本号将读请求切换到新版本，最后直接删除老版本，进而可以减少冗余数据，并提高数据存储效率。
159.本公开示例实施例还提供了一种数据获取方法。参考图6所示，该数据获取方法可以包括以下步骤：
160.步骤s610，根据已存储分片的键，确定所述已存储分片所在的存储引擎节点，并从所述存储引擎节点中获取与所述已存储分片对应的已存储文件；
161.步骤s620，从所述已存储文件中获取所述已存储分片。
162.以下，将对步骤s610
‑
步骤s620进行解释以及说明。具体的，首先，根据已存储分片的键的哈希值的第一个字符，确定该已存储分片所在的存储引擎节点，进而根据该已存储分片的键的哈希值，从该存储引擎节点中匹配对应的已存储文件，最后再从该已存储文件中获取该已存储分片。此处需要说明的是，只要保证待存储分片和已存储分片在数据存储和数据读取过程所用的哈希规则相同，存储的数据就能被准确地从对应的bucket中读取到，进而从与bucket对应的存储因情节点中获取对应的已存储文件以及已存储分片。
163.以下，结合图7对本公开示例实施例的数据存储方法进行进一步的解释以及说明。参考图7所示，该数据存储方法可以包括以下步骤：
164.步骤s701，获取待存储kv数据：根据分布式文件系统上的数据文件的存储路径，获取待存储kv数据，或者从hive集群中获取待存储kv数据；
165.步骤s702，数据分片处理：对待存储kv数据进行分片，得到包括键值对的待存储分片，并根据待存储分片的键，确定其所属的bucket；
166.步骤s703，数据排序：根据待存储分片的键，对同一bucket中的待存储分片进行从
小到大的排序；
167.步骤s704，生成存储引擎文件：将同一bucket中的待存储分片转换成待存储文件；
168.步骤s705，确定待存储文件所属的存储引擎节点：根据路由表，确定bucket所属的存储引擎节点，并根据bucket所属的存储引擎节点，确定该bucket中包括的待存储文件所属的存储引擎节点；
169.步骤s706，拉取待存储文件：通过存储引擎节点的代理服务，拉取该存储引擎节点所需要存储的待存储文件；
170.步骤s707，存储引擎加载文件：将拉取到的待存储文件加载至lsm树中的对应位置，以完成整个的存储过程。
171.本公开所提供的数据存储方法，一方面，使得导入数据效率的明显提升。具体的，相比调用存储引擎写入数据接口的方式，本公开的方案导入数据的效率可以提高到3倍左右。以实际的场景为例，分布式kv存储引擎中已有数据3.8tb(加上备份节点的数据，共7.6tb)，导入2.1亿条数据300gb，在导入数据的同时以每秒1万次的速度读取数据，控制导入数据的整个过程在2小时，比较两种导入数据方案的差别；具体的比对效果可以如下表3所示：
172.表3
[0173][0174]
另一方面，由于不再需要通过若干的任务持续向存储引擎中写入数据，spark的处理时间大幅减少，意味着占用任务队列资源的时间大幅减少；
[0175]
再一方面，从存储引擎数据合并量上看，本公开的方案减少到了原来的1/3，带来的结果是存储引擎的磁盘读写压力减少到了原来的1/3，这一结果从平均查询时间上也得到了验证。这也就意味着，在存储引擎的数据读取性能不变的情况下，导入数据的速度可以提高到原来的3倍，比如原来需要9个小时的导入数据过程，本公开的方案只需要3个小时。
[0176]
示例性装置
[0177]
本公开示例实施例还提供了一种数据存储装置。参考图8所示，该数据存储装置可以包括存储区间确定模块810、待存储文件转换模块820以及文件存储模块830。其中：
[0178]
存储区间确定模块810可以用于对待存储数据进行分片处理，得到包括键值对的待存储分片，并根据所述待存储分片的键，确定所述待存储分片所属的存储区间；
[0179]
待存储文件转换模块820可以用于将属于同一存储区间的待存储分片转换成待存储文件；
[0180]
文件存储模块830可以用于根据所述存储区间所属的存储引擎节点，将所述待存储文件存储至所述存储引擎节点中。
[0181]
在本公开的一种示例性实施例中，对待存储数据进行分片处理，得到多个包括键值对的待存储分片，包括：
[0182]
获取待存储数据，并对所述待存储数据的键进行哈希运算，得到所述待存储数据
的键的哈希值；
[0183]
根据所述待存储数据的键的哈希值以及与所述待存储数据的键对应的值，得到所述包括键值对的待存储分片。
[0184]
在本公开的一种示例性实施例中，获取待存储数据包括：
[0185]
根据数据文件的路径，从分布式文件系统中获取包括键值对的待存储数据；和/或
[0186]
从hive集群中获取包括键值对的待存储数据。
[0187]
在本公开的一种示例性实施例中，根据所述待存储分片的键，确定所述待存储分片所属的存储区间，包括：
[0188]
根据所述待存储分片的键的哈希值的第一个字符在预设的字典序中的顺序，确定所述待存储分片所属的存储区间。
[0189]
在本公开的一种示例性实施例中，所述数据存储装置还包括：
[0190]
待存储分片排序模块，用于根据所述待存储分片的键的哈希值的第一个字符在预设的字典序中的顺序，对属于同一存储区间的待存储分片进行排序。
[0191]
在本公开的一种示例性实施例中，将属于同一存储区间的待存储分片转换成待存储文件，包括：
[0192]
根据所述待存储分片所属的存储区间，对所述待存储分片进行归类；
[0193]
获取属于同一存储区间的待存储分片的场景编号以及所述存储区间的区间编码，并将所述场景编号以及所述区间编码写入所述待存储分片的键中；
[0194]
获取属于同一类别的待存储分片的版本号、过期时间以及写入时间，并将所述版本号、过期时间以及写入时间，写入所述待存储分片的值中；
[0195]
对属于同一存储区间的待存储分片进行格式转换，得到所述待存储文件。
[0196]
在本公开的一种示例性实施例中，所述数据存储装置还包括：
[0197]
第一计算模块，用于计算当前待存储文件的数据量，并判断所述数据量是否大于预设阈值；
[0198]
第一写入模块，用于若是，则将剩余的待存储分片写入下一个待存储文件。
[0199]
在本公开的一种示例性实施例中，根据所述存储区间所属的存储引擎节点，将所述存储区间中包括的待存储文件存储至所述存储引擎节点中，包括：
[0200]
根据分布式存储引擎的路由表，确定所述存储区间所对应的存储引擎节点；
[0201]
根据所述存储区间中包括的待存储文件以及所述存储区间所对应的存储引擎节点，确定所述待存储文件所对应的存储引擎节点；
[0202]
调用所述存储引擎节点所在的存储引擎服务器，拉取所述待存储文件，并将拉取到的待存储文件加载至对应的存储引擎节点中。
[0203]
在本公开的一种示例性实施例中，拉取所述待存储文件，包括：
[0204]
为所述存储引擎节点配置拉取速度值，并在所述存储引擎服务器上部署代理服务；
[0205]
通过所述代理服务控制所述存储引擎节点以所述拉取速度值拉取所述待存储文件。
[0206]
在本公开的一种示例性实施例中，将拉取到的待存储文件加载至对应的存储引擎节点中，包括：
[0207]
读取所述拉取到的待存储文件的元信息；
[0208]
基于所述元信息，将所述待存储文件添加至所述存储引擎节点中包括的日志结构的合并树中。
[0209]
在本公开的一种示例性实施例中，所述数据存储装置还包括：
[0210]
历史版本文件确定模块，用于根据所述待存储文件的值中包括的版本号，确定所述日志结构的合并树中是否存在与所述待存储文件对应的历史版本文件；
[0211]
历史版本文件删除模块，用于若存在，则对所述历史版本文件进行删除。
[0212]
在本公开的一种示例性实施例中，所述数据存储装置还包括：
[0213]
已存储文件获取模块，用于根据已存储分片的键，确定所述已存储分片所在的存储引擎节点，并从所述存储引擎节点中获取与所述已存储分片对应的已存储文件；
[0214]
已存储分片获取模块，用于从所述已存储文件中获取所述已存储分片。
[0215]
示例性存储介质
[0216]
在介绍了本公开示例性实施方式的数据存储方法和数据存储装置之后，接下来，参考图9对本公开示例性实施方式的存储介质进行说明。
[0217]
参考图9所示，描述了根据本公开的实施方式的用于实现上述方法的程序产品900，其可以采用便携式紧凑盘只读存储器(cd
‑
rom)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本公开的程序产品不限于此。
[0218]
所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd
‑
rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。
[0219]
计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质。
[0220]
可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、c 等，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备。
[0221]
示例性电子设备
[0222]
在介绍了本公开示例性实施方式的存储介质之后，接下来，参考图10对本公开示例性实施方式的电子设备进行说明。
[0223]
图10显示的电子设备1000仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
[0224]
如图10所示，电子设备1000以通用计算设备的形式表现。电子设备1000的组件可
以包括但不限于：上述至少一个处理单元1010、上述至少一个存储单元1020、连接不同系统组件(包括存储单元1020和处理单元1010)的总线1030、显示单元1040。
[0225]
其中，所述存储单元1020存储有程序代码，所述程序代码可以被所述处理单元1010执行，使得所述处理单元1010执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的步骤。例如，所述处理单元1010可以执行如图1中所示的步骤s110
‑
s130。
[0226]
存储单元1020可以包括易失性存储单元，例如随机存取存储单元(ram)10201和/或高速缓存存储单元10202，还可以进一步包括只读存储单元(rom)10203。
[0227]
存储单元1020还可以包括具有一组(至少一个)程序模块10205的程序/实用工具10204，这样的程序模块10205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。
[0228]
总线1030可以包括数据总线、地址总线和控制总线。
[0229]
电子设备1000也可以通过输入/输出(i/o)接口1050，与一个或多个外部设备1100(例如键盘、指向设备、蓝牙设备等)通信。并且，电子设备1000还可以通过网络适配器1060与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器1060通过总线1030与电子设备1000的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备1000使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。
[0230]
应当注意，尽管在上文详细描述中提及了数据存储装置的若干模块或子模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。
[0231]
应当注意，尽管在上文详细描述中提及了装置的若干单元/模块或子单元/模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。
[0232]
此外，尽管在附图中以特定顺序描述了本公开方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。
[0233]
虽然已经参考若干具体实施方式描述了本公开的精神和原理，但是应该理解，本公开并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本公开旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。