什么是YARN?跟HBase和Spark比优势在哪?终于有人讲明白了
導(dǎo)讀:HBase沒有資源什么事情也做不了,Spark占用了資源卻沒有事情可做?YARN了解一下。
作者:朱凱
來源:大數(shù)據(jù)DT(ID:hzdashuju)
01?概述
隨著Hadoop生態(tài)的發(fā)展,開源社區(qū)出現(xiàn)了多種多樣的技術(shù)組件。有用來構(gòu)建數(shù)據(jù)倉庫的Hive,也有基于內(nèi)存的計算框架Spark,還有我們之前介紹過的NoSQL數(shù)據(jù)庫HBase等。
這些技術(shù)組件的出現(xiàn),極大地豐富了大數(shù)據(jù)的生態(tài)體系,但同時也引出了一些新的問題。作為一個大數(shù)據(jù)底層支撐平臺,同時部署Hive、HBase和Spark等多種技術(shù)組件是一件十分平常的事情。這些為大數(shù)據(jù)場景設(shè)計的技術(shù)組件可以說個個都是消耗資源的大戶,這些資源包括服務(wù)器的CPU和內(nèi)存。
通常這些技術(shù)組件都有一套自己的資源調(diào)度系統(tǒng)用來管理任務(wù)的資源分配,但當(dāng)它們同時部署在一起的時候就出問題了。這時會有兩種情況產(chǎn)生,第一種情況是某些組件可能申請不到服務(wù)器資源。
比如一臺擁有32G內(nèi)存的服務(wù)器同時部署了HBase和Spark,HBase的RegionServer啟動時占用了20GB內(nèi)存,這時Spark開始執(zhí)行某個任務(wù)也需要使用20GB內(nèi)存,但這時發(fā)現(xiàn)沒有足夠的內(nèi)存資源使用了。因為從每個組件獨立的視角來看他們都認(rèn)為自己能使用100%的服務(wù)器資源,但服務(wù)器資源的總量就那么多,不可能同時滿足所有組件的需求。
第二種是可能會出現(xiàn)資源分配不合理的情況,導(dǎo)致整體資源使用率偏低。我們同樣用剛才的場景舉例,Spark啟動了一個任務(wù)申請使用30GB的內(nèi)存,但是實際上它的程序邏輯并不需要使用這么多資源。這就出現(xiàn)了一種HBase沒有資源什么事情也做不了,但Spark占用了資源卻沒有事情可做的局面。
為了解決類似的問題,我們需要一種通用的資源調(diào)度框架,對整個集群的資源進(jìn)行統(tǒng)籌管理。
YARN就是一款優(yōu)秀的集群資源調(diào)度框架。YARN是Yet Another Resource Negotiator的縮寫,它是Hadoop的第二代集群資源調(diào)度框架。
解決了Hadoop第一代集群資源調(diào)度框架上可靠性差、擴(kuò)展性差等一系列問題,同時YARN從MapReduce中完全獨立出來,從專門支撐MapReduce任務(wù)調(diào)度升級成為了一個支持多種應(yīng)用類型的通用集群資源調(diào)度框架。
除了MapReduce之外,Spark、Hive等一系列服務(wù)都可以作為應(yīng)用運行在YARN之上,統(tǒng)一使用YARN為整個集群資源進(jìn)行宏觀的調(diào)度與分配,如圖2-12所示。
▲圖2-12 YARN的邏輯結(jié)構(gòu)
02 資源模型和Container
YARN將服務(wù)器資源進(jìn)行了抽象封裝,它使用Container對象代表申請資源的基本單元。
這些資源包括資源名稱(服務(wù)器名稱、機(jī)架等)、內(nèi)存和CPU,YARN通過Container機(jī)制將服務(wù)器資源進(jìn)行了隔離。每個應(yīng)用都可以通過ApplicationMaster向ResourceManager申請資源,當(dāng)ApplicationMaster向ResourceManager申請資源時,ResourceManager返回的資源使用Container的個數(shù)來表示,比如一個Spark計算任務(wù)需要5個Container資源。
03 ResourceManager
ResourceManager是一個全局的資源管理器,負(fù)責(zé)整個系統(tǒng)的資源管理和分配以保證整個集群的高效運行。它會根據(jù)容量、隊列等限制條件(如每個隊列分配一定的資源,最多執(zhí)行一定數(shù)量的作業(yè)等),將系統(tǒng)中的資源分配給各個正在運行的應(yīng)用程序。
ResourceManager只負(fù)責(zé)根據(jù)各個應(yīng)用程序的資源請求進(jìn)行資源分配,不參與任何與具體應(yīng)用程序相關(guān)的工作,比如不負(fù)責(zé)監(jiān)控或者跟蹤應(yīng)用的執(zhí)行狀態(tài)等,也不負(fù)責(zé)重新啟動因應(yīng)用執(zhí)行失敗或者硬件故障而產(chǎn)生的失敗任務(wù),這些均交由應(yīng)用程序相關(guān)的ApplicationMaster完成。資源分配單位用的是我們剛才介紹過的Container對象。
此外,ResourceManager還支持一個可插拔的調(diào)度器插件來支持多種資源調(diào)度策略,比如使用公平調(diào)度或是容量調(diào)度。
04 ApplicationMaster
每一個想要運行在YARN上的應(yīng)用都必須有一個相應(yīng)的ApplicationMaster實現(xiàn),應(yīng)用將內(nèi)部的任務(wù)調(diào)度邏輯和監(jiān)控都交由它們自己的ApplicationMaster實現(xiàn)類來處理。
ApplicationMaster是YARN的一個創(chuàng)新設(shè)計,YARN通過這種機(jī)制將自己打造成了一個擴(kuò)展性極強(qiáng)的通用資源調(diào)度框架,因為它允許用戶開發(fā)自己的ApplicationMaster實現(xiàn)。
ApplicationMaster進(jìn)程在運行的過程中主要負(fù)責(zé)與ResourceManager進(jìn)行通信,以申請執(zhí)行任務(wù)時所需要的資源,在申請到資源之后再進(jìn)一步執(zhí)行自身內(nèi)部的調(diào)度任務(wù)。同時ApplicationMaster也負(fù)責(zé)監(jiān)控自己運行的內(nèi)部任務(wù)狀態(tài),在任務(wù)失敗的時候重新為任務(wù)申請相應(yīng)資源并重啟任務(wù)。
ApplicationMaster通常作為一個應(yīng)用的主進(jìn)程,主要用來扮演拆分子任務(wù)、匯總結(jié)果數(shù)據(jù)這類的總體調(diào)度,比如Spark的Driver進(jìn)程。而真正的執(zhí)行程序業(yè)務(wù)邏輯的進(jìn)程是在NodeManager進(jìn)程上執(zhí)行的。
05 NodeManager
NodeManager是每個服務(wù)器節(jié)點上資源管理器,負(fù)責(zé)管理自己所處服務(wù)器Containers的整個生命周期。
在YARN上運行的應(yīng)用最終的邏輯執(zhí)行程序(比如Spark的task、MapReduce的job)都會在NodeManager的Container中運行,可以說NodeManager是YARN計算節(jié)點的代理,因為ResourceManager只會將任務(wù)分配到啟動了NodeManager進(jìn)程的服務(wù)器。
當(dāng)NodeManager進(jìn)程啟動的時候它會向ResourceManager進(jìn)行注冊,并定時匯報自己所在服務(wù)器的資源使用情況和Container運行狀態(tài),同時它也接受并處理來自ApplicationMaster的Container啟動和停止等各種請求。
06 單一集群架構(gòu)
通過上面的介紹我們不難發(fā)現(xiàn),ResourceManager、NodeManager和Container組件都不關(guān)心具體的應(yīng)用程序或任務(wù)的類型,只有ApplicationMaster才是應(yīng)用類型相關(guān)的。
YARN通過使用開放ApplicationMaster的集成方式,允許第三方應(yīng)用框架便捷的和YARN進(jìn)行集成。這才有了像MapReduce On YARN、Storm On YARN、Spark On YARN和Tez On YARN等眾多第三方應(yīng)用集成方案的出現(xiàn)。
通過這種資源共享的單一集群架構(gòu),我們在企業(yè)內(nèi)部可以實現(xiàn)服務(wù)器資源真正的共享使用,以達(dá)到降低技術(shù)集成成本和增強(qiáng)資源整體利用率的目的。
07 工作流程
接下來我們簡單看一下YARN的整個工作過程,如圖2-13所示。
用戶向YARN中提交應(yīng)用程序。
ResourceManager為該應(yīng)用程找到一個可用的NodeManager并分配第一個Container,然后在這個Container中啟動應(yīng)用程序的ApplicationMaster。
ApplicationMaster向ResourceManager進(jìn)行注冊,這樣用戶就可以通過ResourceManager查看應(yīng)用程序的運行狀態(tài)并對任務(wù)進(jìn)行監(jiān)控。
ApplicationMaster采用輪詢的方式通過RPC協(xié)議向ResourceManager申請和領(lǐng)取資源。
ApplicationMaster申請到資源后與對應(yīng)的NodeManager通信,要求它啟動Container并為任務(wù)設(shè)置好運行環(huán)境。
應(yīng)用程序的任務(wù)開始在啟動的Container中運行,各個任務(wù)向ApplicationMaster匯報自己的狀態(tài)和進(jìn)度,以便ApplicationMaster隨時掌握各個任務(wù)的運行狀態(tài),從而可以在任務(wù)失敗時重新啟動任務(wù)。
應(yīng)用在運行的過程中,客戶端通過輪詢的方式主動與ApplicationMaster通信以獲得應(yīng)用的運行狀態(tài)、執(zhí)行進(jìn)度等信息。
應(yīng)用程序運行完成后,ApplicationMaster向ResourceManager注銷并關(guān)閉自己。
▲圖2-13 YARN的工作流程
08 使用場景
基于YARN擴(kuò)展性強(qiáng)、可靠性強(qiáng)、支持多用戶和支持多應(yīng)用的特點,它非常適合于支撐企業(yè)內(nèi)部構(gòu)建統(tǒng)一的資源共享型大數(shù)據(jù)平臺。借助YARN我們可以真正實現(xiàn)通過一套資源調(diào)度系統(tǒng)集成所有應(yīng)用組件的單一大集群架構(gòu)。
1. Spark任務(wù)調(diào)度
Spark是一款分布式內(nèi)存計算框架,Spark可以將自身的任務(wù)調(diào)度部分委托YARN進(jìn)行管理,從而實現(xiàn)集群資源高效整合與利用。
2. MapReduce任務(wù)調(diào)度
同樣的,MapReduce任務(wù)的整個生命周期都可以借助YARN進(jìn)行管理,包括任務(wù)的分配、資源的調(diào)度,等等。
關(guān)于作者:朱凱,資深大數(shù)據(jù)專家和架構(gòu)師,擁有10年IT從業(yè)經(jīng)驗,精通大數(shù)據(jù)、Java、Node.JS等技術(shù)。對大數(shù)據(jù)領(lǐng)域的主流技術(shù)與解決方案有深入研究,擅長分布式系統(tǒng)的架構(gòu)設(shè)計與整合。曾主導(dǎo)過多款大數(shù)據(jù)平臺級產(chǎn)品的規(guī)劃設(shè)計與研發(fā)工作,一線實戰(zhàn)經(jīng)驗豐富。
本文摘編自《企業(yè)級大數(shù)據(jù)平臺構(gòu)建:架構(gòu)與實現(xiàn)》,經(jīng)出版方授權(quán)發(fā)布。
延伸閱讀《企業(yè)級大數(shù)據(jù)平臺構(gòu)建:架構(gòu)與實現(xiàn)》
點擊上圖了解及購買
轉(zhuǎn)載請聯(lián)系微信:DoctorData
推薦語:資深大數(shù)據(jù)專家/一線架構(gòu)師20000小時實際工作經(jīng)驗總結(jié)。以橫向視角出發(fā),拉通Hadoop體系技術(shù)棧,手把手教你快速構(gòu)建一個真實可用、安全可靠的企業(yè)級大數(shù)據(jù)平臺。
劃重點????
干貨直達(dá)????
終于有人把大數(shù)據(jù)講明白了
盤點谷歌、Facebook和IBM的重磅AI項目
為什么微服務(wù)化、數(shù)據(jù)倉庫都不是中臺?
Python條件判斷語句詳解:if、else、switch都有了
更多精彩????
在公眾號對話框輸入以下關(guān)鍵詞
查看更多優(yōu)質(zhì)內(nèi)容!
PPT?|?讀書?|?書單?|?硬核?|?干貨?|?講明白?|?神操作
大數(shù)據(jù)?|?云計算?|?數(shù)據(jù)庫?|?Python?|?可視化
AI?|?人工智能?|?機(jī)器學(xué)習(xí)?|?深度學(xué)習(xí)?|?NLP
5G?|?中臺?|?用戶畫像?|?1024?|?數(shù)學(xué)?|?算法?|?數(shù)字孿生
據(jù)統(tǒng)計,99%的大咖都完成了這個神操作
????
總結(jié)
以上是生活随笔為你收集整理的什么是YARN?跟HBase和Spark比优势在哪?终于有人讲明白了的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 从AI到IA,你愿意买一个机器人伴侣同居
- 下一篇: Redis如何高效可靠地实现主从复制?终