出现map没结束,就跑reduce的情况


跑其他的mr任务没有出现这种情况,一直以为是跑完map再跑reducer

这里会涉及到一个阈值的问题就是当map任务完成到多少的时候就会启动reduce任务,并不是map结束后才跑reduce

  1. 什么是Shuffle?

    Hadoop的shuffle过程就是从map端输出到reduce端输入之间的过程,这一段应该是核hadoop中最心的部分,因为涉及到Hadoop中最珍贵的网络资源

  1. Map阶段:这里以一个Map任务为例,inputSplit(切片)的数量代表Map任务的数量,当Map任务提交的数据会存在buffer in memory(内存中的溢写缓冲区或是环形内存缓冲区)(数据已经分好区和排序)中,默认溢写缓冲区的大小为100M,溢写阈值为80M,当溢写缓冲区中的数据达到80M,一个后台线程会将内容写入本地磁盘的Spill文件(分区和排序),Spill文件可能生成多个(不能单纯根据128M切片来决定Spill文件数量,由Mapper里面的代码决定)当一个任务完成时,即不再输出k,v时的时候,开始合并Merge文件结果文件(分区和排序)。

  注意:map过程的输出是写入本地磁盘而不是HDFS,但是一开始数据并不是直接写入磁盘而是缓冲在内存中,好处在于减少磁盘IO的开销,提高合并和排序的速度。所以在在map中尽量减少内存的使用,为shuffle过程预留更多的内存,因为该过程是最耗时的。

 

  1. Reduce阶段:Reducer通过Http方式得到输出文件的分区。reduce端可能从n个map的结果中获取数据,而这些map的执行速度不尽相同,当其中一个map运行结束时,reduce就会从 JobTracker中获取该信息。map运行结束后TaskTracker会得到消息,进而将消息汇报给JobTracker,reduce定时从 JobTracker获取该信息,reduce端默认有5个数据复制线程从map端复制数据。然后将这些文件合并方为最终的Merge文件,合并的结果作为reduce的输入而不是写入到磁盘中。当Reducer的输入文件确定后,整个Shuffle操作才最终结束。之后就是Reducer的执行了,最后Reducer会把结果存到HDFS上。

 

 2.Hadoop调优策略

  a.调节溢写缓冲区大小,减少Spill溢写次数,减少磁盘I/O次数

  b.加入Combiner中间过程,在溢写缓冲区就会发生Combiner,好处是:

  比如——hello 1 hello 1一共占14个字节,Combiner 后,变为hello 2 。所以也能够间接减

  少Spill溢写次数,从而提高性能。

  c.加入Combiner中间过程,在Merger过程中,可能会发生Combiner,意义是能够减少最后

  结果的大小,从而能够减少Reduce Fetch的数据量,节省带宽,提供性能。

  注:为什么有可能不发生Combiner,如果最后的Spill文件数量是一个,则Spill文件相当于是

  最后的结果文件——即没有Merge过程——也就没有Combiner过程。此外,当Spill文件是2

  个时候,也不会发生Combiner。

  综上:在Merger过程,如果Spill文件的数量小于3,则不会发生Combiner。

  d.在Reduce 抓取分区数据时,是由线程来处理的,为了提高效率,我们的策略是让抓取线程

  尽可能等于或接近于Map任务数量,从而达到并行抓取的效果。

  e.适当调大Merge合并因子(Hadoop默认是10)

  f.Reduce任务并不是等所有的Map任务都完成后才启动的,Hadoop有一个默认的启动阈

  值,5%0.05)。所以这个值可以适当减小。

猜你喜欢

转载自blog.csdn.net/m0_37443131/article/details/81206210