Mapreduce 1.0 舊的MapReduce架構(gòu)

舊的MapReduce架構(gòu)
、

MapReduce架構(gòu)

基本概念

• JobTracker: 負(fù)責(zé)資源管理，跟蹤資源消耗和可用性，作業(yè)生命周期管理（調(diào)度作業(yè)任務(wù)，跟蹤進(jìn)度，為任務(wù)提供容錯）
• TaskTracker: 加載或關(guān)閉任務(wù)，定時報告認(rèn)為狀態(tài)

舊的架構(gòu)的問題

1. JobTracker是MapReduce的集中處理點，存在單點故障
2. JobTracker完成了太多的任務(wù)，造成了過多的資源消耗，當(dāng)MapReduce job 非常多的時候，會造成很大的內(nèi)存開銷。這也是業(yè)界普遍總結(jié)出老Hadoop的MapReduce只能支持4000 節(jié)點主機的上限
3. 在TaskTracker端，以map/reduce task的數(shù)目作為資源的表示過于簡單，沒有考慮到cpu/ 內(nèi)存的占用情況，如果兩個大內(nèi)存消耗的task被調(diào)度到了一塊，很容易出現(xiàn)OOM
4. 在TaskTracker端，把資源強制劃分為map task slot和reduce task slot, 如果當(dāng)系統(tǒng)中只有map task或者只有reduce task的時候，會造成資源的浪費，也就集群資源利用的問題

Hadoop2.0 YARN 架構(gòu)

在這里插入圖片描述

在這里插入圖片描述

在Hadoop2.0中, YARN負(fù)責(zé)管理MapReduce中的資源(內(nèi)存, CPU等)并且將其打包成Container. 這樣可以精簡MapReduce, 使之專注于其擅長的數(shù)據(jù)處理任務(wù), 將無需考慮資源調(diào)度. YARN會管理集群中所有機器的可用計算資源. 基于這些資源YARN會調(diào)度應(yīng)用(比如MapReduce)發(fā)來的資源請求, 然后YARN會通過分配Container來給每個應(yīng)用提供處理能力

基本概念

ResourceManager

• 負(fù)責(zé)整個集群的資源管理和分配，是一個全局的資源管理系統(tǒng)。
• NodeManager 以心跳的方式向 ResourceManager 匯報資源使用情況（目前主要是 CPU 和
  內(nèi)存的使用情況）。RM 只接受 NM 的資源回報信息，對于具體的資源處理則交給 NM 自己
  處理。
• YARN Scheduler 根據(jù) application 的請求為其分配資源，不負(fù)責(zé) application job 的
  監(jiān)控、追蹤、運行狀態(tài)反饋、啟動等工作。

NodeManager

• NodeManager 是每個節(jié)點上的資源和任務(wù)管理器，它是管理這臺機器的代理，負(fù)責(zé)該節(jié)
  點程序的運行，以及該節(jié)點資源的管理和監(jiān)控。YARN 集群每個節(jié)點都運行一個
  NodeManager。
• NodeManager 定時向 ResourceManager 匯報本節(jié)點資源（CPU、內(nèi)存）的使用情況和
  Container 的運行狀態(tài)。當(dāng) ResourceManager 宕機時 NodeManager 自動連接 RM 備用節(jié)
  點。
• NodeManager 接收并處理來自 ApplicationMaster 的 Container 啟動、停止等各種請
  求。

ApplicationMaster

• 用戶提交的每個應(yīng)用程序均包含一個ApplicationMaster，他可以運行在ResourceManager意外的任何機器上ResourceManager 以外的機器上。
• 負(fù)責(zé)與RM調(diào)度器協(xié)商獲取資源（container）
• 將得到的任務(wù)進(jìn)一步分配給內(nèi)部的任務(wù)(資源的二次分配)
• 與NM通信以啟動/停止任務(wù)
• 監(jiān)控所有任務(wù)運行狀態(tài)，并在任務(wù)運行失敗時重新為任務(wù)申請資源以重啟任務(wù)

Container

