典型問題：Hadoop如何判斷一個任務失敗？失敗了怎么做？
分析：實際情況下，用戶代碼存在軟件錯誤、進程崩潰、機器故障等都會導致失敗。Hadoop判斷的失敗有不同級別類型，針對不同級別的失敗有不同的處理對策，這就是MapReduce的容錯機制。下面是幾個不同級別失敗的分類：
一、任務失敗
分為3種情況：Task失敗、子進程JVM退出、超時檢測被關閉。
1.任務失敗。最常見的是Map或Reduce任務的失敗，即寫的本身MR代碼導致失敗。發生Map或Reduce失敗的時候，子任務JVM進程會在退出之前向上一級TaskTracker發送錯誤報告。錯誤報告最后悔記錄在用戶的錯誤日志里面，TaskTracker會將此次task attempt標記為failed，釋放一個任務槽slot用來運行另一個任務。
2. 子進程JVM突然退出。可能由於JVM的bug導致，從而導致MapReduce用戶代碼執行失敗。在這種情況下，TaskTracker會監控到進程以便退出，並將此次嘗試標記為“failed”失敗。
3. 關閉了超時連接（把超時timeout設置成0）。所以長時間運行的任務永不會被標記failed。在這種情況下，被掛起的任務永遠不會釋放其所占用的任務槽slot，並隨時間推移會降低整個集群的性能。
二、TaskTracker失敗
正常情況下，TaskTracker 會通過心跳向 JobTracker 通信，如果發生故障，心跳減少， JobTracker 會將TaskTracker 從等待任務調度的池中移除，安排上一個成功運行的 Map 任務返回。
主要有兩種情況：
1.Map 階段的情況。如果屬於未完成的作業，Reduce 階段無法獲取本地 Map 輸出的文件結果，任務都需要重新調度和執行，只要是Map階段失敗必然是重新執行這個任務。
2.Reduce 階段的情況。自然是執行未完成的 Reduce 任務。因為 Reduce 只要執行完了就會把輸出寫到 HDFS 上。
三、JobTracker失敗
最嚴重的情況就是 JobTracker 失敗，並且這情況在單點故障時是最嚴重的，因為此情況下作業最終失敗。
解決方案是啟動多個 JobTracker ，只運行主 JobTracker ，其可以通過 ZooKeeper 來協調。
四、任務失敗重試
當 MapTask 執行失敗后會重試，超過重試次數（默認為4），整個Job會失敗。
Hadoop 提供配置參數 mapred.max.ap.failures.percent 解決這個問題。如果一個 Job 有 200 個 MapTask ，參數設置為5，則單個 Job 最多允許 10 個 MapTask 失敗（200×5%=10），其可以在配置文件 mapred-site.xml 里修改。