Hadoop生态技术体系下，负责大数据存储管理的组件，涉及到HDFS、Hive、Hbase等。Hive作为数据仓库工具，最初的存储还是落地到HDFS上，这其中就有一个关键的环节，是小文件的处理。今天的大数据开发分享，我们就主要来讲讲，Hive小文件合并。

　　本身来说，由于Hadoop的特性，对大文件的处理非常高效。大文件可以减少文件元数据信息，减轻NameNode的存储压力。相对于上层的数据表汇总程度高，底层就会面临小文件越来越多的问题。

　　一、小文件带来的问题

　　HDFS的文件包好数据块和元信息，其中元信息包括位置、大小、分块等信息，都保存在NameNode的内存中。每个对象大约占用150个字节，因此一千万文件及分块就会占用约3G的内存空间，一旦接近这个量级，NameNode的性能就会开始下降。

　　HDFS读写小文件时也会更加耗时，因为每次都需要从NameNode获取元信息，并且对应的DataNode建立连接。对于MapReduce程序来说，小文件会增加Mapper的数量，每个Map任务只会处理很少的数据，浪费大量的调度时间。

　　二、Hive小文件产生的原因

　　一方面hive数据仓库中汇总表的数据量通常比源数据少的多，而且为了提升运算速度，我们会增加Reduce的数量，Hive本身也会做类似的优化——Reducer数量等于源数据的量除以hive.exec.reducers.bytes.per.reduce所配置的量(默认1G)。Reduce数量的增加也即意味着结果文件的增加，从而产生小文件的问题。

　　解决小文件的问题可以从两个方向入手：

　　①输入合并。即在map前合并小文件。

　　②输出合并。即在输出结果的时候合并小文件。

　　三、配置Map输入合并

　　--每个Map最大输入大小，决定合并后的文件数

　　set mapred.max.split.size=256000000;

　　--一个节点上split的至少的大小，决定了多个data node上的文件是否需要合并

　　set mapred.min.split.size.per.node=100000000;

　　--一个交换机下split的至少的大小，决定了多个交换机上的文件是否需要合并

　　set mapred.min.split.size.per.rack=100000000;

　　--执行Map前进行小文件合并

　　set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;

　　四、配置hive结果合并

　　通过设置hive的配置项在执行结束后对结果文件进行合并：

　　set hive.merge.mapfiles=true#在Map-only的任务结束时合并小文件

　　set hive.merge.mapredfiles=true#在Map-Reduce的任务结束时合并小文件

　　set hive.merge.size.per.task=256*1000*1000#合并文件的大小

　　set hive.merge.smallfiles.avgsize=16000000#当输出文件的平均大小小于该值时，启动一个独立的map-reduce任务进行文件merge

　　hive在对结果文件进行合并时会执行一个额外的map-only脚本，mapper的数量是文件总大小除以size.per.task参数所得的值，触发合并的条件是：根据查询类型不同，相应的mapfiles/mapredfiles参数需要打开;结果文件的平均大小需要大于avgsize参数的值。

　　关于大数据开发，Hive小文件合并，以上就为大家做了大致的介绍了。小文件合并的问题，这里提供了两种思路去解决，具体的实施就要结合到应用场景去选择了。

　　注：本文部分文字和图片来源于网络，如有侵权，请联系删除。版权归原作者所有!此页面下方声明无效！

上一篇

HDFS的故障恢复和高可用

下一篇

HDFS架构演进之路