YARN的基本介紹

YARN的介紹

Apache Hadoop YARN （Yet Another Resource Negotiator，另一種資源協(xié)調(diào)者）是一種新的 Hadoop 資源管理器，它是一個通用資源管理系統(tǒng)，可為上層應用提供統(tǒng)一的資源管理和調(diào)度，它的引入為集群在利用率、資源統(tǒng)一管理和數(shù)據(jù)共享等方面帶來了巨大好處。

YARN是再MRv1發(fā)展過來的，他克服了NRv1的各種限制，因此我們先了解一下MRv1

MRv1

JobTracker：用戶程序提交了一個Job，任務（job）會發(fā)給JobTracker，JobTracker是Map-Reduce框架中心，她負責把任務分解成map和reduce的作業(yè)（task）；需要與集群中的機器定時心跳(heartbeat)通信；需要管理那些程序應該跑在那些機器上；需要管理所有job失敗、重啟操作。

Tasktracker是JobTracker和Task之間的橋梁，Tasktracker可以配置map和reduce的作業(yè)操(task slot)。TaskTracker通過心跳告知JobTracker自己還有空閑的作業(yè)Slot時，JobTrackr會向其分派任務。它將接收并執(zhí)行JobTracker的各種命令:啟動任務、提交任務、殺死任務。

TaskScheduler工作再JobTracker上。根據(jù)JobTracker獲得的slot信息完成具體的分配工作，TaskScheduler支持多種策略以提高集群工作效率。

擴展局限性：JobTracker同時要兼顧資源管理和作業(yè)控制的兩個功能，成為系統(tǒng)的一個瓶頸，制約Hadoop集群計算能力的拓展。（4000節(jié)點任務數(shù)400000）

MRv1采用master/slave結(jié)構(gòu)，其中JobTracker作為計算管理的master存在單點問題，它容易出現(xiàn)故障整個MRv1不可用。

資源利用率局限。MRv1采用了基于作業(yè)槽位（slot）的資源分配模型，槽位時一個粗粒度的資源分配單位，通常一個作業(yè)不會用完槽位對應的物理資源，使得其他作業(yè)也無法再利用空閑資源。對于一些IO密集，CPU空閑,當作業(yè)槽占滿之后其他CPU密集型的也無法使用集群。MRv1將槽分為Map和Reduce兩種slot，且不允許他們之間共享，這樣做會導致另一種槽位資源緊張，另外一種資源限制。

無法支持多種計算框架，隨著數(shù)據(jù)處理要求越來越精細，Mapreduce這種基于磁盤的離線計算框架已經(jīng)滿足不了各方需求，從而出現(xiàn)了新的計算框架，如內(nèi)存計算框架、流式計算框架、迭代計算資源框架、而MRv1不支持多種計算框架并存。

YARN

隨著互聯(lián)網(wǎng)的高速發(fā)展，新的計算框架不斷出現(xiàn)，如內(nèi)存計算框架、流式計算框架、迭代計算資源框架、這幾種框架通常都會被用到考慮到資源的利用率運維和數(shù)據(jù)共享等因素，企業(yè)通常希望將所有的計算框架部署到一個 公共集群中，讓他們共享集群的計算資源，并對資源進行同意使用，同時又能采用簡單的資源隔離方案，這樣便催生了輕量彈性計算平臺需求Yarn的設(shè)計是一個彈性計算平臺，不僅僅支持Mapreduce計算框架而是朝著對多種計算框架進行統(tǒng)一管理方向發(fā)展。

資源利利用率高，按照框架角度進行資源劃分，往往存在應用程序數(shù)據(jù)和計算資源需求的不均衡性，使得某段時間內(nèi)計算資源緊張，而另外一種計算方式的資源空閑，共享集群模式則通過框架共享全部的計算資源，是的集群中的資源更加充分合理的利用。

運維成本低，如果使用：”一個框架一個集群“的模式，運維人員需要獨立管理多個框架，進而增加運維的難度，共享模式通常只需要少數(shù)管理員可以完成多個框架的管理。

數(shù)據(jù)共享，隨著數(shù)據(jù)量的增加，跨集群之間 的數(shù)據(jù)不僅增加了硬件成本呢，而且耗費時間，共享集群模式可以共享框架和硬件資源，大大降低了數(shù)據(jù)移動帶來的成本。

