Hadoop學習之路(8)Yarn資源調度系統詳解

 

文章目錄

• 一、Yarn介紹
• 二、Yarn架構
• 2.1 、ResourceManager
• 2.2 、ApplicationMaster
• 2.3 、NodeManager
• 2.4 、Container
• 2.5 、Resource Request 及 Container
• 2.6 、JobHistoryServer
• 2.七、Timeline Server
• 三、yarn應用運行原理
• 3.一、yarn應用提交過程
• 3.二、mapreduce on yarn
• 四、 yarn使用
• 4.1 、配置文件
• 4.二、 yarn啓動中止
• 4.三、 yarn經常使用命令
• 五、Yarn調度器
• 5.一、 FIFO Scheduler
• 5.二、 Capacity Scheduler
• 5.三、 Fair Scheduler

 

一、Yarn介紹

   Apache Hadoop YARN 是 apache Software Foundation Hadoop的子項目，爲分離Hadoop2.0資源管理和計算組件而引入。YARN的誕生緣於存儲於HDFS的數據須要更多的交互模式，不僅僅是MapReduce模式。Hadoop2.0 的YARN 架構提供了更多的處理框架，好比spark框架，再也不強迫使用MapReduce框架。
   從hadoop2.0 的架構圖能夠看出，YARN承擔着本來由MapReduce承擔的資源管理的功能，同時將這部分的功能打包使得他們能夠被新的數據處理引擎使用。這也同時簡化了MapReduce的流程，使得MapReduce專一的將數據處理作到最好。使用YARN,能夠用共同的資源管理，在Hadoop上跑不少應用程序。目前，不少機構已經開發基於YARN的應用程序。

二、Yarn架構

   YARN的架構仍是經典的主從（master/slave）結構，以下圖所示。大致上看，YARN服務由一個ResourceManager（RM）和多個NodeManager（NM）構成，ResourceManager爲主節點（master），NodeManager爲從節點（slave）

   在YARN體系結構中，全局ResourceManager做爲主守護程序運行，該仲裁程序在各類競爭應用程序之間仲裁可用的羣集資源。ResourceManager跟蹤羣集上可用的活動節點和資源的數量，並協調用戶提交的應用程序應獲取這些資源的時間和時間。ResourceManager是具備此信息的單個進程，所以它能夠以共享，安全和多租戶的方式進行分配（或者更確切地說，調度）決策（例如，根據應用程序優先級，隊列容量，ACL，數據位置等）。
   當用戶提交應用程序時，將啓動名爲ApplicationMaster的輕量級進程實例，以協調應用程序中全部任務的執行。這包括監視任務，從新啓動失敗的任務，推測性地運行慢速任務以及計算應用程序計數器的總值。這些職責先前已分配給全部工做的單個JobTracker。ApplicationMaster和屬於其應用程序的任務在NodeManagers控制的資源容器中運行。
   ApplicationMaster能夠在容器內運行任何類型的任務。例如，MapReduce ApplicationMaster請求容器啓動map或reduce任務，而Giraph ApplicationMaster請求容器運行Giraph任務。您還能夠實現運行特定任務的自定義ApplicationMaster，並以此方式建立一個閃亮的新分佈式應用程序框架，該框架能夠更改大數據世界。我鼓勵您閱讀Apache Twill，它旨在簡化編寫位於YARN之上的分佈式應用程序。
   一個能夠運行任何分佈式應用程序的集羣 ResourceManager，NodeManager和容器不關心應用程序或任務的類型。全部特定於應用程序框架的代碼都被簡單地移動到其ApplicationMaster，以便YARN能夠支持任何分佈式框架，只要有人爲它實現適當的ApplicationMaster。因爲這種通用方法，運行許多不一樣工做負載的Hadoop YARN集羣的夢想成真。想象一下：數據中心內的單個Hadoop集羣能夠運行MapReduce，Giraph，Storm，Spark，Tez / Impala，MPI等。

核心組件：

