CN113946289B - 基于Spark计算引擎的文件合并方法及装置、存储介质、设备 - Google Patents

Abstract

本公开涉及大数据处理领域，具体提供了一种基于Spark计算引擎的文件合并方法及装置，所述方法包括：通过Spark计算引擎对多个文件进行分析处理；在预设分区中生成多个第一文件块，并对所述文件进行存储；其中，每个第一文件块至多存储一个所述文件；根据所述预设分区所存储的文件大小及第二文件块的容量确定预生成第二文件块的数量；在判断所述预生成第二文件块的数量满足预设条件时，在所述预设分区中生成所述确定数量的第二文件块，并将所述多个第一文件块中的文件合并至所述确定数量的第二文件块；该方法能够在较少数量的文件块中对多个文件进行存储，从而节省文件系统的存储空间，提高文件系统内存使用效率和文件读取性能。

Description

基于Spark计算引擎的文件合并方法及装置、存储介质、设备

技术领域

本公开涉及大数据处理领域，具体涉及一种基于Spark计算引擎的文件合并方法及装置、存储介质、设备。

背景技术

随着互联网的高速发展，以大数据为核心的计算框架推陈出新，从支持离线数据处理的MapReduce席卷全球，到支持在线处理的Storm异军突起，支持迭代计算的Spark攻城拔寨，支持高性能数据挖掘的MPI深耕细作，大数据分析处理与存储已经广泛应用于各个领域中。Spark作为专为大规模数据处理而设计的计算引擎，以其运行速度快、具有较高通用性、运行模式多样化等特点，在快速查询系统、实时日志采集处理、业务推荐系统、定制广告系统、用户图计算等方面得到了广泛的应用。

Spark计算引擎以其分布式并行数据处理方式，在实际应用中为提高数据处理速度或避免数据汇集过程中出现过度占用内存等问题，通常会将其设置为多线程的并行数据处理方式。然而，在处理同样大小数据的情况下，并行线程数量越大，则各单行线程处理的数据量则相应变小，从而在存储系统中产生大量较小的文件，导致系统的维护难度增加，文件读取及检索性能下降。

因而，亟需提供一种方法以解决实际应用中存在的上述问题。

发明内容

本公开的目的在于提供一种基于Spark计算引擎的文件合并方法及装置，进而至少在一定程度上克服由于相关技术的限制和缺陷而导致系统内存占用过度及文件读取性能下降的问题。

根据本公开的一个方面，提供一种基于Spark计算引擎的文件合并方法，包括：

通过Spark计算引擎对多个文件进行分析处理；

在预设分区中生成多个第一文件块，并对所述文件进行存储；其中，每个第一文件块至多存储一个所述文件；

根据所述预设分区所存储的文件大小及第二文件块的容量确定预生成第二文件块的数量；

在判断所述预生成第二文件块的数量满足预设条件时，在所述预设分区中生成所述确定数量的第二文件块，并将所述多个第一文件块中的文件合并至所述确定数量的第二文件块。

在本公开的一种示例性实施例中，所述通过Spark计算引擎对多个文件进行分析处理，包括：

根据预设压缩比对所述多个文件进行压缩处理。

在本公开的一种示例性实施例中，所述根据所述预设分区所存储的文件大小及第二文件块的容量确定预生成第二文件块的数量，包括：

根据所述预设分区所存储的文件大小、第二文件块的容量及所述压缩比确定第二文件块的数量。

在本公开的一种示例性实施例中，所述将所述多个第一文件块中的文件合并至所述确定数量的第二文件块，包括：

将所述多个第一文件块按照所述第二文件块的数量进行平均划分并对所述多个第一文件块中的文件进行合并。

在本公开的一种示例性实施例中，根据所述预设分区所存储的文件大小及第二文件块的容量确定第二文件块的数量之后，还包括：

在判断所述预生成第二文件块的数量不满足预设条件时，将所述多个第一文件块存储至HDFS系统中。

