一种基于Spark合并hive小文件的方法及系统技术方案

技术编号:34857216 阅读:13 留言:0更新日期:2022-09-08 07:59
本申请公开了一种基于Spark合并hive小文件的方法及系统,所述方法包括:配置需要合并的库、表、分区信息;读取分区路径的总存储空间和文件个数;根据分区路径的文件个数和文件大小来判断是否需要合并文件;结合HDFS的块大小,计算合并之后的文件个数M;使用Spark将分区中的文件全部读取到内存中,转换成DataFrame;使用Spark的coalesce算子,将DataFrame按M个文件写到HDFS的临时目录下;使用SparkSql将临时目录中的数据覆盖至Hive分区中。本申请避免了过多小文件造成的资源浪费,同时确保了集群的稳定性。同时确保了集群的稳定性。同时确保了集群的稳定性。

【技术实现步骤摘要】
一种基于Spark合并hive小文件的方法及系统


[0001]本专利技术涉及大数据计算
,尤其涉及一种基于Spark合并hive小文件的方法及系统。

技术介绍

[0002]HDFS(Hadoop Distributed File System,Hadoop分布式文件系统),是为大数据设计的分布式文件系统。HDFS是一个主/从(Master/Slave)体系结构,一个HDFS集群由一个管理节点(NameNode)和多个数据节点(DataNode)组成。NameNode为元数据节点,管理文件系统的元数据,NameNode将文件系统的元数据存放在内存中。DataNode为数据节点,存储实际的文件数据。由于在HDFS中NameNode只有一个,因此NameNode的可靠性是影响HDFS可靠性的重要因素。
[0003]元数据存储一般为小文件存储,虽然每个小文件所占内存空间较小,但是每个小文件均需占用一个内存块,每个内存块的存储空间约为150字节,那么存储一千万个文件,则NameNode对应地存储管理文件系统目录等信息大约需要3G的空间,即存储的文件数目和集群规模会严重受限于NameNode的内存大小。如果集群产生大量小文件而不处理,长期下去,过多的小文件存储会大量消耗namenode节点的存储量,必将给NameNode造成巨大压力,影响NameNode的性能。同时,对于hive、Spark计算时,会生成很多文件,每个文件大小只有几Kb,小文件意味着需要更多的task和资源,造成资源的浪费,影响计算速度,同时影响集群的稳定性。
[0004]因此,HDFS对大数据的存储做了针对性的优化,但却不适合存储海量小文件。使用Spark运算时,集群小文件过多会影响NameNode性能,也变相影响数据集群的使用问题。如何解决Spark运算时集群小文件过多的问题,是本领域技术人员亟待解决的问题。

技术实现思路

