Hadoop小文件优化

一、Hadoop小文件弊端

1、小文件多会占用大量NameNode的内存空间（每个元数据的大小约150byte）

2、元数据文件过多，使得寻址索引速度变慢

3、小文件过多启动MapTask数量多，有可能处理时间比启动时间还短，白白消耗资源

二、解决方案

3个方向，4个方面

1、数据源头方向

在数据采集时，就将小文件或小批数据合并成大方件再上传HDFS

2、存储方向

（1）har文件-文件归档，是一个高效的将小文件放入HDFS块中的文件存档工具，即将多个小文件打包成一个Har文件。

（2）HDFS存档文件对内还是一个个独立文件，对NameNode而言却是一个整体，减少NameNode内存使用

3、计算方向

（1）使用CombineTextInputFormat将多个小文件在切片过程中合并切片，减少切片数量

        job.setInputFormatClass(CombineTextInputFormat.class)

        CombineTextInputFormat.setMaxInputSplitSize(job,4194304)

（2）开启uber模式，实现JVM重用。

        默认情况下每个task任务都要启动一个JVM来运行，如果task任务计算的数据量很小，可以让同一个job的多个task运行在一个JVM中，不必为每个task都开启一个JVM。（如果job任务足够小，则直接让任务串行的在MRAppMaster完成，这样整个Application只会使用一个Container（JVM重用功能），相对于分配多个Container来说执行效率要高很多。）

        mapred-site.xml 4个参数：

 仅仅满足以上四个参数还不行，因为作业是在AM所在的Container中运行，Uber任务执行还应满足如下条件：

(1) Map内存设置（mapreduce.map.memory.mb）和Reduce内存设置（mapreduce.reduce.memory.mb）必须小于等于AM所在容器内存大小设置（yarn.app.mapreduce.am.resource.mb）。

(2) Map配置的vcores（mapreduce.map.cpu.vcores）个数和 Reduce配置的vcores（mapreduce.reduce.cpu.vcores）个数也必须小于等于AM所在容器vcores个数的设置（yarn.app.mapreduce.am.resource.cpu-vcores）。