遇到问题---hadoop---reduce执行时又重新map

遇到的情况

我们在运行一个2T的hive数据进行动态分区，发现运行了很长时间的mapreduce在reduce运行过程中又重新启动了一次map。

如图

原因

分析到的原因可能有两个

一是有异常报错，reduce入库时一直失败，很多个fail或者kill，hadoop启用推测执行机制。hadoop针对慢或者老是失败的任务额外启动一个备份任务，一起处理同一份数据，哪个先执行完，则采用哪个的处理结果，同时将另外一个任务杀死。也就是说，推测执行是Hadoop对慢任务的一种优化机制（实际上就是“空间换时间”的经典优化思想），不属于容错调度范畴。可以通过参数调整禁止推测执行。

二是因为导致失败的原因未排除，重复执行任务，导致内存超出或者硬盘不足，节点挂掉。

我们看到图里就是250挂掉了，任务重新在217执行。所以很大原因是这个。

解决方式

排查fail和kill的原因，解决掉

hadoop中有三种特殊的任务，failed task，killed task和speculative task.

其中，failed task是由于硬件、程序bug等原因异常退出的任务，比如磁盘空间不足等，

killed task是Hadoop主动将其杀死的任务，比如一个任务占用过多的内存,为了不影响其他作业的正常运行，

Hadoop需将这种任务杀死，以保证为所有作业提供一个“和谐”的任务执行环境。

failed task再次调度时不会在那些曾经失败的节点上运行，而killed task则可能被再次调度到任何一个节点上（包括曾经失败多的节点），

因此，如果你目测一个作业的任务运行很慢，你可以使用“bin/hadoop job -fail-task xxx”让这个任务换一个节点重新运行，

而不是使用“bin/hadoop job -kill-task xxx”。 speculative task是Hadoop针对那些慢任务（慢任务会拖慢一个作业的完成时间），

为他们额外启动一个备份任务，一起处理同一份数据，哪个先执行完，则采用哪个的处理结果，同时将另外一个任务杀死。

也就是说，推测执行是Hadoop对慢任务的一种优化机制（实际上就是“空间换时间”的经典优化思想），不属于容错调度范畴。

除了及时排查异常之外，还要保障集群的健康状态，防止重要节点挂掉导致任务重新执行。