在本公开的一种示例性实施例中，所述在判断所述预生成第二文件块的数量满足预设条件时，在所述预设分区内生成所述确定数量的第二文件块，并将所述多个第一文件块中的文件合并至所述确定数量的第二文件块，包括：

在判断所述预生成第二文件块的数量小于所述第一文件块的数量时，在所述预设分区内生成所述确定数量的第二文件块，并将所述多个第一文件块中的文件合并至所述确定数量的第二文件块。

在本公开的一种示例性实施例中，所述方法还包括：

获取将所述多个第一文件块中的文件合并至所述确定数量的第二文件块的合并记录信息，并对所述合并记录信息进行量化处理。

根据本公开的一个方面，提供一种基于Spark计算引擎的文件合并装置，包括：

分析处理模块，用于通过Spark计算引擎对多个文件进行分析处理；

存储模块，用于在预设分区中生成多个第一文件块，并对所述文件进行存储；其中，每个第一文件块至多存储一个所述文件；

数量确定模块，用于根据所述预设分区所存储的文件大小及第二文件块的容量确定预生成第二文件块的数量；

合并模块，用于在判断所述与预生成第二文件块的数量满足预设条件时，在所述预设分区内生成所述确定数量的第二文件块，并将所述多个第一文件块中的文件合并至所述确定数量的第二文件块。

根据本公开的一个方面，提供一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序用于执行所述基于Spark计算引擎的文件合并方法。

根据本公开的一个方面，提供一种设备，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

所述处理器，用于从所述存储器中读取所述可执行指令，并执行所述指令以实现所述基于Spark计算引擎的文件合并方法。

本公开针对性的提出了一种基于Spark计算引擎的文件合并方法，该方法在Spark计算引擎对多个文件进行分析处理的过程中，对所生成的小文件进行合并存储，一方面能够在较少数量的文件块中对多个文件进行存储，从而节省文件系统的存储空间；另一方面，该方法使得文件系统中用于维护存储文件的元数据大幅减少，以及读取同样大小所需的文件块数量和线程数量减少，从而提高文件系统内存使用效率和文件读取性能。

附图说明

图1为本公开实施方式中一种基于Spark计算引擎的文件合并方法的流程示意图；

图2为本公开实施方式中一种文件合并方法的示意图；

图3为本公开实施方式中一种文件合并方法的示意图；

图4为本公开实施方式中一种基于Spark计算引擎的文件合并装置的示意图。

具体实施方式

为使本公开的目的、特征、优点能够更加的明显和易懂，下面将结合附图对本公开实施方式及实施例中的技术方案进行清楚、完整地描述。然而，示例实施方式及实施例能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式及实施例使得本公开将更加全面和完整，并将示例实施方式及实施例的构思全面地传达给本领域的技术人员。本公开所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式及实施例中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式及实施例的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附图中所示的流程图仅是示例性说明，不是必须包括所有的步骤。例如，有的步骤还可以分解，而有的步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

在大数据相关技术的发展历程中，Spark作为一个快速、通用的大规模数据处理引擎，与Hadoop、MapReduce等具有类似的计算框架，但相对于MapReduce，Spark凭借其可伸缩、基于内存计算等特点，以及可以直接读写Hadoop上任何格式数据的优势，进行批处理时更加高效以及更低延迟的优势。在当前的相关技术应用中，Spark已经成为轻量级大数据快速处理的统一平台，实时流处理、机器学习、交互式查询等各种不同的应用均可以通过Spark建立在不同的存储和运行系统上。

然而，正如背景技术部分所述，Spark计算引擎在多并行线程数量的应用中存在着产生大量小文件的问题，所述小文件系相对体量较大的文件而言，比如在医疗领域的应用中，通过Spark计算引擎对包含挂号、就诊、药方、药品等数据进行处理，所形成的文件大都不超过1MB，便可以被称为小文件。经过Spark计算引擎处理得到的这些小文件，最终存储在诸如HDFS这样的文件系统中。HDFS对所存储的文件同样进行着维护、读取、检索等操作，当系统中存储打量小文件时，用于进行文件维护管理的HD FS元数据发生急剧膨胀，从而系统内存占压增加，文件检索、读写等效率降低。此外，系统读取同等大小的数据时，需要打开和关闭多个文件，读取成本增高。

