YARN原理
一、YARN是什么
- 概述：yarn是一個資源調度平台，負責為運算的程序提供運算所需的資源，相當於一個分布式的操作系統，而MapReduce就相當於運行在操作系統上的一個應用程序。
- 來由：yarn是hadoop2.0加入的一個框架，用來取代hadoop1.0中的 JobTracker。
二、為什么要YARN
2.1 第一代Hadoop如何運行
- 組成：眾所周知，yarn是hadoop2.0版本加入的。而hadoop1.0版本由分布式文件系統HDFS，分布式計算框架MapReduce組成。HDFS由一個NameNode和多個DataNode組成；MapReduce由一個JobTracker和多個TaskTracker組成。
- 運行：當client提交作業后，JobTracker會將作業加入隊列並調度，默認調度規則是FIFO；TaskTracker會主動向JobTracker詢問是否有任務可做(心跳機制)，這個任務可以是map任務也可以是reduce任務；申請到任務后，TaskTracker會拷貝代碼和任務信息到本地，並啟動JVM運行；任務運行的過程中。首先將自己的狀態匯報給TaskTracker，然后由TaskTracker告知JobTracker；JobTracker在接收最后一個任務完成后才算完成，並清理臨時數據。
2.2 JobTracker的缺點
- 單點故障：與HDFS中的NameNode類似，JobTracker是集群事務的集中處理點，存在單點故障；
- 任務集中：JobTracker既要負責資源管理，又要負責作業調度，以及job和task的狀態；
- 資源調度不周全(OOM)：在TaskTracker端，用map/reduce task作為資源的表示過於簡單，沒有考慮CPU、內存等資源的情況；如果把兩個需要消耗大內存的task調度到一起，就很容易出現OOM；
- 資源利用不足(slot)：每個job申請資源以slot為單位。並且map task使用map slot，reduce task使用reduce slot，容易造成資源利用不足。
三、YARN的組成
3.1 ResourceManager
-
由來：yarn將 JobTracker的資源管理和作業控制功能分開，分別由ResourceManager和ApplicationMaster來實現。
-
組成：
-
調度器 Scheduler：負責給application分配資源，只是根據資源的使用情況進行調度；周期性的接收來自nodemanager的資源使用率的監控信息；調度方式有FIFO、Capacity Scheduler、 Fair Scheduler等，也可以自定義。
-
應用程序管理器 ApplicationsManager(AsM)：負責處理client提交的job，以及協商第一個container，以供ApplicationMaster(AM)運行；管理系統中所有AM的生命周期，並在AM失敗后重啟AM。
-
-
作用：ResourceManager（RM）負責全局所有應用程序的資源分配。RM會跟蹤集群中有多少活動的節點和資源，協調用戶提交的那些應用程序(Job)應該在何時獲取這些資源。RM是唯一擁有這些信息的進程。
-
高可用：RM與NameNode一樣，也存在單點故障問題，但是目前還沒有很好的實現，不過CDH4.4之后實現了一個簡單的高可用，與NameNode的HA類似。
3.2 ApplicationMaster
-
作用：ApplicationMaster（AM）僅負責一個應用程序 (Job)內的所有任務的執行，包括監視任務、重啟失敗的任務等。AM可以在容器內運行任何類型的任務。例如MapReduce ApplicationMaster請求一容器來啟動map和reduce任務，而Giraph AM請求一個容器來運行Giraph任務。也可以自定義。
-
中間人：AM負責向ResourceManager索要NodeManager執行任務所需的資源容器，起到中間人的作用；以及跟蹤這些資源的使用情況，和任務進度的監控。
3.3 NodeManager
- 來由：NodeManager是TaskTracker的一種更加普通和高效的版本。沒有固定數量的map/reduce slot，而是擁有許多動態創建的資源容器(Container)。
- 作用：NodeManager（NM）是客戶端框架。負責Container，監控它們的資源使用並上報給RM；只會監視資源，不會監視任務；
- 資源本地化：在啟動container時，NM會設置一些必要的環境變量，以及將container運行所需的jar包、文件等從HDFS下載到本地。
3.3.1 Container
- 作用：Container是yarn中對系統資源的抽象，同時它也是系統分配資源的基本單位；與MRv1中slot不同的是，container是一個動態的資源划分單位，其里邊描述的CPU、內存等資源是根據實際應用程序的需求而變的，而slot是一個靜態的資源抽象單位；Container是AM、Map/Reduce Task的運行容器。
四、YARN的運行過程
4.1 YARN可以運行的分布式應用程序：
- YARN的可擴展性：ResourceManager、NodeManager和Container都不關心應用程序的類型，所有特定於應用程序框架的代碼都會轉移到ApplicationMaster，以便任何分布式框架都可以受yarn支持。
- 可運行的應用程序：得益於YARN的可擴展性，Hadoop YARN集群可以運行許多不同類型的分布式分布式計算模型，例如：MapReduce、Giraph、Storm、Spark等。
4.2 運行過程（以MapReduce為例）
- 首先由driver向resourcemanager提交請求運行一個job的命令：job.waitForCompletion()；
- RM同意后，返回給client一個jobid和存儲切片、jar文件的位置；
- client根據返回的信息將切片和jar文件上傳到hdfs的指定位置中，都是臨時文件；
- drive申請一個容器，運行AM進程。RM同意后，生成容器任務，放進資源隊列；
- 當任務開始執行時，創建任務容器，MRAppMaster加載任務信息；
- driver發送啟動命令，運行程序，MRAppMaster接收命令，加載配置信息；
- 並向RM申請container運行mapTask；
- mapTask領到資源后，根據MRAppMaster加載的任務信息，下載jar包和切片，配置文件等；
- 運行mapTask；
- 當MapTask運行結束后，MRAppMaster向RM申請新的容器，運行reduceTask；
- reduceTask開始運行；
- 當所有的任務執行完畢后，MRAppMaster向RM注銷本次job，並退出程序。
4.3 流程圖
- 步驟1：用戶向Yarn提交應用程序，其中包括用戶程序、相關文件、啟動ApplicationMaster命令、ApplicationMaster程序等。
- 步驟2：ResourceManager為該應用程序分配第一個Container，並且與Container所在的NodeManager通信，並且要求該NodeManager在這個Container中啟動應用程序對應的ApplicationMaster。
- 步驟3：ApplicationMaster首先會向ResourceManager注冊，這樣用戶才可以直接通過ResourceManager查看到應用程序的運行狀態，然后它為准備為該應用程序的各個任務申請資源，並監控它們的運行狀態直到運行結束，即重復后面4~7步驟。
- 步驟4：ApplicationMaster采用輪詢的方式通過RPC協議向ResourceManager申請和領取資源。
- 步驟5：一旦ApplicationMaster申請到資源后，便會與申請到的Container所對應的NodeManager進行通信，並且要求它在該Container中啟動任務。
- 步驟6：任務啟動。NodeManager為要啟動的任務配置好運行環境，包括環境變量、JAR包、二進制程序等，並且將啟動命令寫在一個腳本里，通過該腳本運行任務。
- 步驟7：各個任務通過RPC協議向其對應的ApplicationMaster匯報自己的運行狀態和進度，以讓ApplicationMaster隨時掌握各個任務的運行狀態，從而可以再任務運行失敗時重啟任務。
- 步驟8：應用程序運行完畢后，其對應的ApplicationMaster會向ResourceManager通信，要求注銷和關閉自己。