在Hadoop集群中，平衡內(nèi)存（RAM）、處理器（CPU核心）和磁盤的使用是至關(guān)重要的，合理規(guī)劃以免某一項引起瓶頸制約。一般的建議是，一塊磁盤和一個CPU核心上配置兩個Container會達(dá)到集群利用率的最佳平衡,Container是YARN中處理能力的基本單元, 是對內(nèi)存, CPU等的封裝
從可用的硬件資源角度看，要調(diào)整群集每個節(jié)點Yarn和MapReduce的內(nèi)存配置到合適的數(shù)據(jù)，應(yīng)注意以下幾個重要的元素：

• RAM (總內(nèi)存大小)
• CORES (CPU核心數(shù))
• DISKS (磁盤數(shù))
  Yarn和MapReduce的總的可用內(nèi)存應(yīng)考慮到保留的內(nèi)存。保留的內(nèi)存是由系統(tǒng)進(jìn)程和其他Hadoop進(jìn)程（如Hbase）所需要的內(nèi)存。

保留內(nèi)存=保留系統(tǒng)內(nèi)存+保留HBase內(nèi)存（如果HBase是在同一個節(jié)點）
下面的計算是確定每個節(jié)點的Container允許的最大數(shù)量。
Container數(shù)量=min (2CORES, 1.8DISKS, (可用內(nèi)存)/最低Container的大小)
最低Container的大小 這個值是依賴于可用的RAM數(shù)量——在較小的存儲節(jié)點，最小的Container的大小也應(yīng)較小。下面的表列出了推薦值：

最后計算的每個Container的內(nèi)存大小是

每個Container的內(nèi)存大小 = max(最小Container內(nèi)存大小, (總可用內(nèi)存) /Container數(shù)))

新舊架構(gòu)對比

YARN 的核心就是將jobTracker的功能進(jìn)行拆解，分成了資源管理和任務(wù)調(diào)度監(jiān)控兩個進(jìn)程，一個全局的資源管理和每個作業(yè)的管理。ResourceManager和Nodemanager提供了計算資源的分配和管理，ApplicationMaster負(fù)責(zé)完成程序的運行.YARN架構(gòu)下形成了一個通用的資源管理平臺和一個通用的應(yīng)用計算平，避免了舊架構(gòu)的單點問題和資源利用率問題，同時也讓在其上運行的應(yīng)用不再局限于MapReduce形式

Yarn基本流程

在這里插入圖片描述

1. 用戶向YARN中提交應(yīng)用程序，其中包括ApplicationMaster程序、啟動ApplicationMaster的命令、用戶程序等
2. ResourceManager為該應(yīng)用程序分配第一個Container，并與對應(yīng)的Node-Manager通信，要求它在這個Container中啟動應(yīng)用程序的ApplicationMaster
3. ApplicationMaster首先向ResourceManager注冊，這樣用戶可以直接通過ResourceManage查看應(yīng)用程序的運行狀態(tài)，然后它將為各個任務(wù)申請資源，并監(jiān)控它的運行狀態(tài)，直到運行結(jié)束，即重復(fù)步驟4~7
4. ApplicationMaster采用輪詢的方式通過RPC協(xié)議向ResourceManager申請和領(lǐng)取資源
5. 一旦ApplicationMaster申請到資源后，便與對應(yīng)的NodeManager通信，要求它啟動任務(wù)
6. NodeManager為任務(wù)設(shè)置好運行環(huán)境(包括環(huán)境變量、JAR包、二進(jìn)制程序等)后，將任務(wù)啟動命令寫到一個腳本中，并通過運行該腳本啟動任務(wù)
7. 各個任務(wù)通過某個RPC協(xié)議向ApplicationMaster匯報自己的狀態(tài)和進(jìn)度，以讓ApplicationMaster隨時掌握各個任務(wù)的運行狀態(tài)，從而可以在任務(wù)失敗時重新啟動任務(wù)。在應(yīng)用程序運行過程中，用戶可隨時通過RPC向ApplicationMaster查詢應(yīng)用程序的當(dāng)前運行狀態(tài)
8. 應(yīng)用程序運行完成后，ApplicationMaster向ResourceManager注銷并關(guān)閉自己

Yarn調(diào)度器Scheduler

