关于hadoopV1中reduce提前启动的问题

 

   为什么reduce要提前启动(默认是5%)而不是等到最后map执行完了再启动?

 
 有人认为如果map任务没有完成，提前启动reduce任务没有意义，因为数据必须等map执行完才能是完整的数据。
 而且这样会造成reduce的"slot hoarding"现象，
 个人理解的话，有两个原因:
  1.reduce提前启动进行shuffle的话，会减少后续的数据传输量，这样减轻了后面的数据传输量(I/O是主要的时间瓶颈之一)以及后续的网络负载。 这个是主要原因。
  2. 以排序为例的话，数据基本有序的话，再排序的话会快很多，
 同理，reduce对前面的数据整理，使其基本有序后，再有少量新数据进来的话，效率比从完全是一堆无序的数据要快的多。

 

  此外，在

中小规模Hadoop集群优化

http://blog.csdn.net/azhao_dn/article/details/6955671中提到:

 

" 8. mapred.reduce.slowstart.completed.maps

这个参数控制slowstart特性的时机，默认是在5%的map任务完成后，就开始调度reduce进程启动，开始copy过程。

但是我们的机器数量不多，有一次大量的任务堆积在JobTracker里，每个TaskTracker的map和reduce slots都跑满了。

由于map没有足够资源迅速完成，reduce也就无法结束，造成集群的资源互相死锁。

把这个参数改成了0.75，任务堆积的列表从平均10个，变成了3个。 "

 

  这里的意思是reduce较早启动的话，会造成死锁。

  我的疑惑是: 为什么会造成死锁?  map任务对reduce任务又没有依赖，为什么会产生死锁呢?  或者这里"死锁" 这个词用的不是很合适。map任务最终会结束，reduce任务自然就能结束，不会像OS中的死锁概念，双方互相制约导致无法结束。

        在过了很久之后，终于有位大神回我了(http://blog.csdn.net/azhao_dn/article/details/6955671#comments): 

1楼  cloudeagle_bupt 2013-05-28 10:30发表 [回复] [引用] [举报] [删除]

您好，这里我非常困惑您说的第8点，“由于map没有足够资源迅速完成，reduce也就无法结束，造成集群的资源互相死锁。” map任务对reduce任务没有依赖性，而且TT上的map slot资源和reduce资源限制之间也没有关系，为什么会形成"死锁"呢?

Re:  小悟空 2013-10-15 19:07发表 [回复] [引用] [举报]

回复cloudeagle_bupt：我看到这个地方，没人回复，解释一下
当提交一个任务，map执行还没结束，结果reduce已经占用了全部的槽位，这个时候，来了一个高优先级的job，第一个job的map停止执行，而第一个job占用的reduce不会释放，第二个job执行时，无法得到reduce，这样，结果就是，第二个高优先级的job只有等到第一个job的reduce执行结束之后才能执行第二个job的reduce，这个是一个很令人头疼的“死锁”当然，没死。

Re:  cloudeagle_bupt 2013-10-15 19:56发表 [回复] [引用] [举报] [删除]

回复wukonwukon：请问为什么第一个job的reduce不会释放？ 第2个job的优先级比较高的话，为什么其reduce任务不会抢占第1个job的reduce槽位呢?

Re:  小悟空 2013-10-16 17:22发表 [回复] [引用] [举报]

回复cloudeagle_bupt：这个是hadoop的优先级的特点，高优先级的不会抢占正在执行的低优先级的槽位，当低优先级的map或者reduce执行结束之后，槽位会优先分配给高优先级的，以此来确定高低优先级。
hadoop优先级，是非抢占式的。。