1. 程式人生 > >MapReduce再學習:資源管理框架YARN

MapReduce再學習:資源管理框架YARN

在前面寫到的三篇部落格中,HDFS概述MapReduce簡介寫的都是hadoop1.0的情況,針對1.0版本的各種不足,2.0都有相應的改動, HDFS再學習:HA和Federation機制寫的是儲存系統HDFS上的改動。針對我們的計算模型MapReduce,2.0版本設計了新的資源管理框架YARN。

元件 Hadoop1.0的問題 Hadoop2.0的改進
HDFS 單一節點問題 Hdfs HA提供熱備機制
HDFS 單一名稱空間 Hdfs Federation管理多名稱空間
MapReduce 資源管理效率低 新的資源管理框架YARN

MapReduce1.0的缺陷

回顧一下MapReduce1.0的結構,,詳細的可以去看上一篇部落格:

MapReduce1.0
存在問題:
1、JobTracker“大包大攬”,導致任務過重且單結點限制了規模。
2、容易出現記憶體溢位問題。因為分配資源時考慮的是MapReduce的任務數,不考慮CPU,記憶體等問題。
3、資源劃分不合理。如上一篇部落格裡面介紹道,MR1.0裡面的資源單位為槽slot,強制分為MapSlot和ReduceSlot,即使沒有map任務,但是reduce任務槽數不夠用,reduce任務也沒法使用map任務的槽。

YARN的設計思路

YARN是一個分散式資源管理系統,用於提高分散式的叢集環境下資源的利用率,這些資源包括記憶體,I/O,網路,磁碟等。其產生的原因是為了解決MapReduce框架的不足。

YARN

我們從MapReduce1.0的結構圖可以看到,1.0版本既是一個計算框架,也是一個資源排程框架。資源排程方面的jobTracker不僅負責了資源的管理還負責任務的排程和任務的監控。2.0版本把資源排程的任務分離出來,形成了YARN,也就是說,YARN是一個純粹的資源管理排程框架,而2.0版本的mapReduce就只是一個純粹的計算框架了,不再自己負責資源管理服務

2.0版本中把jobTracker的資源管理交給了全域性的資源管理器ResourceManager,任務方面的排程和監控交給了應用相關的ApplicationMaster,用節點NodeManage來替代TaskTracker。

ResourceManager


RM是一個全域性的資源管理器,負責整個系統的資源管理與分配,主要包括兩個元件:排程器Scheduler和應用程式管理器Applications Manager。

排程器接收來自ApplicationMaster的應用程式資源請求,把叢集中的資源以“容器”的形式分配給提出申請的應用程式,容器的選擇通常考慮應用程式所要處理的資料的位置,就近選擇,實現“計算向資料靠攏”。

Container容器
動態資源分配的單位,每個容器中都封裝一定數量的CPU、記憶體、磁碟等資源,從而限制每個應用程式可以使用的資源量。

scheduler排程器
是一個可插拔的元件,YARN不僅自身提供了很多可以直接用的排程器,也允許使用者自定義。

Applications Manager應用程式管理器
負責系統中所有應用程式的管理工作,主要包括應用程式提交,與排程器協商資源以啟動、監控、重啟ApplicationMaster。

ApplicationMaster
ResourceManager接收使用者提交的作業(記住,hadoop中處理的使用者程式都是以作業的形式來處理的,只是我們計算的時候把作業變成了一個個的map/reduce任務),按照作業的上下文資訊及從NodeManager收集來的容器狀態資訊,啟動排程過程,在NodeManager中啟動一個容器為ApplicationMaster(applicationMaster的執行也佔用資源,它是由resourceManager在nodeManager中啟動的一個container)。

其作用是:
為應用程式申請資源,並分配給內部任務。
負責這個任務的排程、監控與容錯(任務失敗時重申資源,重啟任務)。

NodeManager
單個節點上的資源管理,每個節點上就有一個。
監控節點上容器的資源使用情況。
跟蹤節點健康狀況。
以“心跳”方式與ResourceManager保持通訊。
接收來自ResourceManager和ApplicationMaster的各種請求。

YARN的工作流程

YARNProcess

1、使用者提交程式,包括ApplicationMaster程式,啟動AM的命令和使用者程式。
2、YARN中的ResourceManager負責接收和處理來自客戶端的程式,選擇NodeManager中的一個容器,啟動ApplicationMaster。
3、ApplicationMaster建立後會先向 ResourceManager註冊。
4、ApplicationMaster輪詢向ResourceManager申請資源。
5、ResourceManager以容器的方式向提出申請的AM分配資源。
6、在容器中啟動任務。
7、各個任務向Am報告狀態與進度。
8、應用程式結束後,AM向RM登出並關閉自己。

YARN體系結構

叢集部署上,YARN的各個元件是與Hadoop叢集中的其他元件統一部署的。

ResourceManager和NameNode一起,是主節點。

ApplicationMaster可以和資料節點一起,由NodeManager管理。

container和資料節點一起,(方便計算),由NodeManager管理。

YarnStructure

從MapReduce1.0框架發展到YARN框架,客戶端並沒有發生變化,其大部分呼叫API及介面都保持相容,因此,原來針對Hadoop1.0開發的程式碼不用做大的改動,就可以直接放到Hadoop2.0平臺上執行

Yarn與MapReduce1.0框架的對比分析

總體而言,YARN相對於MapReduce1.0來說具有以下優勢
1、大大減少了承擔中心服務功能的ResourceManager的資源消耗
ApplicationMaster來完成需要大量資源消耗的任務排程和監控
多個作業對應多個ApplicationMaster,實現了監控分佈化

2、MapReduce1.0既是一個計算框架,又是一個資源管理排程框架,但是,只能支援MapReduce程式設計模型。而YARN則是一個純粹的資源排程管理框架,在它上面可以執行包括MapReduce在內的不同型別的計算框架,比如storm實現流計算,spark實現記憶體計算等等,只要程式設計實現相應的ApplicationMaster

3、YARN中的資源管理比MapReduce1.0更加高效
以容器為單位,而不是以slot為單位

YARN的目標是實現“一個叢集多個框架”,即在一個叢集上部署一個統一的資源排程框架YARN,在此上可以部署其它各種計算框架。由YARN為這些計算框架提供統一的資源排程管理服務,並且能根據各種計算框架的負載需求,調整各自佔用的資源,實現叢集資源共享與資源彈性收縮。
這樣,不同的計算框架可以共享底層的儲存,避免了資料集跨叢集的移動。