所谓推测式执行，就是计算框架判断，如果有一个task执行的过慢，则会启动备份任务，最终使用原任务+备份任务中执行较快task的结果。产生原因一般是程序bug、负载倾斜。
那么这个较慢，是怎么判断的呢？
有如下具体的算法：
比较两个时间。一是根据推测式算法计算出来的task最终完成时刻，也就是按着任务当前的运行速度，推测出来的时刻。暂且命名为oldtime
二是如果此刻启动该任务，则推测出来将要完成的时刻，这个是按着已运行完的任务推测出来的时刻。暂且命名为newtime
如果newtime的时间点在oldtime之后，则不会启动推测任务。因为即使启动了，最终完成时间是更晚的，没有意义。
oldtime计算方式： (timestamp – start) / Math.max(0.0001, progress) +taskbegintime
解释：
timestamp是当前时刻
start是任务已经运行的时间
progress是任务运行的比例（0.1-1）
taskbegintime是任务启动所用时间
加号前面计算出，按当前这个task已运行完部分的速度，计算出整个运行完会占用多少时间。
newtime计算方式：当前的时刻+已经运行完的task的平均所使用的时间是多长。
那么执行这个推测任务，都有什么先决条件呢？
1、每个task只能有一个备份任务
2、当前job已完成的task必须不小于0.05（5%）
那么，MRv2就会选择oldtime-newtime值最大的task执行推测式任务。
那么是谁来执行这个推测任务的呢？
是一个叫DefaultSpeculator（实现了Speculator）的服务，定时扫一遍task，判断是否有task需要启动备份任务。
题外话：看到大牛blog里有这么一段话，摘抄过来：
hadoop中有三种特殊的任务，failed task，killed task和speculative task，其中，failed task是由于硬件、程序bug等原因异常退出的任务，比如磁盘空间不足等，是task自己退出， killed task是Hadoop主动将其杀死的任务，比如一个任务占用过多的内存,为了不影响其他作业的正常运行，Hadoop需将这种恶心的任务杀死，以保证为所有作业提供一个“和谐”的任务执行环境。在容错方面，failed task再次调度时不会在那些曾经失败的节点上运行，而killed task则可能被再次调度到任何一个节点上（包括曾经失败多的节点），因此，如果你目测一个作业的任务运行很慢，你可以使用“bin/hadoop job -fail-task xxx”让这个任务换一个节点重新运行，而不是使用“bin/hadoop job -kill-task xxx”。 speculative task是Hadoop针对那些慢任务（慢任务会拖慢一个作业的完成时间），为他们额外启动一个备份任务，一起处理同一份数据，哪个先执行完，则采用哪个的处理结果，同时将另外一个任务杀死。也就是说，推测执行是Hadoop对慢任务的一种优化机制（实际上就是“空间换时间”的经典优化思想），不属于容错调度范畴。