鉴于上述Spark计算引擎产生大量小文件从而导致的一系列存储系统的问题，本公开针对性的提出了一种基于Spark计算引擎的文件合并方法，该方法通常应用于计算机等终端设备或大型服务器中。通过该方法的实施，在Spark计算引擎对原始文件进行分析处理的过程中，在预设分区中生成多个第一文件块，并对所述文件进行存储；根据所述预设分区所存储的文件大小及第二文件块的容量确定预生成第二文件块的数量；在判断所述预生成第二文件块的数量满足预设条件时，在所述预设分区中生成所述确定数量的第二文件块，并将所述多个第一文件块中的文件合并至所述确定数量的第二文件块。通过该合并方法所提供的各个步骤，能够实现在Spark计算引擎的临时存储目录中实现对小文件的合并，从而保证了最终存储到HDFS文件系统中的文件系相对较大体量的文件，从而提供了存储系统的性能。

图1系本公开实施方式中一种基于Spark计算引擎的文件合并方法的流程示意图。参考图1所示，所述方法包括以下步骤：

步骤S11:通过Spark计算引擎对多个文件进行分析处理；

Spark是基于内存的迭代计算框架，适用于需要多次操作特定数据集的应用场合。在Spark大数据处理框架中，Spark为上层多种应用提供服务。Spark SQL提供SQL查询服务，性能比Hive快3～50倍；MLlib提供机器学习服务；GraphX提供图计算服务；SparkStreaming将流式计算分解成一系列短小的批处理计算，并且提供高可靠和吞吐量服务。

在本示例性实施例中，步骤S11可以应用于诸如医疗行业大数据大数据处理，那么在步骤S11之前则还可以构建包含患者特征数据、病种数据、治疗方案与费用数据、治疗状态数据等相关参数的数据库。可以理解，大数据分析并不是对医院所有的数据都进行收集，而是对与所欲实现的目的相关的，有直接或者间接联系的数据，需要首先明确哪些数据对于战略性的决策或者细节决策有帮助的，分析出来的数据结果能够具有参考或使用价值的；以及例如哪些数据可以得临床诊疗有帮助的信息或更好的辅助诊疗效果。一般而言，在进行大数据分析处理时首先会选定特定的行业及明确欲实现的目标，有针对性的实施本公开所涉及数据分析处理方法。

具体而言，文件分析处理过程通常是将文件从一种形态转换为另一种形态，Spark计算引擎对多个文件进行分析处理，可以是根据预设压缩比对文件进行压缩并以压缩后的文件进行存储，也可以是根据文件的类型进行分类及分区存储，也可以是预先设置有特定筛选方式，从所有原始文件中筛选出符合存储目的的文件；当然也可以是为了实现复杂目的设置的多重处理方式，本示例性实施例中对此不做特殊限定。

步骤S13:在预设分区中生成多个第一文件块，并对所述文件进行存储；其中，每个第一文件块至多存储一个所述文件；

Spark计算引擎以多线程并行运行的方式对大量文件进行分析处理，因而在各单程线路依次运行完成时才能够实现所有文件的处理。各单程线路运行的过程中依次将处理完成的文件写入存储系统的临时目录中，待所有文件处理完成后再执行将其转存至最终的文件系统中的操作。预设分区系在存储文件的临时目录中创建的分布式数据集，该分区可以人为预先设定，也可以是在Spark运行过程中根据存储需要而自行设定；示例性的，分区可以根据文件产生的时间划分，例如将同一时间内产生的文件存储至同一分区内，也可以将每个APP产生的文件存储至一个分区内。

文件块系在分区中创建的用于存储的文件的存储单元，文件块的存储容量可以预先设定，例如可以设置为128MB或256MB，通常可以将其容量设置为64MB的倍数。

