大数据开发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最大输入大小，决定合并后的文件数
　　setmapred。max。split。size256000000；
　　一个节点上split的至少的大小，决定了多个datanode上的文件是否需要合并
　　setmapred。min。split。size。per。node100000000；
　　一个交换机下split的至少的大小，决定了多个交换机上的文件是否需要合并
　　setmapred。min。split。size。per。rack100000000；
　　执行Map前进行小文件合并
　　sethive。input。formatorg。apache。hadoop。hive。ql。io。CombineHiveInputF
　　四、配置hive结果合并
　　通过设置hive的配置项在执行结束后对结果文件进行合并：
　　sethive。merge。mapfilestrue在Maponly的任务结束时合并小文件
　　sethive。merge。mapredfilestrue在MapReduce的任务结束时合并小文件
　　sethive。merge。size。per。task25610001000合并文件的大小
　　sethive。merge。smallfiles。avgsize16000000当输出文件的平均大小小于该值时，启动一个独立的mapreduce任务进行文件merge
　　hive在对结果文件进行合并时会执行一个额外的maponly脚本，mapper的数量是文件总大小除以size。per。task参数所得的值，触发合并的条件是：根据查询类型不同，相应的mapfilesmapredfiles参数需要打开；结果文件的平均大小需要大于avgsize参数的值。
　　关于大数据开发，Hive小文件合并，以上就为大家做了大致的介绍了。小文件合并的问题，这里提供了两种思路去解决，具体的实施就要结合到应用场景去选择了。