1.yarn的架構與設計

YARN的總體架構模式是Master/Slave主從模式。一個全局的ResourceManager ( RM，主 ，可以多個HA),多個NodeManager共同構成計算框架。 NodeManager (NM)是每台機器的框架代理，管理單個節點的資源和任務，比如負責容器container、監控其資源使用情況（cpu、內存、磁碟、網絡）等。既然YARN是為了給計算框架做資源調度分配與管理的，那麼少不了應用程式管理相關的框架：ApplicationMaster (AM) 實際上是一個特定框架的庫，其作用是負責管理整個系統中所有的應用程式（從任務提交到結束），協商來自 ResourceManager 的資源，同時與 NodeManager 一起執行和監視任務。

從上面這張Hadoop官網的照片我們可以清晰的看出,YARN主要有以下三個組件構成.ResourceManager，NodeManager,ApplicationMaster構成。

2.透視YARN三大組件全貌

YARN 可以看出一個大的雲作業系統，它負責為應用程式啟動 ApplicationMaster（相當於主線程），然後再由 ApplicationMaster 負責數據切分、任務分配、啟動和監控等工作，而由 ApplicationMaster 啟動的各個 Task（相當於子線程）僅負責自己的計算任務。當所有任務計算完成後，ApplicationMaster 認為應用程式運行完成，然後退出。

2.1.ResourceManager全局資源管理器

RM負責整個系統的資源分配與管理；它主要有調度器ResourceScheduler和應用程式管理器（APPlications Manager）構成；

2.1.1ResourceScheduler

Resource Scheduler調度器只負責資源的細分調度，比如按照隊列，容量等指標，給每個請求的應用程式分配的指定數量的資源。 hadoop 提供了三種不同的資源調度器供選用,用戶可以在配置文件中加以選擇。這三種調度器是FIFO Scheduler, FAIR Scheduler,CAPACITY Scheduler,詳細使用可以參考官網或我的其他博客。yarn配置文件 yarn-sire.xml 中<yarn. resourcemanager. scheduler. class >來指定調度器，apache Hadoop集群默認的調度器是 CapacityScheduler ，而CDH默認的則是FAIR Scheduler.

 <property>
        <name>yarn.resourcemanager.scheduler.class</name>
        <value>org.Apache.hadoop.yarn.Server.resourcemanager.scheduler.capacity.CapacityScheduler</value>
    </property>

2.1.2APPlications Manager

APPlications Manager 應用程式管理器負責整個系統中所有應用程式的管理，包括管理啟動的所有ApplicationMaster (AM)實例，比如啟動AM,和AM通信並監控所有AM實例的運行狀態，某個AM失敗時，在失敗次數範圍內時對其進行重啟等（默認一個應用的AM可以啟動2次）。區別APPlications Manager和APPlications Master，兩者不同，前者管理後者的實例。

2.2 NodeManger，節點資源管理器

NM是單個節點的資源管理器，管理者單個節點的資源分配與任務。所以如果hadoop集群特殊情況時想做存儲與計算分離，則某些節點可以只啟動Datanode，或只啟動Nodemanger即可，這樣可以只做存儲節點或者計算節點，當然也可以通過參數限制存儲的使用和計算的使用比例。所以NM是YARN的實際計算節點。

NM和RM保持心跳機制，定時匯報自己節點的資源使用情況和Container的運行狀態
Container,全稱是Resouce Container是YARN中的資源抽象（主要包含了CPU,內存，網絡等），應用程式向RM請求資源的個體就是Container，由NodeManager分配。YARN會為每個任務分配一個container，且任務能使用的資源值就是container中分配的資源（新Capacity調度支持container資源的動態擴容）
NM接受來自AM的Container分配，啟動與停止
YARN使用了輕量級資源隔離機制CGroups，CGroups 是 Linux 內核功能。從 YARN 的角度來看，這允許限制容器的資源使用。沒有 CGroups，就很難限制容器 CPU 使用率。
NM只負責AM管理的應用程式的部分工作，不管整個程序的失敗與否，只負責執行Container。
編輯

尖叫總結：RM內部有個 ResourceTrackerService 類的對象 resourceTracker ,它跟蹤管理著 NodeManager 節點所知道的資源變動。同時 NodesListManager 類的對象nodesListManager 則維持著一個節點清單,記錄著哪些節點當前是可用的,哪些則是不可用的。而 ResourceTrackerService 和 NodesListManager 掌握的則是來自所有 NodeManager 節點的心跳報告,通過心跳進行交互的信息如節點當前狀態，資源使用情況等。這些信息最終都要匯集到ResourceScheduler,通過調度器將資源分配出去給用戶使用。

2.3Application Master應用程式主管理器

客戶端每使用YARN啟動執行一個應用程式之前，先啟動一個AM（其實本質就是一個運行的Container，一個程序最早啟動的container實例）