組件名	做用
ResourceManager	至關於這個Application的監護人和管理者，負責監控、管理這個Application的全部Attempt在cluster中各個節點上的具體運行，同時負責向YarnResourceManager申請資源、返還資源等；
ApplicationMaster	至關於這個Application的監護人和管理者，負責監控、管理這個Application的全部Attempt在cluster中各個節點上的具體運行，同時負責向YarnResourceManager申請資源、返還資源等；
NodeManager	是Slave上一個獨立運行的進程，負責上報節點的狀態(磁盤，內存，cpu等使用信息)；
Container	是yarn中分配資源的一個單位，包涵內存、CPU等等資源，YARN以Container爲單位分配資源；

2.1 、ResourceManager

   RM是一個全局的資源管理器，集羣只有一個，負責整個系統的資源管理和分配，包括處理客戶端請求、啓動/監控ApplicationMaster、監控 NodeManager、資源的分配與調度。它主要由兩個組件構成：調度器（Scheduler）和應用程序管理器（Applications Manager，ASM）。
   (1)調度器
   調度器根據容量、隊列等限制條件（如每一個隊列分配必定的資源，最多執行必定數量的做業等），將系統中的資源分配給各個正在運行的應用程序。須要注意的是，該調度器是一個「純調度器」，它從事任何與具體應用程序相關的工做，好比不負責監控或者跟蹤應用的執行狀態等，也不負責從新啓動因應用執行失敗或者硬件故障而產生的失敗任務，這些均交由應用程序相關的ApplicationMaster完成。
   調度器僅根據各個應用程序的資源需求進行資源分配，而資源分配單位用一個抽象概念「資源容器」（ResourceContainer，簡稱Container）表示，Container是一個動態資源分配單位，它將內存、CPU、磁盤、網絡等資源封裝在一塊兒，從而限定每一個任務使用的資源量。
   (2)應用程序管理器
應用程序管理器主要負責管理整個系統中全部應用程序，接收job的提交請求，爲應用分配第一個 Container 來運行 ApplicationMaster，包括應用程序提交、與調度器協商資源以啓動 ApplicationMaster、監控ApplicationMaster 運行狀態並在失敗時從新啓動它等。

2.2 、ApplicationMaster

   管理 YARN 內運行的一個應用程序的每一個實例。關於 job 或應用的管理都是由 ApplicationMaster 進程負責的，Yarn 容許咱們覺得本身的應用開發 ApplicationMaster。
   功能：
   (1)數據切分；
   (2)爲應用程序申請資源並進一步分配給內部任務（TASK）；
   (3)任務監控與容錯；
   負責協調來自ResourceManager的資源，並經過NodeManager監視容易的執行和資源使用狀況。Yarn 的動態性，就是來源於多個Application 的ApplicationMaster 動態地和 ResourceManager 進行溝通，不斷地申請、釋放、再申請、再釋放資源的過程。

2.3 、NodeManager

   NodeManager 整個集羣有多個，負責每一個節點上的資源和使用。
   NodeManager 是一個 slave 服務：它負責接收 ResourceManager 的資源分配請求，分配具體的 Container 給應用。同時，它還負責監控並報告 Container 使用信息給 ResourceManager。經過和ResourceManager 配合，NodeManager 負責整個 Hadoop 集羣中的資源分配工做。
   功能:本節點上的資源使用狀況和各個 Container 的運行狀態（cpu和內存等資源）
   (1)接收及處理來自 ResourceManager 的命令請求，分配 Container 給應用的某個任務；
   (2)定時地向RM彙報以確保整個集羣平穩運行，RM 經過收集每一個 NodeManager 的報告信息來追蹤整個集羣健康狀態的，而 NodeManager 負責監控自身的健康狀態；
   (3)處理來自 ApplicationMaster 的請求；
   (4)管理着所在節點每一個 Container 的生命週期；
   (5)管理每一個節點上的日誌；
   (6)執行 Yarn 上面應用的一些額外的服務，好比 MapReduce 的 shuffle 過程；
   當一個節點啓動時，它會向 ResourceManager 進行註冊並告知 ResourceManager 本身有多少資源可用。在運行期，經過 NodeManager 和 ResourceManager 協同工做，這些信息會不斷被更新並保障整個集羣發揮出最佳狀態。NodeManager 只負責管理自身的 Container，它並不知道運行在它上面應用的信息。負責管理應用信息的組件是ApplicationMaster

