Hadoop2.x的yarn

hadoop mapreduce 1.x中的問題

原理

在1.x中主要使用的是JobTracker和TaskTracker這兩個組件管理系統中的資源

step1：客戶端提交任務
step2：JobTracker從namenode獲取輸入文件的數據塊的列表信息
step3：JobTracker會根據第二步中獲取到的數據塊的列表信息將任務提交到離數據塊儘可能近的位置上運行
step4：TaskTracker跟蹤監控該節點上的任務的運行情況
step5：TaskTracker隔一段時間將運行的信息發送到JobTracker（包括task的運行狀態和本節點上的資源的使用情況），如果JobTracker在一定時間內沒有收到來自於TaskTracker的信息，那麼就認爲分配在這個上面的任務失敗了，就會將任務分配到另一個節點上去運行。一旦所有的任務都成功了，JobTracker就會更新作業狀態爲成功，如果任務反覆失敗達到一定的數量，那麼JobTracker就會宣佈任務失敗

除此以外，客戶端也會輪詢JobTracker用來獲取Job的運行情況

問題

1. 在圖中我們能發現，JobTracker過於繁重，其需要進行task的調度，還需要實施監控着各個節點上的資源信息，爲下一個任務分配好準備。這就造成了JobTracker容易出現故障
2. JobTracker存在單點故障
3. 使用這種方式只支持mapreduce只一種計算模型，不能支持比如map，reduce，reduce這種運算模型，需要改變JobTracker

hadoop mr2中引入yarn

yarn中的主要組件：

1. ResourceManager（全局只有一個）
   處理客戶端的請求
   啓動ApplicationMaster，並負責對他的監控
   管理和分配集羣上的所有的資源（這裏涉及到對nodemanager的監控）
2. ApplicationMaster（每一個應用都會有一個）
   向ResourceManager請求資源，包含的要求有對容器的要求，CPU數量和內存大小
   監控任務的執行情況
3. NodeManager
   接收ResourceManager的請求，爲作業分配Container
   向RM彙報自己節點的資源信息
   管理自己運行的Container

mr程序使用yarn的運行機制

step1：Client提交任務到ResourceManager
step2：ResourceManager接收到作業後，根據其的一些調度策略（因爲RM可能不止接收了一個作業）調度作業，在一個節點上獲取一個運行ApplicationManager實例的Container
step3：AM啓動後，向RM註冊，客戶端就可以通過RM查詢AM的詳細信息了
step4：AM對任務進行相應的分析後，向RM申請用於執行task（map或者reduce）的Container
step5：RM將分配好的信息(包括容器所在的節點和容器所持有的CPU的數量和內存的大小)告知AM，AM去尋找相應的NodeManager
step6：NodeManager分配Container
step7：每個任務向AM彙報執行進度

與mr1.x的比較

1. JobTracker的任務被分成了兩個部分，分別由ResourceManager進行資源的分配和ApplicationMaster管理監控task的運行
2. yarn支持多種計算模型，只要實現相應的ApplicationMaster即可

yarn的容錯機制

1. ResourceManager
   使用Zookeeper的實現HA
2. NodeManager
   失敗後，RM將失敗任務告訴對應的AM；
   AM決定如何處理失敗的任務。
3. ApplicationMaster
   失敗後，由RM負責重啓；
   AM需處理內部任務的容錯問題；
   RMAppMaster會保存已經運行完成的Task，重啓後無需重新運行。