[0005]本专利技术的目的在于提供一种基于Spark合并hive小文件的方法及系统,以解决上述技术背景中提出的问题。
[0006]为实现上述目的,本专利技术采用以下技术方案:本申请第一个方面提供了一种基于Spark合并hive小文件的方法,包括:S1,配置需要合并的库、表、分区信息;S2,根据配置的信息,判断分区路径是否有数据;S3,读取分区路径的总存储空间和文件个数;S4,根据分区路径的文件个数和文件大小来判断是否需要合并文件,如果分区路径的文件个数大于预设下限值且分区路径的文件大小远远小于HDFS的块大小,则进行文件合并;S5,结合HDFS的块大小,计算合并之后的文件个数M;S6,使用Spark将分区中的文件全部读取到内存中,转换成 DataFrame;
S7,使用Spark的coalesce算子,将DataFrame 按M个文件写到HDFS的临时目录下;S8,使用SparkSql将临时目录中的数据覆盖至Hive分区中。
[0007]优选地,所述步骤S4中,所述预设下限值为1个。
[0008]优选地,所述步骤S4中,所述文件合并是按照预设的任务规则对分区中的多个小文件进行合并,所述任务规则包括:读取分区路径的各个文件大小,对文件大小远远小于HDFS的块大小的文件进行合并,当文件大小大于或等于HDFS的块大小的情况下,不对大于或等于HDFS的块大小的文件进行合并。
[0009]优选地,所述步骤S4中,合并后的文件包括:文件头和文件内容,所述文件头包括合并前所有文件的名称,所述文件内容包括合并前所有文件的数据。
[0010]优选地,所述步骤S5中,所述HDFS的块大小默认为128Mb。
[0011]优选地,所述步骤S5中,计算合并之后的文件个数M,采用如下计算公式:M=Math.ceil(T/S);其中,Math.ceil()函数返回大于等于给定参数的最小整数,即对浮点数向上取整;T表示分区路径的总存储空间,单位Mb;S表示HDFS的块大小,单位Mb。
[0012]优选地,所述步骤S8中,使用SparkSql中的“load data inpath overwrite
”ꢀ
语法,将临时目录中数据覆盖至Hive分区中。
[0013]本申请第二个方面提供了一种基于Spark合并hive小文件的系统,包括:配置模块,用于配置需要合并的库、表、分区信息;判断模块,用于根据配置的信息,判断分区路径是否有数据;读取模块,用于读取分区路径的总存储空间和文件个数;合并模块,用于根据分区路径的文件个数和文件大小来判断是否需要合并文件,如果分区路径的文件个数大于预设下限值且分区路径的文件大小远远小于HDFS的块大小,则进行文件合并;计算模块,用于结合HDFS的块大小,计算合并之后的文件个数M;转换模块,用于使用Spark将分区中的文件全部读取到内存中,转换成 DataFrame;临时写入模块,用于使用Spark的coalesce算子,将DataFrame 按M个文件写到HDFS的临时目录下;Hive分区写入模块,用于使用SparkSql将临时目录中的数据覆盖至Hive分区中。
[0014]本申请第三个方面公开了一种电子设备,包括:存储器;以及至少一个处理器;其中,所述存储器存储计算机执行指令;所述至少一个处理器执行所述存储器存储的计算机执行指令,使得所述至少一个处理器执行如上述的基于Spark合并hive小文件的方法。
[0015]本申请第四个方面公开了一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机执行指令,当处理器执行所述计算机执行指令时,实现如上述的基于Spark合并hive小文件的方法。
[0016]与现有技术相比,本专利技术的技术方案具有以下有益效果:本申请利用Spark可以对文件数据重新合并的能力,减少文件数量,增加文件大小,提高了读写能力,解决了在大数据存储与计算中,由于hive小文件过多给分布式文件系统带来的管理压力,避免了过多小文件造成的资源浪费,同时确保了集群的稳定性。
附图说明
[0017]构成本申请的一部分附图用来提供对本申请的进一步理解,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:图1是本专利技术实施例提供的基于Spark合并hive小文件的方法的流程示意图;图2是本专利技术实施例提供的基于Spark合并hive小文件的系统的结构示意图;图3是本专利技术实施例提供的一种电子设备的结构示意图。
具体实施方式
[0018]为使本专利技术的目的、技术方案及效果更加清楚、明确,以下参照附图并举实例对本专利技术进一步详细说明。应当理解,此处所描述的具体实施例仅用以解释本专利技术,并不用于限定本专利技术。
[0019]需要说明的是,本专利技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序,应该理解这样使用的数据在适当情况下可以互换。此外,术语“包括”和“具有”以及它们的任何变形,意图在于覆盖不排他的包含,例如,包含了一本文档来自技高网
...

【技术保护点】

【技术特征摘要】
1.一种基于Spark合并hive小文件的方法,其特征在于,包括:S1,配置需要合并的库、表、分区信息;S2,根据配置的信息,判断分区路径是否有数据;S3,读取分区路径的总存储空间和文件个数;S4,根据分区路径的文件个数和文件大小来判断是否需要合并文件,如果分区路径的文件个数大于预设下限值且分区路径的文件大小远远小于HDFS的块大小,则进行文件合并;S5,结合HDFS的块大小,计算合并之后的文件个数M;S6,使用Spark将分区中的文件全部读取到内存中,转换成 DataFrame;S7,使用Spark的coalesce算子,将DataFrame 按M个文件写到HDFS的临时目录下;S8,使用SparkSql将临时目录中的数据覆盖至Hive分区中。2.根据权利要求1所述的一种基于Spark合并hive小文件的方法,其特征在于,所述步骤S4中,所述预设下限值为1个。3.根据权利要求1所述的一种基于Spark合并hive小文件的方法,其特征在于,所述步骤S4中,所述文件合并是按照预设的任务规则对分区中的多个小文件进行合并,所述任务规则包括:读取分区路径的各个文件大小,对文件大小远远小于HDFS的块大小的文件进行合并,当文件大小大于或等于HDFS的块大小的情况下,不对大于或等于HDFS的块大小的文件进行合并。4.根据权利要求1所述的一种基于Spark合并hive小文件的方法,其特征在于,所述步骤S4中,合并后的文件包括:文件头和文件内容,所述文件头包括合并前所有文件的名称,所述文件内容包括合并前所有文件的数据。5.根据权利要求1所述的一种基于Spark合并hive小文件的方法,其特征在于,所述步骤S5中,所述HDFS的块大小默认为128Mb。6.根据权利要求1所述的一种基于Spark合并hive小文件的方...

【专利技术属性】
技术研发人员:施明
申请(专利权)人:上海二三四五网络科技有限公司
类型:发明
国别省市:

网友询问留言 已有0条评论
  • 还没有人留言评论。发表了对其他浏览者有用的留言会获得科技券。

1