爲什麼投機性執行對Giraph沒有意義？

最近我運行一些基準來了解Giraph中的故障轉移機制。爲什麼投機性執行對Giraph沒有意義？

其實我很好奇;當工作中的工人變得更慢時，其他工人就會等待它。後來我發現在GiraphJob.java是這樣的：

// Speculative execution doesn't make sense for Giraph 
giraphConfiguration.setBoolean("mapred.map.tasks.speculative.execution", false);

有誰知道爲什麼推測執行不Giraph啓用？

謝謝

來源

2014-10-27 Algorithman

首先讓我們回想一下什麼是推測執行。從Yahoo's Hadoop tutorial引用：

預測執行：與Hadoop的系統的一個問題是，在很多節點劃分任務，有可能幾個慢節點速率限制的程序的其餘部分。例如，如果一個節點有一個慢速磁盤控制器，那麼它可能只是以所有其他節點速度的10％讀取其輸入。因此，當99個地圖任務已經完成時，系統仍在等待最終地圖任務檢入，這比所有其他節點花費的時間要長得多。通過強制任務彼此獨立運行，單個任務不知道他們的輸入來自哪裏。任務信任Hadoop平臺只提供適當的輸入。因此，同一輸入可以並行處理多次，以利用機器能力的差異。隨着作業中的大部分任務即將結束，Hadoop平臺將爲剩餘的任務安排多個節點的冗餘副本，這些副本不需要其他工作來執行。這個過程被稱爲投機執行。任務完成後，他們會向JobTracker公佈這一事實。無論任務的任何副本首先完成成爲最終副本。如果其他副本是推測性執行的，則Hadoop會通知TaskTracker放棄這些任務並放棄其輸出。然後，減速器首先從任何Mapper成功完成的輸入中接收輸入。默認情況下啓用推測性執行。您可以通過mapred.map.tasks.speculative.execution和mapred.reduce.tasks.speculative.execution JobConf選項設置爲false，分別

禁用映射器和減壓器推測執行，如果我得到Giraph權利，他們不要使用推測性執行，因爲它們使用自己的迭代式計算範式，因爲它不適合。這種範例受谷歌預測的啓發，它提供了更多以圖節點爲中心的數據視圖。此外，通過檢查點創建容錯，這意味着每次迭代（也稱爲superstep）計算每個圖形節點的所有傳入消息，然後將消息分配到節點之間。

簡單地說，MapReduce並沒有用到它的原始方式，因此對於giraph的推測性執行沒有任何意義。

來源

2014-10-27 10:33:08

它是有道理的，在BSP的舊文獻中（特別是工程量測），推薦推測執行。爲什麼？因爲一個落後的任務可以完全延遲整個超級步驟（與計算回滾相同）。這是Giraph的消息模型的一個限制，沒有別的。 – 2014-10-27 10:49:33

我只是想確認一下。在這種情況下，迭代計算意味着：Giraph必須迭代地處理每個頂點。因此，如果在Giraph中啓動投機性執行，那麼它會違反Giraph的規則，處理事情不合適。對？如果啓用投機執行，會發生什麼情況？會導致不一致嗎？ – Algorithman 2014-10-27 11:01:21

@Vincentius：我不確定我是否正確。但請注意，Giraph不是迭代地處理頂點，而是其算法步驟。對於這些步驟中的每一個步驟，圖表中的每個節點（簡單地說）分析它是傳入的消息。這對每個節點都是異步並行完成的。由於Giraph無法使用它，啓用投機執行根本沒有意義。 – 2014-10-28 07:43:58

爲什麼投機性執行對Giraph沒有意義？

回答

相關問題