一般而言，文件块以一次性写入的方式对文件进行存储，对于依次完成处理的两个或多个文件难以同时写入同一文件块中，因此spark运行过程中所生成的文件块逐一存储在各文件块中；在一些文件体量较大致使一个文件块难以进行存储的特殊情况下，需要两个或者更多的文件块来存储一个文件。以下主要以小文件的存储作为示例，即一个第一文件块中存储一个文件的情形进行详细说明。

步骤S15:根据所述预设分区所存储的文件大小及第二文件块的容量确定预生成第二文件块的数量；

第一文件块和第二文件块均系在临时目录中生成的存储单元，其存储容量可以选择性设定为相同，也可以设定为不同容量，本实施例以第一文件块与第二文件块存储容量相同的情况作出示例性说明，但并不表示对其作出任何限制性描述。由于第一文件块系在文件处理过程中对文件的实时存储，一个文件块只能存储一个小文件，例如28MB的文件块仅存储一个2MB的文件，便会导致文件系统中存储资源的浪费。因而为合理调整存储空间或重新调整分区，可以先确定当前分区中所存储的文件总量，并结合第二文件块的容量确定预生成第二文件块的数量。其中，将多个第一文件块的文件合并至第二文件块系同时对多个文件进行写入存储的过程，因而第二文件块的存储方式可以是以其存储容量为限一次性写入多个文件。

在本示例性实施例中，步骤S11spark运行过程包含按照预定的压缩比对所述文件进行了压缩处理，因而在将文件合并至第二文件块时，还应当按照压缩比预留足够用于解压缩的内存空间，以避免高压缩率导致输出文件包含的信息过多导致后续读取时内存占用过高的问题。示例性的，第二文件块的数量可以根据该分区所存储的文件大小、第二文件块的容量及所述压缩比确定，如第二文件块的数量＝分区所存储的文件大小*压缩比/第二文件块的容量，也即先将所存储的文件按照压缩比进行扩展后再分配至多个第二文件块中。

步骤S17:在判断所述预生成第二文件块的数量满足预设条件时，在所述预设分区中生成所述确定数量的第二文件块，并将所述多个第一文件块中的文件合并至所述确定数量的第二文件块。

在本示例性实施例中，并非所有情形下都对第一文件块中的文件进行合并，例如spark运行过程中所处理的文件数量较小，所生成的第一文件块仅有几个、十几个甚至几十个，在这种少量文件下无需对其进行合并，因而步骤S17设定了根据预生成第二文件块的数量判断是否需要合并的情形。一方面，在文件体量相对较大的情形下，该文件可能存储在两个或多个第一文件块中，此时便难以将其合并至一个同等容量的第二文件块中；另一方面，若文件数量较少且对存储内存影响不大，为减少任务启动的开支和保证收益，系统可以存储少量的小文件，则无需对第一文件块进行合并。因此，步骤S17可以预先设定当判断预生成第二文件块的数量大于第一文件块的数量时进行合并操作，也可以设定当判断第二文件块的数量大于预设数值时进行合并操作，预设数值可以较大的任意正整数；当然也可以将上述两条件同时作为判断条件，亦属于本实施例所描述的范围。

在经过上述判断所述第一文件块中文件无需进行合并时，可以将临时目录中的文件及存储方式直接转存至最终的存储目录。其中临时目录和最终存储目录均系HDFS文件系统中的存储模块。而在判断执行合并完成合并操作后，也可以将所合并的文件及其存储方式转存至存储目录中。当然也可以理解，临时目录中存储的文件在任何情况下都可以不经执行本公开所提供的方法而直接转存至最终存储目录中，本公开未对其做详细描述并不表示相关示例无法得到执行。

具体而言，将多个第一文件块中的文件合并至所述确定数量的第二文件块存在多种实现方式，一实施例提供了一种直接对第一文件块中的文件进行合并的方法，如图2所示，合并分区系对多个第一文件块按照第二文件块的数量平均分配后直接进行合并，例如将多个第一文件块合并为2个第二文件块可以通过下述coalesce操作实现：

