我的一次Hadoop小文件Job优化预研报告

前言

    公司有日志排序的需求，目前收集环节会产生大量小文件，目前我们没有使用flume和Hbase，本次优化只涉及HDFS和MapReduce。

    关于小文件对Namenode影响，本文不涉及，我们现在使用HAR归档小文件。

    本文的结论基于HDFS大量小文件的情况。

 

一 、开启Jvm重用对Job影响：

文件数	文件大小	JVM重用	耗时	Jobid
4815	7.54 GB	Y	26mins, 5sec	job_201202211018_0034
N	51mins, 49sec	job_201202211018_0044

结论：对于大量小文件Job，开启JVM重用减少50%运行时间

 

二、Map压缩对Job影响（开启JVM重用）

 

2.1大量小文件情况

文件数	文件大小	压缩Map输出	耗时	Jobid
4815	7.54 GB	gz	38mins, 38sec	job_201202211018_0034
—	27mins, 26sec	job_201202211018_0031
lzo	27mins, 17sec	job_201202211018_0036

 

2.2每个文件140MB情况：

文件数	文件大小	压缩Map输出	耗时	Jobid
48（合并小文件）	7.54 GB	gz	29mins, 37sec	job_201202211018_0039
—	24mins, 32sec	job_201202211018_0042
lzo	19mins, 18sec	job_201202211018_0040

 

结论：

 

• 对于大量小文件Job，使用lzo压缩可以比gz压缩减少28%运行时间。
• 平均140MB输入文件的 Job比大量小文件Job减少30%的时间（jvm重用、map输出lzo）

 

三、 参数mapred.reduce.parallel.copies

 

任务时间	mapred.reduce.parallel.copies
54mins, 21sec	5（默认值）
45mins, 30sec	20

 

结论：通过配置参数mapred.reduce.parallel.copies可以提升16%性能

 

 

四、 总结

优化项	优化方法	可以减少Job时间
Jvm重用	开启jvm重用	50%
mapred.reduce.parallel.copies	默认值为5，优化值20	16%
Map输出LZO格式	默认输出为gz，修改为lzo	28%
合并小文件	合并小文件	30%

 

 

--本文来自heipark iteye博客

 

评论

1 楼 skzr.org 2013-09-06  

如果有具体的集群规模，硬件环境配置就更好了。

• 4815个文件 7.5G（平均才1.5M），估计秒级就over了，大量的耗时在jvm启动中。
如果配置成一直重用同一个jvm估计更快。
• 压缩后的效果还是很明显
• 小文将试试CombineFileInputFormat