YARN采用了Master/Slave結(jié)構(gòu)，在整個資源管理框架中ResourceManager為master，NodeManager為Slave。ResourceManager負責對各個 NodeManager上的資源進行統(tǒng)一的管理和調(diào)度，當用戶提交一個應用程序時，需要生成以一個用于追蹤和管理這個程序即ApplicationMaster，它負責向ResourceManager申請資源，并要求NodeManager啟動可以占用一定的資源任務，不同的ApplicationMaster會被分不到不同的節(jié)點上，他們之間是相互獨立的。

ResourceManager負責整個系統(tǒng)的資源分配和管理，是一個全局的資源管理器。主要由兩個組件構(gòu)成：調(diào)度器和應用管理器。

調(diào)度器(Scheduler)：調(diào)度器根據(jù)隊列、容器等限制條件（每個隊列配給 ?一定的資源，最多執(zhí)行一定數(shù)量的作業(yè)等），將系統(tǒng)中的資源分配給各自正在運行的程序。調(diào)度器僅根據(jù)各個應用程序的 資源需求進行資源分配，而資源分配單位用一個抽象的概念”資源容器“(Container)從而限定每個使用的資源量，容器用于執(zhí)行的特定應用的進程每個容器都有所有資源限制（CPU 內(nèi)存 等）一個容器可以是一個Unix進程也可以是一個Linux cgroup(Linux內(nèi)核提升的一種限值，記錄隔離進程并且使用的物理資源 CPU 內(nèi)存 IO 等 谷歌提出)調(diào)度器相應應用程序的資源請求，是可插拔的，如Capcity ?Scheduler、Fair Scheduler。

應用程序管理器（Applications Manager）：應用程序管理器負責管理整個系統(tǒng)的所有應用程序，包括應用程序提交，與調(diào)度器協(xié)商資源以啟動ApplicationMaster、監(jiān)控ApplicationMaster運行狀態(tài)并在失敗時重新啟動等，追蹤分給的Container的情況。

ApplicationMaster是一個詳細的框架庫，他結(jié)合了ResourceManager獲取資源和NodeManager協(xié)同工作來運行和監(jiān)控任務，用戶提交的每一個應用程序軍包含一個AM，主要的功能是：

與ResourceManager調(diào)度器協(xié)商以獲取抽象資源(Container);

負責應用的監(jiān)控，追蹤應用執(zhí)行狀態(tài)重啟任務失敗等。

與NodeManager協(xié)同工作完成Task的執(zhí)行和監(jiān)控。

MRappMaster是Mapreduce的ApplicationMaster實現(xiàn)，它是的Mapreduce應用程序可以直接在YARN平臺之上，MRApplication負責Mappreduce應用的聲明周期、作業(yè)管理資源申請再分配、container啟動與釋放、作業(yè)恢復等。其他的如 Spark on YARN ,Storm on Yarn。如果需要可以自己寫一個符合規(guī)范的YARN的應用模型。

NM是每個節(jié)點上的資源和任務管理器，他會定時地向RM匯報 本節(jié)點上地資源使用情況和各個Container地運行狀態(tài)；同時會接受AM的Container啟動/停止等請求。

YARN 資源抽象 ，封存了某個節(jié)點是的多維度資源，如內(nèi)存、CPU、磁盤、網(wǎng)絡等。當AM向RM申請資源時，RM為AM返回資源是用Container表示的 。YARN為每一個任務分配給一個Container且該任務只能讀取該Container中描述的資源。Container不同于MRv1的slot，他是一個動態(tài)劃分單位，根據(jù)應用程序的需求動態(tài)生成的。

用戶向YARN提交應用程序，其中還包含了ApplicationMaster程序，啟動AM的命令，命令參數(shù)和用戶程序等等；本步驟需要準確描述運行AplicationMaster的unixs進程的所有信息。通常由YarnClient完成。

Resource Manager為該應用程序分配一個Containe，和對應的NameNode進行通信，要求他在Container中啟動ApplicationMaster；

ApplicationMaster首先向ResourceManager注冊，這樣用戶可以直接通過RM查看程序的運行狀態(tài)。然后它將為各個任務申請資源，并監(jiān)控他的運行狀態(tài)，知道運行結(jié)束，重復4~7；

ApplicationMaster采用輪詢的方式通過RPC方式向ResourceManager申請和領(lǐng)取資源，資源的協(xié)調(diào)通過異步 方式完成。