2.4 、Container

   Container 是 YARN 中的資源抽象，它封裝了某個節點上的多維度資源，如內存、CPU、磁盤、網絡等，當 AM 向RM 申請資源時，RM 爲 AM 返回的資源即是用 Container 表示的。YARN 會爲每一個任務分配一個 Container，且任務只能使用該 Container 中描述的資源。
   Container 和集羣節點的關係是：一個節點會運行多個 Container，但一個 Container 不會跨節點。任何一個 job或 application 必須運行在一個或多個 Container 中，在 Yarn 框架中，ResourceManager 只負責告訴ApplicationMaster 哪些 Containers 能夠用，ApplicationMaster 還須要去找 NodeManager 請求分配具體的Container。
   須要注意的是，Container 是一個動態資源劃分單位，是根據應用程序的需求動態生成的。目前爲止，YARN 僅支持 CPU 和內存兩種資源，且使用了輕量級資源隔離機制 Cgroups 進行資源隔離。

2.5 、Resource Request 及 Container

   Yarn的設計目標就是容許咱們的各類應用以共享、安全、多租戶的形式使用整個集羣。而且，爲了保證集羣資源調度和數據訪問的高效性，Yarn還必須可以感知整個集羣拓撲結構。
   爲了實現這些目標，ResourceManager的調度器Scheduler爲應用程序的資源請求定義了一些靈活的協議，經過它就能夠對運行在集羣中的各個應用作更好的調度，所以，這就誕生了Resource Request和Container。一個應用先向ApplicationMaster發送一個知足本身需求的資源請求，而後ApplicationMaster把這個資源請求以
   resource-request的形式發送給ResourceManager的Scheduler，Scheduler再在這個原始的resource-request中返回分配到的資源描述Container。每一個ResourceRequest可看作一個可序列化Java對象，包含的字段信息以下：

<!-- - resource-name：資源名稱，現階段指的是資源所在的host和rack，後期可能還會支持虛擬機或者更復雜的網絡結構 - priority：資源的優先級 - resource-requirement：資源的具體需求，現階段指內存和cpu需求的數量 - number-of-containers：知足需求的Container的集合 --> <resource-name, priority, resource-requirement, number-of-containers>

2.6 、JobHistoryServer

   做業歷史服務,記錄在yarn中調度的做業歷史運行狀況狀況 , 經過mr-jobhistory-daemon.sh start historyserver命令在集羣中的數據節點機器上不須要作任何配置,單獨使用命令啓動直接啓動便可, 啓動成功後會出現JobHistoryServer進程(使用jps命令查看，下面會有介紹) , 而且能夠從19888端口進行查看日誌詳細信息

打開以下圖界面，在下圖中點擊History，頁面會進行一次跳轉

     點擊History以後 跳轉後的頁面以下圖,是空白的，這時由於咱們沒有啓動jobhistoryserver所致使的。 在三臺機器上執行mr-jobhistory-daemon.sh start historyserver命令依次啓動jobhistoryserver。在node1節點啓動

      此時咱們在三個節點把jobhistoryserver啓動後，在此運行wordcount程序(記得啓動前把輸出目錄刪除掉)
點擊History鏈接會跳轉一個贊新的頁面，在頁面下方會看到TaskType中列舉的map和reduce，Total表示這次運行的mapreduce程序執行所須要的map和reduce的任務數據.

2.七、Timeline Server

   用來寫日誌服務數據 , 通常來寫與第三方結合的日誌服務數據(好比spark等),從官網的介紹看，它是對jobhistoryserver功能的有效補充，jobhistoryserver只能對mapreduce類型的做業信息進行記錄，除了jobhistoryserver可以進行對做業運行過程當中信息進行記錄以外還有更細粒度的信息記錄，好比任務在哪一個隊列中運行，運行任務時設置的用戶是哪一個用戶。根據官網的解釋jobhistoryserver只能記錄mapreduce應用程序的記錄，timelineserver功能更強大,但不是替代jobhistory二者是功能間的互補關係。

