大数据开发：Hive小文件合并
推荐
在线提问>>
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小文件合并，以上就为大家做了大致的介绍了。小文件合并的问题，这里提供了两种思路去解决，具体的实施就要结合到应用场景去选择了。
注：本文部分文字和图片来源于网络，如有侵权，请联系删除。版权归原作者所有!此页面下方声明无效！