scala>val numsDF2＝numsDF.coalesce(2)

numsDF2:org.apache.spark.sql.Dataset[org.apache.spark.sql.Row]＝[num:int]

上述直接合并第一文件块的方法无需对其进行移动，直接在当前分区的基础之上进行了合并即可，该方法无需对文件进行移动，具有较高的合并效率。然而，按照该方法合并产生的第二文件块的大小并不均匀，后续读取时可能产生各并发输入数据量不一致的问题。

再一实施例中提供了一种通过repartition方法将文件或者文件所包含的记录信息打散(Shuffle)重新进行组合的合并方式。如图3所示，该方法将每个第一文件块中的文件按照第二文件块的数量平均分配后存储至各第二文件块，从而实现对所有文件的平均分配。该方法适用于对文件大小要求较为严格的应用场景，比如压缩比较高的数据解压缩后数据量差异较大的情形，其获得的每个文件块的数据分布比较均匀，在后续读取过程中能够使得各并发输入数据量保持一致。

在本公开的一个示例性实施例中，在对Spark计算引擎分析处理的文件进行合并后，还可以获取包含文件数量及大小、合并前后文件块数量变化等数据，根据该数据对进行量化分析。示例性的，通过获取对default数据库中的非分区表small_spark_app的进行合并的优化事件数据结构可知，合并共计15.2MB的3538个文件耗费时间为12.987秒，并且通过上述方法将存储在3538个文件块中的文件合并至1个文件中，极大的减少了在HDFS系统中所占用的内存，提高了系统的文件读取性能。再一示例性的，通过获取对共计67GB文件进行合并的量化模块数据可知，通过上述方法将存储在两万个文件块中的文件合并至两千个文件中，能够降低集群负载并提高集群的可用性。

本公开的另一实施方式提供了一种基于Spark计算引擎的文件合并装置，图4为本公开实施方式中一种基于Spark计算引擎的文件合并装置的示意图。如图4所示，基于Spark计算引擎的文件合并装置40包括：

分析处理模块42，用于通过Spark计算引擎对多个文件进行分析处理；

存储模块44，用于在预设分区中生成多个第一文件块，并对所述文件进行存储；其中，每个第一文件块至多存储一个所述文件；

数量确定模块46，用于根据所述预设分区所存储的文件大小及第二文件块的容量确定预生成第二文件块的数量；

合并模块48，用于在判断所述与预生成第二文件块的数量满足预设条件时，在所述预设分区内生成所述确定数量的第二文件块，并将所述多个第一文件块中的文件合并至所述确定数量的第二文件块。

上述基于Spark计算引擎的文件合并装置中各模块/单元的具体细节已经在对应的基于Spark计算引擎的文件合并方法部分进行了详细的描述，此处不再赘述。应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

除上述方法和设备以外，本公开的实施例还可以是计算机程序产品，其包括计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本说明书上述“示例性方法”部分中描述的根据本公开各种实施例的方法中的步骤。

所述计算机程序产品可以以一种或多种程序设计语言的任意组合来编写用于执行本公开实施例操作的程序代码，所述程序设计语言包括面向对象的程序设计语言，诸如Java、C++等，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。

本公开的另一实施方式提供了一种计算机可读存储介质，其上存储有计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本说明书上述“示例性方法”部分中描述的根据本公开各种实施例的方法中的步骤。

所述计算机可读存储介质可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以包括但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

本公开的另一实施方式提供了一种设备，可以用于执行本示例实施方式中所述方法或网络控制方法的全部或者部分步骤。所述装置包括：处理器；用于存储处理器可执行指令的存储器；其中，所述处理器被配置为执行：响应于用户在客户端的输入，根据来自所述客户端的远程输入消息更新云应用端的远程输入事件队列；以及将用于获取输入事件的应用程序接口API获取输入事件的操作重定向至所述远程输入事件队列，并对从所述远程输入事件队列获取的输入事件进行处理。