ApplicationMaster一旦申請資源后，便開始與對應的NodeManager通信，要求他們啟動作業(yè)。

NodeManager為作業(yè)設(shè)置好運行環(huán)境（環(huán)境變量，jar包，二進制程序）將任務寫道一個腳本中，并通過運行該腳本啟動作業(yè)。

各個作業(yè)通過協(xié)議RPC方式向ApplicationMaster同步匯報自己當前的進度和狀態(tài)，AM隨時掌握各個作業(yè)的運行狀態(tài)，從而在作業(yè)失敗的時候重啟作業(yè)。

應用程序運行完成后，ApplicationMaster向ResourceManager注銷并關(guān)閉。

一個應用程序可以通過ApplicationMaster請求特定的資源需求來滿足它的資源需要。調(diào)度器會被分配給一個Container來相應資源需求、用于滿足ApplicationMaster在ResourceRequst中提出的要求。Container包含5類信息：優(yōu)先級、期望資源所在節(jié)點、資源量、container數(shù)目、松弛本地性(是否沒有滿足本地資源時，選擇機架本地資源)

ResourceRequst包含物種信息:

資源名稱：期望所在的主機名、機架、用*表示沒有特殊要求。

優(yōu)先級： 程序內(nèi)部請求的優(yōu)先級，用來調(diào)整程序內(nèi)部各個ResourceRequst的次序。

資源需求：需要的資源量，表示成內(nèi)存里，CPU核數(shù)的元組(目前YARN僅支持內(nèi)存和CPU兩種資源為u的)

container數(shù)：表示 需要container數(shù)量，它決定了用該ResourceRequst指定的Container總數(shù)。

是否松弛本地性：在本機架資源剩余量無法滿足要求是改為只要運行在服務器所在的機架上進行就行。

本質(zhì)上Container是一種資源分配的形式，是ResourceManager為ResourceRequst成功分配資源的結(jié)果。Container授予節(jié)點在機器上使用資源（如內(nèi)存、CPU）的權(quán)利，YARN允許的不僅僅是Java的應用程序，概念上Container在YARN分配任務分為兩層：第一層為ResourceManage調(diào)度器結(jié)果分配給用用程序ApplicationMaster，第二層，作為運行環(huán)境用ApplicationMaster分配給作業(yè)資源。

YARN啟動應用程序流程

首先，客戶端通知ResourceManager它要提交一個應用程序。隨后ResourceManager在應答中返回一個ApplicationId以及必要的客戶端請求資源的集群容量信息，資源請求分為兩步：1.提交Application請求 2.返回ApplicationID。

3.客戶端使用“Application submission Contex”發(fā)起響應，Application subminssion上下文包含了ApplicationID、客戶名、隊列以及其他啟動Application所需要的信息。“ContainerLaunch Context”(CLC)也會發(fā)送給ResourceManager,CLC提供資源需求、作業(yè)文件、安全令牌以及在節(jié)點上啟動ApplicationMaster所需要的其他信息。應用程序被提交之后，客戶端可以向ResourceManager請求結(jié)束這個應用或者提供這個應用程序的狀態(tài)。

4.當ResourceManager接收到客戶端的應用提交上下文，它會為ApplcationMaster調(diào)度一個可用的Container來啟動AM。如果由合適的Container，Resource會聯(lián)系相應的NodeManager并啟動ApplicationMaster。如果沒有合適的Container，則請求必須等待。ApplicationMaster會發(fā)送注冊請求到ResourceManager，RM可以通過RPC的方式監(jiān)控應用程序的狀態(tài)。在注冊請求中，ResourceManager會發(fā)送集群的最大和最小的容器容量(第5步)，供ApplicationMaster決定如何使用當前集群的可用資源。

基于ResourceMangaer的可用資源信息，ApplicationMaster會請求一定數(shù)量的Container（第6步），ResourceManager根據(jù)調(diào)度政策，盡量為Application分配資源，最為資源請求應答發(fā)送給ApplicationMaster（第7步）。

應用啟動之后，ApplicationMaster將心跳和進度信息通過心跳發(fā)送給ResourceManager，這些心跳中，ApplicationMaster可以請求或釋放Container。應用結(jié)束時ApplicationMaster發(fā)送給結(jié)束信息到ResourceManager以注銷自己。