三、yarn應用運行原理

   YARN 是如何工做的？ YARN的基本理念是將JobTracker/TaskTracker 兩大職能分割爲如下幾個實體：
1.一個全局的資源管理ResourceManager
2. 每一個應用程序一個ApplicationMaster
3. 每一個從節點一個NodeManager
4. 每一個應用程序一個運行在NodeManager上的Container
   ResouceManager 和 NodeManager 組成了一個新的、通用的、用分佈式管理應用程序的系統。ResourceManager 對系統中的應用程序資源有終極仲裁的權限。ApplicationMaster 是一個特定於框架的實體，它的責任是同ResourceManager 談判資源 ，同時爲NodeManager(s)執行和監控組件任務。RessourceManager有一個調度器，根據不一樣的約束條件，例如隊列容量、用戶限制等，將資源進行分配給各種運行着的應用程序。調度器執行調度功能是基於應用程序的資源申請。NodeManager 負責發佈應用程序容器，監控資源的使用並向ResourceManager進行彙報。每一個ApplicationMaster都有職責從調度器那談判獲得適當的資源容器，追蹤它們的狀態，並監控他們的進程。從系統的視圖看，ApplicationMaster 做爲一個普通的容器運行着。

3.一、yarn應用提交過程

   Application在Yarn中的執行過程，整個執行過程能夠總結爲三步：
   (1)應用程序提交
   (2)啓動應用的ApplicationMaster實例
   (3)ApplicationMaster 實例管理應用程序的執行
具體過程：
   (1)客戶端程序向 ResourceManager 提交應用並請求一個 ApplicationMaster 實例；
(2)ResourceManager 找到一個能夠運行一個 Container 的 NodeManager，並在這個 Container 中啓動ApplicationMaster 實例；
   (3)ApplicationMaster 向 ResourceManager 進行註冊，註冊以後客戶端就能夠查詢 ResourceManager 得到本身 ApplicationMaster 的詳細信息，之後就能夠和本身的 ApplicationMaster 直接交互了（這個時候，客戶端主動和 ApplicationMaster 交流，應用先向 ApplicationMaster 發送一個知足本身需求的資源請求）；
   (4)在日常的操做過程當中，ApplicationMaster 根據 resource-request協議 向 ResourceManager 發送 resource-request請求；
   (5)當 Container 被成功分配後，ApplicationMaster 經過向 NodeManager 發送 container-launch-specification信息 來啓動Container，container-launch-specification信息包含了可以讓Container 和ApplicationMaster 交流所須要的資料；
   (6)應用程序的代碼以 task 形式在啓動的 Container 中運行，並把運行的進度、狀態等信息經過 application-specific協議 發送給ApplicationMaster；
   (7)在應用程序運行期間，提交應用的客戶端主動和 ApplicationMaster 交流得到應用的運行狀態、進度更新等信息，交流協議也是 application-specific協議；
   (8)一旦應用程序執行完成而且全部相關工做也已經完成，ApplicationMaster 向 ResourceManager 取消註冊而後關閉，用到全部的 Container 也歸還給系統。

3.二、mapreduce on yarn

    (1)客戶端提交hadoop jar
   (2)找到main()方法中的job.waitForCompletition生成job對象，運行job對象的runjob()方法，與ResourceManager通訊，
