Hadoop集群資源管理系統YARN介紹

YARN產生背景

MRv1的局限

YARN是在MRv1基礎上演化而來的,它克服了MRv1中的各種局限性。在正式介紹YARN之前,先了解下MRv1的一些局限性,主要有以下幾個方面:

  • 擴展性差。在MRv1中,JobTracker同時兼備了資源管理作業控制兩個功能,這成為系統的一個最大瓶頸,嚴重制約了Hadoop集群擴展性。
  • 可靠性差。MRv1采用了master/slave結構,其中,master存在單點故障問題,一旦它出現故障將導致整個集群不可用。
  • 資源利用率低。MRv1采用了基于槽位的資源分配模型,槽位是一種粗粒度的資源劃分單位,通常一個任務不會用完槽位對應的資源,且其他任務也無法使用這些空閑資源。此外,Hadoop將槽位分為Map Slot和Reduce Slot兩種,且不允許它們之間共享,常常會導致一種槽位資源緊張而另外一種閑置(比如一個作業剛剛提交時,只會運行Map Task,此時Reduce Slot閑置)。
  • 無法支持多種計算框架。隨著互聯網高速發展,MapReduce這種基于磁盤的離線計算框架已經不能滿足應用要求,從而出現了一些新的計算框架,包括內存計算框架、流式計算框架和迭代式計算框架等,而MRv1不能支持多種計算框架并存。

為了克服以上幾個缺點,Apache開始嘗試對Hadoop進行升級改造,進而誕生了更加先進的下一代MapReduce計算框架MRv2。正是由于MRv2將資源管理功能抽象成了一個獨立的通用系統YARN,直接導致下一代MapReduce的核心從單一的計算框架MapReduce轉移為通用的資源管理系統YARN。

集群資源統一管理

隨著互聯網的高速發展,新的計算框架不斷出現,從支持離線處理的MapReduce,到支持在線處理的Storm,從迭代式計算框架Spark到流式處理框架S4,各種框架各有所長,各自解決了某一類應用問題。這時候就需要一個組件對同一個集群上的不同計算框架進行資源的統一管理。

YARN

相比于“一種計算框架一個集群”的模式,共享集群的模式存在多種好處:

  • 資源利用率高。如果每個框架一個集群,可能在某段時間內,有些計算框架的集群資源緊張,而另外一些集群資源空閑。共享集群模式則通過多種框架共享資源,使得集群中的資源得到更加充分的利用。
  • 運維成本低。如果采用“一個框架一個集群”的模式,則可能需要多個管理員管理這些集群,進而增加運維成本,而共享模式通常需要少數管理員即可完成多個框架的統一管理。
  • 數據共享。隨著數據量的暴增,跨集群間的數據移動不僅需花費更長的時間,且硬件成本也會大大增加,而共享集群模式可讓多種框架共享數據和硬件資源,將大大減小數據移動帶來的成本。

YARN基本設計思想

MRv1主要由編程模型、數據處理引擎(由Map Task和Reduce Task組成)和運行時環境三部分組成。為了保證編程模型的向后兼容性,MRv2重用了MRv1中的編程模型和數據處理引擎,但運行時環境被完全重寫。

MRv1的運行時環境主要由兩類服務組成,分別是JobTracker和TaskTracker。其中,JobTracker負責資源管理作業控制。TaskTracker負責單個節點資源管理和任務執行

MRv1將資源管理和應用程序管理兩部分混雜在一起,使得它在擴展性、容錯性和多框架支持等方面存在明顯缺陷。

而MRv2則通過將資源管理和應用程序管理兩部分剝離開,分別由ResourceManager和ApplicationMaster負責,其中ResourceManager專管資源管理和調度,而ApplicationMaster則負責與具體應用程序相關的任務切分、任務調度和容錯等,具體如下圖所示。

Paste_Image.png

YARN基本架構

YARN是Hadoop 2.0中的資源管理系統,它的基本設計思想是將MRv1中的JobTracker拆分成了兩個獨立的服務:一個全局的資源管理器ResourceManager每個應用程序特有的ApplicationMaster。其中ResourceManager負責整個系統的資源管理和分配,而ApplicationMaster負責單個應用程序的管理

YARN總體上仍然是Master/Slave結構,在整個資源管理框架中,ResourceManager為Master,NodeManager為Slave,ResourceManager負責對各個NodeManager上的資源進行統一管理和調度。當用戶提交一個應用程序時,需要提供一個用以跟蹤和管理這個程序的ApplicationMaster,它負責向ResourceManager申請資源,并要求NodeManger啟動可以占用一定資源的任務。由于不同的ApplicationMaster被分布到不同的節點上,因此它們之間不會相互影響。

下圖描述了YARN的基本組成結構,YARN主要由ResourceManager、NodeManager、ApplicationMaster(圖中給出了MapReduce和MPI兩種計算框架的ApplicationMaster,分別為MR AppMstr和MPI AppMstr)和Container等幾個組件構成。

YARN基本架構

接下來對YARN里幾個重要的組件一一介紹。

1. ResourceManager(RM)

