建站
咨詢
售后
建站咨詢
新聞中心
本文將分析Hadoop MapReduce（包括MRv1和MRv2）的兩種常見的容錯場景，***種是，作業(yè)的某個任務(wù)阻塞了，長時間占用資源不釋放，如何處理？另外一種是，作 業(yè)的Map Task全部運行完成后，在Reduce Task運行過程中，某個Map Task所在節(jié)點掛了，或者某個Map Task結(jié)果存放磁盤損壞了，該如何處理？
讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴，公司提供的服務(wù)項目有：空間域名、網(wǎng)頁空間、營銷軟件、網(wǎng)站建設(shè)、青浦網(wǎng)站維護(hù)、網(wǎng)站推廣。
***種場景：作業(yè)的某個任務(wù)阻塞了，長時間占用資源不釋放，如何處理？
這種場景通常是由于軟件Bug、數(shù)據(jù)特殊性等原因?qū)е碌?，會讓程序阻塞，任?wù)運行停滯不前。在外界看來，任務(wù)（Task）好像阻塞了一樣。這種事情 經(jīng)常發(fā)生，由于任務(wù)長時間占用著資源但不使用（如果不采取一定的手段，可能永遠(yuǎn)不會被使用，造成“資源泄露”），會導(dǎo)致資源利用率下降，對系統(tǒng)不利，那 么，Hadoop MapReduce遇到這種情況如何處理呢？
在TaskTracker上，每個任務(wù)會定期向TaskTracker匯報新的進(jìn)度（如果進(jìn)度不變則不匯報），并由TaskTracker進(jìn)一步匯 報給JobTracker。當(dāng)某個任務(wù)被阻塞時，它的進(jìn)度將停滯不前，此時任務(wù)不會向TaskTracker匯報進(jìn)度，這樣，一定達(dá)到超時時間上 限，TaskTracker會將該任務(wù)殺掉，并將任務(wù)狀態(tài)（KILLED）匯報給JobTracker，進(jìn)而觸發(fā)JobTracker重新調(diào)度該任務(wù)。
在實際應(yīng)用場景中，有些正常的作業(yè)，其任務(wù)可能長時間沒有讀入或者輸出，比如讀取數(shù)據(jù)庫的Map Task或者需要連接其他外部系統(tǒng)的Task，對于這類應(yīng)用，在編寫Mapper或Reducer時，應(yīng)當(dāng)啟動一個額外的線程通過Reporter組件定 期向TaskTracker匯報心跳（只是告訴TaskTracker自己還活著，不要把我殺了）。
第二種場景：作業(yè)的Map Task全部運行完成后，在Reduce Task運行過程中，某個Map Task所在節(jié)點掛了，或者M(jìn)ap結(jié)果存放磁盤損壞了，該如何處理？
這種場景比較復(fù)雜，需分開討論。
如果節(jié)點掛了，JobTracker通過心跳機(jī)制知道TaskTracker死掉了，會重新調(diào)度之前正在運行的Task和正在運行的作業(yè)中已經(jīng)運行完成的Map Task。
如果節(jié)點沒有掛，只是存放Map Task結(jié)果的磁盤損壞了，則分兩種情況：
（1）所有的Reduce Task已經(jīng)完成shuffle階段
（2）尚有部分Reduce Task沒有完成shuffle階段，需要讀取該Map Task任務(wù)
對于***種情況，如果所有Reduce Task一路順風(fēng)地運行下去，則無需對已經(jīng)運行完成的Map Task作任何處理，如果某些Reduce Task一段時間后運行失敗了，則處理方式與第二種一樣。
對于第二種情況，當(dāng)Reduce Task遠(yuǎn)程讀取那個已經(jīng)運行完成的Map Task結(jié)果(但結(jié)果已經(jīng)損壞)時，會嘗試讀取若干次，如果嘗試次數(shù)超過了某個上限值，則會通過RPC告訴所在的TaskTracker該Map Task結(jié)果已經(jīng)損壞，而TaskTracker則進(jìn)一步通過RPC告訴JobTracker，JobTracker收到該消息后，會重新調(diào)度該Map Task，進(jìn)而重新計算生成結(jié)果。
需要強(qiáng)調(diào)的是，目前Hadoop MapReduce的實現(xiàn)中，Reduce Task重試讀取Map Task結(jié)果的時間間隔是指數(shù)形式遞增的，計算公式是10000*1.3^noFailedFetches，其中noFailedFetches取值范圍 為MAX{10， numMaps/30}，也就是說，如果map task數(shù)目是300，則需要嘗試10次才會發(fā)現(xiàn)Map Task結(jié)果已經(jīng)損壞，嘗試時間間隔分別是10s，13s，21s，28s，37s，48s，62s，81s和106s，需要非常長的時間才能發(fā)現(xiàn)，而且 Map Task越多，發(fā)現(xiàn)時間越慢，這個地方通常需要調(diào)優(yōu)，因為任務(wù)數(shù)目越多的作業(yè)，越容易出現(xiàn)這種問題。
在MapReduce V2.0中，所有任務(wù)（Map Task和Reduce Task）直接跟MRAppMaster交互，不需要通過類似于TaskTracker這樣的中間層，整個過程與上述過程類似，在此不再贅述，具體可閱讀書籍《Hadoop技術(shù)內(nèi)幕：深入解析YARN架構(gòu)設(shè)計與實現(xiàn)原理》中的“第8章 離線計算框架MapReduce”。
當(dāng)前文章：HadoopMapReduce兩種常見的容錯場景分析
文章轉(zhuǎn)載：http://m.5511xx.com/article/dhdehep.html