ResourceManager已經(jīng)將分配的NodeManager的控制權(quán)移交給ApplicationMaster。ApplicationMaster將獨立聯(lián)系其指定的節(jié)點管理器，并提供Container Launch Context，CLC包括環(huán)境便利，遠程存儲依賴文件、以及環(huán)境依賴文件，數(shù)據(jù)文件都被拷貝到節(jié)點的本地存儲上。同一個節(jié)點的依賴文件都可以被同一應用程序Container共享。

一旦所有的Container都啟動完成，ApplicationMaster就可以檢查他們的狀態(tài)。ResourceManager不參與應用程序的執(zhí)行，只處理調(diào)度和監(jiān)控其他資源。ResourceManager可以命令NodeManager殺死Container，比如ApplicationMaster通知ResourceManager自己的任務結(jié)束或者時ResourceManager需要為其他應用程序搶占資源。或者Container超出資源限制時都可能發(fā)生殺死Container事件。當Container被銷毀后，NodeManager會清理它的本地工作目錄。 應停用程序結(jié)束后，ApplicationMaster會發(fā)送結(jié)束信號通知ResourceManager，然后ResourceManager通知NodeManager收集日志并清理Container專用文件。如果Container還沒退出，NodeManager也可以接收指令去殺死剩余的Container。

簡單易懂，不需要任何配置(FIFO Scheduler),容量調(diào)度器(Capcity Scheduler)和公平調(diào)度器（Fair Scheduler）。FIFO調(diào)度器將應用放置在一個隊列中然后按照提交的順序(先進先出)運行應用，首先為隊列中的第一個任務請求分配資源。第一個應用的請求被滿足后再一次為隊列的下一條進行服務。

一個獨立的專門隊列保證小作業(yè)提交就可以啟動，由于隊列容量是為了那個隊列中的作業(yè)所保留的。這意味這與使用FIFO調(diào)度器相比，大作業(yè)執(zhí)行的事件要長。容量調(diào)度器允許多個組織共享一個Hadoop集群，每個組織可以分配到全部集群資源的一部分。每個組織都被配置一個專門的隊列，每個隊列都被配置為可以使用一定的集群資源。隊列可以進一步按層次劃分，這樣每個組織內(nèi)的不同用戶能夠共享該組織隊列所分配的資源。在一個隊列內(nèi)，使用FIFO調(diào)度政策對應用進行調(diào)度。單個作業(yè)使用的資源不會超過其隊列容量然而，如果隊列中由多個作業(yè)，并且隊列資源不夠用，如果仍有可用的空閑資源，那么容量調(diào)度器可能會被空余的資源分配給隊列的作業(yè)，哪怕這超出隊列容量。這稱之為為“彈性隊列”。

Fair調(diào)度器是一個隊列資源分配方式，在整個時間線上，所有的Job平均的獲取資源。默認情況下，F(xiàn)air調(diào)度器知識對內(nèi)存資源做公平的調(diào)度和分配。當集群中只有一個任務運行時，那么此任務會占用整個集群的資源。當其他的任務提交后，那些釋放的資源就會被分配給新的Job，所以每個任務最終都能夠獲取幾乎一樣多的資源。

總結(jié)：

FIFO： 最簡單的調(diào)度器，按照先進先出的方式處理應用。只有一個隊列可提交應用，所有的用戶提交到這個隊列。可以針對這個隊列設(shè)置ACL，沒有應用優(yōu)先級可以配置。

Capcity：可以看作是FIFO的多隊列版本，每個隊列可以限制資源使用量。但是隊列間的資源分配 以使用量安培作為依據(jù)，使得容量小的隊列有競爭優(yōu)勢，集群整體吞較大。延遲調(diào)度機制使得應用可以放棄，跨機器或者跨機架的調(diào)度機會，爭取本地調(diào)度。

Fair：多隊列，多用戶共享資源。特有的客戶端創(chuàng)建隊列的特性，使得權(quán)限控制不太完美，根據(jù)隊列設(shè)定的最小共享量或者權(quán)重等參數(shù)，按照比例共享資源。延遲調(diào)度機制跟Capcity的牡蠣類似但是實現(xiàn)方式稍微不同，資源搶占特性，是指調(diào)度容器能夠依據(jù)公平共享算法，計算每個隊列應得的資源，將超額資源的隊列的部分容器釋放掉的特性。

總結(jié)

分布式 Hadoop 大數(shù)據(jù) Yarn

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。