返回ResourceManager分配一個ID號（applicationid），需不須要輸出，若是須要輸出，判斷輸出是否存在，若是不存在問題，在看輸入，根據hdfs獲得輸入獲得分片信息,根據分片信息獲得map個數，將這些信息回傳給客戶端Job
   (3)把Job所須要的資源，例如Jar包，配置文件，split分片信息，上傳到hdfs中去
   (4)Job對象告知與ResourceManager提交應用
   (5)ResourceManager尋找合適的節點開啓container容器(本質上是一個JVM虛擬機)
   (6)在container中啓動一個applicationMaster,初始化Job，生成一個薄記對象(就是一個記事本)，記錄map、reduce的狀態。把job全部資源上傳到hdfs中，包括jar包，配置文件，split信息
   (7)applicationMaster向ResourceManager申請資源，返回資源信息(包括node節點地址，cpu信息，內存佔比，IO信息)
   (8)applicationMaster收到信息以後，和NodeManager通訊，傳遞資源信息
   (9)開啓YarnChild進程,從hdfs中得到Job詳細信息(包括Jar包,配置文件信息)

   (一)Job初始化：一、當resourceManager收到了submitApplication()方法的調用通知後，scheduler開始分配container,隨之ResouceManager發送applicationMaster進程，告知每一個nodeManager管理器。 二、由applicationMaster決定如何運行tasks,若是job數據量比較小，applicationMaster便選擇將tasks運行在一個JVM中。那麼如何判別這個job是大是小呢？當一個job的mappers數量小於10個，只有一個reducer或者讀取的文件大小要小於一個HDFS block時，（可經過修改配置項mapreduce.job.ubertask.maxmaps,mapreduce.job.ubertask.maxreduces以及mapreduce.job.ubertask.maxbytes 進行調整) 三、在運行tasks以前，applicationMaster將會調用setupJob()方法，隨之建立output的輸出路徑(這就可以解釋，無論你的mapreduce一開始是否報錯，輸出路徑都會建立)。
   (二)Task 任務分配：一、接下來applicationMaster向ResourceManager請求containers用於執行map與reduce的tasks（step 8),這裏map task的優先級要高於reduce task，當全部的map tasks結束後，隨之進行sort(這裏是shuffle過程後面再說）,最後進行reduce task的開始。(這裏有一點，當map tasks執行了百分之5%的時候，將會請求reduce，具體下面再總結) 二、運行tasks的是須要消耗內存與CPU資源的，默認狀況下，map和reduce的task資源分配爲1024MB與一個核，（可修改運行的最小與最大參數配置,mapreduce.map.memory.mb,mapreduce.reduce.memory.mb,mapreduce.map.cpu.vcores,mapreduce.reduce.reduce.cpu.vcores.)
   (三)運行進度與狀態更新 一、MapReduce是一個較長運行時間的批處理過程，能夠是一小時、
幾小時甚至幾天，那麼Job的運行狀態監控就很是重要。每一個job以及每一個task都有一個包含
job（running,successfully completed,failed）的狀態，以及value的計數器，狀態信息及描述信息（描述信息通常都是在代碼中加的打印信息），那麼，這些信息是如何與客戶端進行通訊的呢？ 二、當一個task開始執行，它將會保持運行記錄，記錄task完成的比例，對於map的任務，將會記錄其運行的百分比，對於reduce來講可能複雜點，但系統依舊會估計reduce的完成比例。當一個map或reduce任務執行時，子進程會持續每三秒鐘與applicationMaster進行交互。

四、 yarn使用

4.1 、配置文件

<!-- $HADOOP_HOME/etc/hadoop/mapred-site.xml --> <configuration> <property> <name>mapreduce.framework.name</name> <value>yarn</value> </property> </configuration> <!-- $HADOOP_HOME/etc/hadoop/yarn-site.xml --> <configuration> <property> <name>yarn.nodemanager.aux-services</name> <value>mapreduce_shuffle</value> </property> </configuration>

4.二、 yarn啓動中止

啓動 ResourceManager 和 NodeManager （如下分別簡稱RM、NM）

#主節點運行命令 $HADOOP_HOME/sbin/start-yarn.sh #主節點運行命令 $HADOOP_HOME/sbin/stop-yarn.sh 若RM沒有啓動起來，能夠單獨啓動

若RM沒有啓動起來，能夠單獨啓動

