在現實情況中，使用者**錯誤不斷，程序崩潰，機器故障等情況均容易造成任務失敗。hadoop最主要的好處之一就是它能處理此類故障並能夠成功完成作業。
1、任務失敗對於一些應用程式，不希望一旦有少數幾個任務失敗就終止執行整個作業，因為即使有任務失敗，作業的一些結果可能還是可用的。在這種情況下，可以為作業設定在不觸發作業失敗的情況下允許任務失敗的最大百分比。針對map任務和reduce任務的設定可以通過mapreduce.map.failures.maxpercent設定。
2、應用管理器失敗
3、節點管理器失敗
如果節點管理器由於崩潰或執行非常緩慢而失敗，就會停止向資源管理器傳送心跳資訊（或傳送頻率很低）。如果10分鐘內沒有收到一條心跳資訊，資源管理器將會通知停止傳送心跳資訊的節點管理器，並且將其從自己的節點池中移除以排程啟用容器。
4、資源管理器失敗
資源管理器失敗時非常嚴重的問題，沒有資源管理器，作業和任務容器將無法啟動。在預設的配置中，資源管理器是個單點故障，這是由於在機器失敗的情況下，所有執行的作業都失敗且不能被恢復。
為獲得高可用性（ha),在雙機熱備配置下，執行一堆資源管理器是必要的。如果主資源管理器失敗了，那麼備份資源管理器能夠接替，且客戶端不會感到明顯的中斷。
資源管理器從備機到主機的切換是由故障轉移控制器（failover controller）處理的。
預設的故障轉移控制器是自動工作的，使用zookeeper的leader選舉機制（leader election）以確保同一時刻只有乙個主資源管理器。為應對資源管理器的故障轉移，必須對客戶和節點管理器進行配置，因為他們可能是在和兩個資源管理器打交道。客戶和節點管理器以輪詢方式檢視連線每乙個資源管理器，直到找到主資源管理器。如果主資源管理器故障，他們將再次嘗試直到備份資源管理器變成主機。
Spark Spark容錯機制
一般來說，分布式資料集的容錯性有兩種方式 資料檢查點和記錄資料的更新。面向大規模資料分析，資料檢查點操作成本很高，需要通過資料中心的網路連線在機器之間複製龐大的資料集，而網路頻寬往往比記憶體頻寬低得多，同時還需要消耗更多的儲存資源。因此，spark選擇記錄更新的方式。但是，如果更新粒度太細太多，那麼...
Spark容錯機制
一般來說，分布式資料集的容錯性有兩種方式 資料檢查點和記錄資料的更新。面向大規模資料分析，資料檢查點操作成本很高，需要通過資料中心的網路連線在機器之間複製龐大的資料集，而網路頻寬往往比記憶體頻寬低得多，同時還需要消耗更多的儲存資源。因此，spark選擇記錄更新的方式。但是，如果更新粒度太細太多，那麼...
Spark容錯機制
一般來說，分布式資料集的容錯性有兩種方式 資料檢查點和記錄資料的更新。面向大規模資料分析，資料檢查點操作成本很高，需要通過資料中心的網路連線在機器之間複製龐大的資料集，而網路頻寬往往比記憶體頻寬低得多，同時還需要消耗更多的儲存資源。因此，spark選擇記錄更新的方式。但是，如果更新粒度太細太多，那麼...