作業完成時間取決於最慢的任務完成時間
一個作業由若干Map任務和Reduce任務構成,但因硬體老化,軟體BUG,某些任務可能執行非常慢
典型案例：系統中有 99%的 Map 任務都完成了，只有少數幾個 Map 老是進度很慢，完不成，怎麼辦？

推測執行機制
發現拖後腿的任務,比如某個任務執行速度遠慢於任務平均速度,為拖後腿任務啟動一個備份任務,同時執行,誰先執行完,就用誰的結果

執行推測任務的前提條件

(1) 每個task只能一個備份任務
(2)當前job已完成的task必須不小於5%
(3)開始推測執行引數設定 修改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>
 

不能啟用推測執行機制情況

(1) 任務間存在嚴重的負載傾斜 比如兩個節點 第一個節點跑90%的任務,第二個節點跑的少
(2)特殊任務,比如任務向資料庫中寫資料

演算法原理

假設某一個時刻,任務T的執行進度為process,可以通過一定的演算法推測出該任務的最終完成時刻, estimateEndTime,另一方面,如果此刻為該任務啟動一個備份任務,則可以推斷出它可能完成時刻,estimateEndTime,則可以退出公式

 estimateEndTime = estimatedRunTime + taskStartTime
 推測執行完時刻 60 = 推測執行時間（60s） + 任務啟動時刻（0）

 estimatedRunTime = (currentTimestamp - taskStartTime) / progress
 推測執行時間（60s） =（當前時刻（6） - 任務啟動時刻（0）） / 任務執行比例（10%）
 
 estimateEndTime` = currentTimestamp + averageRunTime
 備份任務推測完成時刻（16） = 當前時刻（6） + 執行完成任務的平均時間（10s）
 

1. MR總是選擇（estimateEndTime- estimateEndTime ` ）差值最大的任務，併為之啟動備份任務。
2. 為了防止大量任務同時啟動備份任務造成的資源浪費，MR為每個作業設定了同時啟動的備份任務數目上限。
3. 推測執行機制實際上採用了經典的優化演算法：以空間換時間，它同時啟動多個相同任務處理相同的資料，並讓這些任務競爭以縮短資料處理時間。顯然，這種方法需要佔用更多的計算資源。在叢集資源緊缺的情況下，應合理使用該機制，爭取在多用少量資源的情況下，減少作業的計算時間。