#若RM沒有啓動，在主節點運行命令 $HADOOP_HOME/sbin/yarn-daemon.sh start resouremanager #相反，可單獨關閉 $HADOOP_HOME/sbin/yarn-daemon.sh stop resouremanager

若NM沒有啓動起來，能夠單獨啓動

#若NM沒有啓動，在相應節點運行命令 $HADOOP_HOME/sbin/yarn-daemon.sh start nodemanager #相反，可單獨關閉 $HADOOP_HOME/sbin/yarn-daemon.sh stop nodemanager

4.三、 yarn經常使用命令

#1.查看正在運行的任務 yarn application -list #2.殺掉正在運行任務 yarn application -kill 任務id #3.查看節點列表 yarn node -list #4.查看節點情況 TODO yarn node -status node3:40652 #5.查看yarn依賴jar的環境變量 yarn classpath

五、Yarn調度器

   在Yarn中有三種調度器能夠選擇：FIFO Scheduler ，Capacity Scheduler，FairS cheduler

5.一、 FIFO Scheduler

   FIFO Scheduler把應用按提交的順序排成一個隊列，這是一個先進先出隊列，在進行資源分配的時候，先給隊列中最頭上的應用進行分配資源，待最頭上的應用需求知足後再給下一個分配，以此類推。FIFO Scheduler是最簡單也是最容易理解的調度器，也不須要任何配置，但它並不適用於共享集羣。大的應用可能會佔用全部集羣資源，這就致使其它應用被阻塞。在共享集羣中，更適合採用Capacity Scheduler或FairScheduler，這兩個調度器都容許大任務和小任務在提交的同時得到必定的系統資源。下面「Yarn調度器對比圖」展現了這幾個調度器的區別，從圖中能夠看出，在FIFO 調度器中

5.二、 Capacity Scheduler

而對於Capacity調度器，有一個專門的隊列用來運行小任務，可是爲小任務專門設置一個隊列會預先佔用必定的集
羣資源，這就致使大任務的執行時間會落後於使用FIFO調度器時的時間。
如何配置容量調度器
隊列層級結構以下：
root
├── prod
└── dev
     ├── spark
     └── hdp
HADOOP_HOME/etc/hadoop/中創建一個新的capacity-scheduler.xml；內容以下：

<?xml version="1.0" encoding="utf-8"?> <configuration> <property> <name>yarn.scheduler.capacity.root.queues</name> <value>prod,dev</value> </property> <property> <name>yarn.scheduler.capacity.root.dev.queues</name> <value>hdp,spark</value> </property> <property> <name>yarn.scheduler.capacity.root.prod.capacity</name> <value>40</value> </property> <property> <name>yarn.scheduler.capacity.root.dev.capacity</name> <value>60</value> </property> <property> <name>yarn.scheduler.capacity.root.dev.maximum-capacity</name> <value>75</value> </property> <property> <name>yarn.scheduler.capacity.root.dev.hdp.capacity</name> <value>50</value> </property> <property> <name>yarn.scheduler.capacity.root.dev.spark.capacity</name> <value>50</value> </property> </configuration>

將應用放置在哪一個隊列中，取決於應用自己。
例如MR，能夠經過設置屬性mapreduce.job.queuename指定相應隊列。以WordCount爲例，以下，若是指定的隊列不存在，則發生錯誤。若是不指定，默認使用"default"隊列，以下圖

5.三、 Fair Scheduler

   在Fair調度器中，咱們不須要預先佔用必定的系統資源，Fair調度器會爲全部運行的job動態的調整系統資源。當第一個大job提交時，只有這一個job在運行，此時它得到了全部集羣資源；當第二個小任務提交後，Fair調度器會分配一半資源給這個小任務，讓這兩個任務公平的共享集羣資源。須要注意的是，在下圖Fair調度器中，從第二個任務提交到得到資源會有必定的延遲，由於它須要等待第一個任務釋放佔用的Container。小任務執行完成以後也會釋放本身佔用的資源，大任務又得到了所有的系統資源。最終的效果就是Fair調度器即獲得了高的資源利用率又能保證小任務及時完成.