以上结合具体实施例描述了本公开的基本原理，但是，需要指出的是，在本公开中提及的优点、优势、效果等仅是示例而非限制，不能认为这些优点、优势、效果等是本公开的各个实施例必须具备的。另外，上述公开的具体细节仅是为了示例的作用和便于理解的作用，而非限制，上述细节并不限制本公开为必须采用上述具体的细节来实现。

本公开中涉及的器件、装置、设备、系统的方框图仅作为例示性的例子并且不意图要求或暗示必须按照方框图示出的方式进行连接、布置、配置。如本领域技术人员将认识到的，可以按任意方式连接、布置、配置这些器件、装置、设备、系统。诸如“包括”、“包含”、“具有”等等的词语是开放性词汇，指“包括但不限于”，且可与其互换使用。这里所使用的词汇“或”和“和”指词汇“和/或”，且可与其互换使用，除非上下文明确指示不是如此。这里所使用的词汇“诸如”指词组“如但不限于”，且可与其互换使用。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (8)

1.一种基于Spark计算引擎的文件合并方法，其特征在于，包括以下步骤：

通过Spark计算引擎对多个文件进行分析处理，所述对多个文件进行分析处理包括根据预设压缩比对所述多个文件进行压缩处理；

在预设分区中生成多个第一文件块，并对所述文件进行存储；其中，每个第一文件块至多存储一个所述文件；

根据所述预设分区所存储的文件大小及第二文件块的容量确定预生成第二文件块的数量，所述第二文件块的数量为所存储的文件大小*压缩比/第二文件块的容量；

在判断所述预生成第二文件块的数量小于所述第一文件块的数量时，在所述预设分区中生成所述确定数量的第二文件块，并将所述多个第一文件块中的文件合并至所述确定数量的第二文件块。

2.根据权利要求1所述的基于Spark计算引擎的文件合并方法，其特征在于，所述根据所述预设分区所存储的文件大小及第二文件块的容量确定预生成第二文件块的数量，包括：

根据所述预设分区所存储的文件大小、第二文件块的容量及所述压缩比确定第二文件块的数量。

3.根据权利要求1所述的基于Spark计算引擎的文件合并方法，其特征在于，所述将所述多个第一文件块中的文件合并至所述确定数量的第二文件块，包括：

将所述多个第一文件块按照所述第二文件块的数量进行平均划分并对所述多个第一文件块中的文件进行合并。

4.根据权利要求1所述的基于Spark计算引擎的文件合并方法，其特征在于，根据所述预设分区所存储的文件大小及第二文件块的容量确定第二文件块的数量之后，还包括：

在判断所述预生成第二文件块的数量不满足预设条件时，将所述多个第一文件块存储至HDFS系统中。

5.根据权利要求1至4任一项所述的基于Spark计算引擎的文件合并方法，其特征在于，还包括：

获取将所述多个第一文件块中的文件合并至所述确定数量的第二文件块的合并记录信息，并对所述合并记录信息进行量化处理。

6.一种基于Spark计算引擎的文件合并装置，其特征在于，包括：

分析处理模块，用于通过Spark计算引擎对多个文件进行分析处理，所述对多个文件进行分析处理包括根据预设压缩比对所述多个文件进行压缩处理；

存储模块，用于在预设分区中生成多个第一文件块，并对所述文件进行存储；其中，每个第一文件块至多存储一个所述文件；

数量确定模块，用于根据所述预设分区所存储的文件大小及第二文件块的容量确定预生成第二文件块的数量，所述第二文件块的数量＝所存储的文件大小*压缩比/第二文件块的容量；

合并模块，用于在判断所述预生成第二文件块的数量小于所述第一文件块的数量时，在所述预设分区内生成所述确定数量的第二文件块，并将所述多个第一文件块中的文件合并至所述确定数量的第二文件块。

7.一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序用于执行上述权利要求1-5任一项所述的基于Spark计算引擎的文件合并方法。

8.一种设备，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

所述处理器用于从所述存储器中读取所述可执行指令，并执行所述指令以实现上述权利要求1-5任一项所述的基于Spark计算引擎的文件合并方法。

Images