RM是一個全局的資源管理器,負責整個系統的資源管理和分配。它主要由兩個組件構成:調度器(Scheduler)和應用程序管理器(Applications Manager,ASM)。

(1)調度器(分配Container)

調度器根據容量、隊列等限制條件(如每個隊列分配一定的資源,最多執行一定數量的作業等),將系統中的資源分配給各個正在運行的應用程序。需要注意的是,該調度器是一個“純調度器”,它不再從事任何與具體應用程序相關的工作,比如不負責監控或者跟蹤應用的執行狀態等,也不負責重新啟動因應用執行失敗或者硬件故障而產生的失敗任務,這些均交由應用程序相關的ApplicationMaster完成。調度器僅根據各個應用程序的資源需求進行資源分配,而資源分配單位用一個抽象概念“資源容器”(Resource Container,簡稱Container)表示,Container是一個動態資源分配單位,它將內存、CPU、磁盤、網絡等資源封裝在一起,從而限定每個任務使用的資源量。此外,該調度器是一個可插拔的組件,用戶可根據自己的需要設計新的調度器,YARN提供了多種直接可用的調度器,比如Fair Scheduler和Capacity Scheduler等。

(2)應用程序管理器

應用程序管理器負責管理整個系統中所有應用程序,包括應用程序提交、與調度器協商資源以啟動ApplicationMaster、監控ApplicationMaster運行狀態并在失敗時重新啟動它等。

2. ApplicationMaster(AM)

用戶提交的每個應用程序均包含一個AM,主要功能包括:

  • 與RM調度器協商以獲取資源(以Container表示)
  • 將得到的任務進一步分配給內部的任務
  • 與NM通信以啟動/停止任務
  • 監控所有任務運行狀態,并在任務失敗時重新為任務申請資源以重啟任務

3. NodeManager(NM)

NM是每個節點上的資源和任務管理器。一方面,它定時地向RM匯報本節點的資源使用情況和Container運行狀態;另一方面,它接受并處理來自AM的Container啟動/停止等各種請求。

4. Container

Container是YARN中的資源抽象,它封裝了某個節點上的多維資源,如CPU、內存、磁盤、網絡等。當AM向RM申請資源時,RM向AM返回的資源便是用Container表示的。YARN會為每個任務分配一個Container,且該任務只能使用該Container中描述的資源。Container是一個動態資源劃分單位,是根據應用程序的需求自動生成的。目前,YARN僅支持CPU和內存兩種資源。

YARN工作流程

運行在YARN上的應用程序主要分為兩類:短應用程序和長應用程序。其中,短應用程序是指一定時間內可運行完成并正常退出的應用程序,如MapReduce作業、Spark DAG作業等。長應用程序是指不出意外,永不終止運行的應用程序,通常是一些服務,比如Storm Service(包括Nimbus和Supervisor兩類服務),HBase Service(包括HMaster和RegionServer兩類服務)等,而它們本身作為一種框架提供編程接口供用戶使用。盡管這兩類應用程序作業不同,一類直接運行數據處理程序,一類用于部署服務(服務之上再運行數據處理程序),但運行在YARN上的流程是相同的。

當用戶向YARN中提交一個應用程序后,YARN將分兩個階段運行該應用程序:第一階段是啟動ApplicationMaster。第二階段是由ApplicationMaster創建應用程序,為它申請資源,并監控它的整個運行過程,直到運行完成。具體如下:

  1. 用戶向YARN中提交應用程序,其中包括ApplicationMaster程序、啟動ApplicationMaster的命令、用戶程序等。
  2. ResourceManager為該應用程序分配第一個Container,并與對應的NodeManager通信,要求它在這個Container中啟動應用程序的ApplicationMaster。
  3. ApplicationMaster首先向ResourceManager注冊,這樣用戶就可以直接通過ResourceManager查看應用程序的運行狀態,然后它將為各個任務申請資源,并監控它的運行狀態,直到運行結束,即重復步驟4~7。
  4. ApplicationMaster采用輪詢的方式通過RPC協議向ResourceManager申請和領取資源。
  5. 一旦ApplicationMaster申請到資源后,便與對應的NodeManager通信,要求它啟動任務。
  6. NodeManager為任務設置好運行環境(包括環境變量、JAR包、二進制程序等)后,將任務啟動命令寫到一個腳本中,并通過運行該腳本啟動任務。
  7. 各個任務通過某個RPC協議向ApplicationMaster匯報自己的狀態和進度,以讓ApplicationMaster隨時掌握各個任務的運行狀態,從而可以在任務失敗時重新啟動任務。
  8. 應用程序運行完成后,ApplicationMaster向ResourceManager注銷并關閉自己。
YARN工作流程
FullStackPlan

歡迎關注公眾號: FullStackPlan 獲取更多干貨哦~

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,786評論 6 534
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,656評論 3 419
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,697評論 0 379
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,098評論 1 314
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,855評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,254評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,322評論 3 442
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,473評論 0 289
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,014評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,833評論 3 355
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,016評論 1 371
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,568評論 5 362
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,273評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,680評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,946評論 1 288
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,730評論 3 393
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,006評論 2 374

推薦閱讀更多精彩內容