每個提交到YARN的任務都會啟動一個唯一的AM實例，如果AM失敗了，默認可以重試啟動一次。
AM與RM通信提交需要的資源，AM與RM調度器Scheduler通信協商以獲取資源Container，得到Container後分配給自己的任務執行執行。比如map任務的執行。分配的多少個Container就有多少個map並行執行。
AM從RM得到的資源只是資源列表，hosts，container數量，資源大小等，這時候AM需要與NM通信，啟動任務，啟動container。
AM監管者該任務所有任務實例的運行狀態，比如一個MapReduce任務，該任務AM監管所有的MapTask，ReduceTask的運行狀態。如果AM監管到任務失敗了後，可以進行重新申請資源重啟。包括可以主動殺死任務，停止任務等。

尖叫總結：從上面可以看出，YARN三大組件的RM,NM都只與資源分配有關，只有AM跟應用程式有關。所以如果想將一個新的計算框架（比如自定義的）/應用程式使用YARN進行資源調度和任務管理，只需要從重新實現兩個組件即可，前者是提交任務使用的客戶端Client，後者就是Application Master。比如MapReduce計算引擎能直接配置使用YARN進行調度，就是YARN默認給他實現了可以提交任務通信的客戶端JobClient和任務管理器MapReduce Application Master(簡稱MRAppMaster)。

3.YARN組件之間的通信RPC/IPC

開發人員經常會在任務中看到RPC通信異常，也有IPC通信異常，報錯等？或者查到監控指標RPC請求延遲等？大家應該都不陌生，那麼這些報錯意味著什麼呢？如何解決呢？

3.1RPC通信與IPC通信

RPC通信是指遠程過程調用（Remote Procedure Call）通信協議，主要用來讓遠程的兩台伺服器之間A主機的程序可以調用B主機的子程序，是一種遠程分布式網絡調用通信協議，我們不用太關注底層網絡通信細節（不用關注TCP,UDP等），是一種封裝好了的通信協議，直接拿來用即可，真香。

IPC通信是指進程間通信（Inter-Process Communication ,IPC）協議，這個是分布式系統通信的基石。

儘管Java自帶了一套RPC通信組件（RMI，remote method Invocation），但是Hadoop並沒有使用該框架，因為相比Java的RMI,後者更加輕量級，高性能和可控性。Hadoop的RPC框架也是C/S模式，分成了四個模塊，分別是序列化層，函數調用層，網絡傳輸層以及server端處理層。當前開源的RPC框架很多，比如Apache的AVRO,Google的Protocol Buffer等。

YARN的RPC通信為了更好的兼容默認使用Google的Protocol Buffer作為默認的序列化機制，而不是Hadoop自帶的Writtable。在 YARN 中，任何兩個需相互通信的組件之間僅有一個 RPC 協議，而對於任何一個 RPC 協議，通信雙方有一端是 Client，另一端為 Server，且 Client 總是主動連接 Server 的，因此，YARN 實際上採用的是拉式（pull-based）通信模型。

比如NM和RM之前的遠程通信就是基於RPC,通過ResouceTracker實現，其中RM是服務端，NM是客戶端。NM主要通過調用ResouceTracker中兩個RPC函數與之交互，前者是NM剛啟動時通過registerNodeManager函數向RM進行註冊，然後再通過nodeHeartBeat像RM發送周期性心跳，維護兩者之間的交互。如下圖所示，因為RPC分成了四層次序列化層，函數調用層，網絡傳輸層以及server端處理層，所有不同組件之間實現通信的「協議」是不同的。

1.JobClient（作業提交客戶端）與 RM 之間JobClient 通過該 RPC 協議提交應用程式、查詢應用程式狀態，使用的協議是ApplicationClientProtocol 。
2.AM 與 RM 之間的協議是ApplicationMasterProtocol ，AM 通過該 RPC 協議向 RM 註冊並為各個任務申請資源，或者使用完以後進行銷毀自己。
3. AM 與 NM 之間的協議是ContainerManagementProtocol ，AM 通過該 RPC 協議要求 NM 啟動/停止 Container，同時獲取各個 Container 的狀態信息等。
4.NM 與 RM 之間的協議是ResourceTracker ，NM 通過該 RPC 協議向 RM 註冊，並且周期性發送心跳信息匯報當前節點的資源使用情況和 Container 運行情況。
5.Admin與 RM 之間的通信協議是ResourceManagerAdministrationProtocol，超級用戶通過該 RPC 協議更新系統配置文件，比如節點上下線名單、用戶隊列權限等。

尖叫總結：RM,NM,AM三大組件互相通信，通過不同RPC框架協議進行通信，進而保持整個YARN資源的調度和任務監控實施。

深入YARN系列1：窺全貌之YARN架構，設計，通信原理等