理想情況下，我們應(yīng)用對 Yarn 資源的請求應(yīng)該立刻得到滿足，但現(xiàn)實情況資源往往是
有限的，特別是在一個很繁忙的集群，一個應(yīng)用資源的請求經(jīng)常需要等待一段時間才能的到
相應(yīng)的資源。在Yarn中，負(fù)責(zé)給應(yīng)用分配資源的就是Scheduler。其實調(diào)度本身就是一個
難題，很難找到一個完美的策略可以解決所有的應(yīng)用場景。為此Yarn提供了多種調(diào)度器
和可配置的策略供我們選擇。在 Yarn 中有三種調(diào)度器可以選擇：FIFO Scheduler ，Capacity Scheduler，F(xiàn)air Scheduler。

三種調(diào)度器基本原理

在這里插入圖片描述

• FIFO Scheduler: 把應(yīng)用按提交的順序排成一個隊列，這是一個先進(jìn)先出隊列，在進(jìn)行資源分配的時候，先給隊列中最頭上的應(yīng)用進(jìn)行分配資源，待最頭上的應(yīng)用需求滿足后再給下一個分配，以此類推
• Capacity 調(diào)度器允許多個組織共享整個集群，每個組織可以獲得集群的一部分計算能力。通過為每個組織分配專門的隊列，然后再為每個隊列分配一定的集群資源，這樣整個集群就可以通過設(shè)置多個隊列的方式給多個組織提供服務(wù)了。除此之外，隊列內(nèi)部又可以垂直劃分，這樣一個組織內(nèi)部的多個成員就可以共享這個隊列資源了，在一個隊列內(nèi)部，資源的調(diào)度是采用的是先進(jìn)先出(FIFO)策略。
• Fair 針對不同的應(yīng)用（也可以為用戶或用戶組），每個應(yīng)用屬于一個隊列，主旨是讓每個應(yīng)用分配的資源大體相當(dāng)。（當(dāng)然可以設(shè)置權(quán)重），若是只有一個應(yīng)用，那集群所有資源都是他的。和 Capacity的區(qū)別是不需要預(yù)留資源 。適用情況：共享大集群、隊列之間有較大差別。

配置文件位置

• capacity調(diào)度器的啟用：
  在ResourceManager節(jié)點上的yarn-site.xml設(shè)置
  Property===>yarn.resourcemanager.scheduler.class
  Value=====>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler

• capacity調(diào)度器的配置:
  在目錄$HADOOP_HOME/hadoop/etc/hadoop/capacity-scheduler.xml

YARN-FailOver

任務(wù)失敗

1. 運行時異?；蛘逬VM退出都會報告給AM
2. 通過心跳檢查任務(wù)的timeout，會檢查多次（可配置）才判斷該任務(wù)是否有效
3. 失敗的任務(wù)或者作業(yè)都有AM重新運行

ApplicationMaster失敗

1. AM 定時發(fā)送心跳信號到RM，通常一旦AM失敗，就認(rèn)為失敗，但是也可以通過配置多次失敗才算失敗
2. AM失敗后，RM會啟動一個新的ApplicationMaster
3. 新的AM負(fù)責(zé)回復(fù)之前錯誤的AM的狀態(tài)，(yarn.app.mapreduce.am.job.recovery.enable=true)，這一步是通過將應(yīng)用運行狀態(tài)保存到共享的存儲上來實現(xiàn)的，ResourceManager不會負(fù)責(zé)任務(wù)狀態(tài)的保存和恢復(fù)
4. Client也會定時向ApplicationMaster查詢進(jìn)度和狀態(tài)，一旦發(fā)現(xiàn)其失敗，則向ResouceManager詢問新的ApplicationMaster

NodeManager失敗

1. NodeManager定時發(fā)送心跳到ResourceManager，如果超過一段時間沒有收到心跳消息，ResourceManager就會將其移除
2. 任何運行在該NodeManager上的任務(wù)和ApplicationMaster都會在其他NodeManager上進(jìn)行恢復(fù)
3. 如果某個NodeManager失敗的次數(shù)太多，ApplicationMaster會將其加入黑名單，任務(wù)調(diào)度時不在其上運行任務(wù)

ResourceManager失敗

1. 通過checkpoint機制，定時將其狀態(tài)保存到磁盤，然后失敗的時候，重新運行
2. 通過zookeeper同步狀態(tài)和實現(xiàn)透明的HA