简介
- 作业完成时间取决于最慢的任务完成时间
一个作业由若干个Map任务和Reduce任务构成.因硬件老化,软件Bug等,某些任务可能运行非常慢
典型案列: 系统中有99%的map任务都完成了,只有少数几个Map老是进度很慢,完不成怎么办? - 推测执行机制
发现拖后腿的任务,比如某个任务运行速度远慢于任务平局速度.为拖后腿任务启动一个备份任务,同时运行.谁先运行完,则采用谁的结果 - 执行推测任务的前提条件
- 每个task只能有一个备份任务
- 当前job已完成的task必须不小于0.05(5%)
- 开启推测执行参数设置.hadoop2.7.2 mapred-site.xml文件中默认是打开的
<property>
<name>mapreduce.map.speculative</name>
<value>true</value>
<description>If true, then multiple instances of some map tasks may be executed in parallel</description>
</property>
<property>
<name>mapreduce.reduce.speculative</name>
<value>true</value>
<description>If true, then multiple instances of some reduce tasks may be executed in parallel</description>
</property>
不能使用情况
- 任务存在严重的负载倾斜,有个reduce是承担了绝大多数计算的场景
- 特殊任务,比如任务向数据库中写数据,会有备份任务出来的话,写数据就会出现双倍了
算法原理
假设某一时刻,任务T的执行进度为progress,则可通过一定的算法推测出该任务的最终完成时刻.另一方面,如果此刻为该任务启动一个备份任务,则可推断出它可能的完成时刻,于是可以得出以下几个公式
estimateEndTime = estimatedRunTime + taskStartTime
推测执行完时刻60 = 推测运行时间(60s) + 任务启动时刻(0)
estimateRunTime = (currentTimestamp - taskStartTime) / progress
推测运行时间(60s) = (当前时刻(6) - 任务启动时刻(0)) / 任务运行比例(10%)
estimateEndTime丶 = currentTimestamp + averageRunTime
备份任务推测完成时刻(16) = 当前时刻(6) + 运行完成任务的平均时间(10s)
- MR总是选择(estimateEndTime - estimateEndTime丶) 差值最大的任务,并为之启动备份任务
- 为了防止大量任务同时启动备份任务造成的资源浪费,MR为每个作业设置了同时启动的备份任务数目上限
- 推测执行机制实际上采用了经典的优化算法,以空间换时间,它同时启动多个相同任务处理相同的数据,并让这些任务竞争以缩短数据处理时间.显然,这种方法需要占用更多的计算资源.在集群资源紧缺的情况下,应该合理使用该机制