第十一篇:Map/Reduce 工作機制分析 - 錯誤處理機制

穆晨發表於2017-05-20

前言

       對於Hadoop叢集來說,節點損壞是非常常見的現象。

       而Hadoop一個很大的特點就是某個節點的損壞,不會影響到整個分散式任務的執行。

       下面就來分析Hadoop平臺是如何做到的。

硬體故障

       硬體故障可以分為兩種 - JobTracker節點損壞和TaskTracker節點損壞。

1. JobTracker節點損壞

       這是Hadoop叢集中最為嚴重的錯誤。

       出現了這種錯誤,那就只能重新選擇JobTracker節點,而在選擇期,所有的任務都必須停掉,而且當前已經完成了的任務也必須通通重來。

2. TaskTracker節點損壞

       這是Hadoop叢集中最常見的錯誤。對於這類錯誤,Hadoop有完好的錯誤處理機制。

       JobTracker和TaskTracker的心跳通訊機制要求TaskTracker保證在1分鐘之內向JobTracker彙報進展。

       如果超過時間JobTracker沒有收到彙報,就會將該TaskTracker從等待排程的集合中移除出去;

       而如果收到任務失敗的的報告,就把這個TaskTracker移動到等待排程佇列尾部重新排隊。但是若一個TaskTracker連續彙報了四次失敗,那麼也會被移出任務等待佇列。

小結

       關於故障的處理維護,一般會由專人來進行管理。

       這部分內容就暫且不做深究了。

相關文章