編者按:對于業界的大數據存儲及分布式處理系統來說,Hadoop 是耳熟能詳的卓越開源分布式文件存儲及處理框架,對于 Hadoop 框架的介紹在此不再累述,隨著需求的發展,Yarn
框架浮出水面,
@依然光榮復興的
博客給我們做了很詳細的介紹,讀者通過本文中新舊 Hadoop MapReduce 框架的對比,更能深刻理解新的 yarn 框架的技術原理和設計思想。
Yarn是一個分布式的資源管理系統,用以提高分布式的集群環境下的資源利用率,這些資源包括內存、IO、網絡、磁盤等。其產生的原因是為了解決原MapReduce框架的不足。最初MapReduce的committer們還可以周期性的在已有的代碼上進行修改,可是隨著代碼的增加以及原MapReduce框架設計的不足,在原MapReduce框架上進行修改變得越來越困難,所以MapReduce的committer們決定從架構上重新設計MapReduce,使下一代的MapReduce(MRv2/Yarn)框架具有更好的擴展性、可用性、可靠性、向后兼容性和更高的資源利用率以及能支持除了MapReduce計算框架外的更多的計算框架。
Yarn/MRv2最基本的想法是將原JobTracker主要的資源管理和job調度/監視功能分開作為兩個單獨的守護進程。有一個全局的ResourceManager(RM)和每個Application有一個ApplicationMaster(AM),Application相當于map-reduce
job或者DAG jobs。ResourceManager和NodeManager(NM)組成了基本的數據計算框架。ResourceManager協調集群的資源利用,任何client或者運行著的applicatitonMaster想要運行job或者task都得向RM申請一定的資源。ApplicatonMaster是一個框架特殊的庫,對于MapReduce框架而言有它自己的AM實現,用戶也可以實現自己的AM,在運行的時候,AM會與NM一起來啟動和監視tasks。
ResourceManager作為資源的協調者有兩個主要的組件:Scheduler和ApplicationsManager(AsM)。
Scheduler負責分配最少但滿足application運行所需的資源量給Application。Scheduler只是基于資源的使用情況進行調度,并不負責監視/跟蹤application的狀態,當然也不會處理失敗的task。RM使用resource container概念來管理集群的資源,resource container是資源的抽象,每個container包括一定的內存、IO、網絡等資源,不過目前的實現只包括內存一種資源。
ApplicationsManager負責處理client提交的job以及協商第一個container以供applicationMaster運行,并且在applicationMaster失敗的時候會重新啟動applicationMaster。下面闡述RM具體完成的一些功能。
關于ResourceManager的可用性目前還沒有很好的實現,不過Cloudera公司的CDH4.4以后的版本實現了一個簡單的高可用性,使用了Hadoop-common項目中HA部分的代碼,采用了類似hdfs namenode高可用性的設計,給RM引入了active和standby狀態,不過沒有與journalnode相對應的角色,只是由zookeeper來負責維護RM的狀態,這樣的設計只是一個最簡單的方案,避免了手動重啟RM,離真正的生產可用還有一段距離。
NM主要負責啟動RM分配給AM的container以及代表AM的container,并且會監視container的運行情況。在啟動container的時候,NM會設置一些必要的環境變量以及將container運行所需的jar包、文件等從hdfs下載到本地,也就是所謂的資源本地化;當所有準備工作做好后,才會啟動代表該container的腳本將程序啟動起來。啟動起來后,NM會周期性的監視該container運行占用的資源情況,若是超過了該container所聲明的資源量,則會kill掉該container所代表的進程。
另外,NM還提供了一個簡單的服務以管理它所在機器的本地目錄。Applications可以繼續訪問本地目錄即使那臺機器上已經沒有了屬于它的container在運行。例如,Map-Reduce應用程序使用這個服務存儲map output并且shuffle它們給相應的reduce task。
在NM上還可以擴展自己的服務,yarn提供了一個yarn.nodemanager.aux-services的配置項,通過該配置,用戶可以自定義一些服務,例如Map-Reduce的shuffle功能就是采用這種方式實現的。
NM在本地為每個運行著的application生成如下的目錄結構:
在啟動一個container的時候,NM就執行該container的default_container_executor.sh,該腳本內部會執行launch_container.sh。launch_container.sh會先設置一些環境變量,最后啟動執行程序的命令。對于MapReduce而言,啟動AM就執行org.apache.hadoop.mapreduce.v2.app.MRAppMaster;啟動map/reduce
task就執行org.apache.hadoop.mapred.YarnChild。
ApplicationMaster是一個框架特殊的庫,對于Map-Reduce計算模型而言有它自己的ApplicationMaster實現,對于其他的想要運行在yarn上的計算模型而言,必須得實現針對該計算模型的ApplicationMaster用以向RM申請資源運行task,比如運行在yarn上的spark框架也有對應的ApplicationMaster實現,歸根結底,yarn是一個資源管理的框架,并不是一個計算框架,要想在yarn上運行應用程序,還得有特定的計算框架的實現。由于yarn是伴隨著MRv2一起出現的,所以下面簡要概述MRv2在yarn上的運行流程。
MRv2運行流程:
在yarn上寫應用程序并不同于我們熟知的MapReduce應用程序,必須牢記yarn只是一個資源管理的框架,并不是一個計算框架,計算框架可以運行在yarn上。我們所能做的就是向RM申請container,然后配合NM一起來啟動container。就像MRv2一樣,jobclient請求用于MR AM運行的container,設置環境變量和啟動命令,然后交由NM去啟動MR AM,隨后map/reduce task就由MR AM全權負責,當然task的啟動也是由MR AM向RM申請container,然后配合NM一起來啟動的。所以要想在yarn上運行非特定計算框架的程序,我們就得實現自己的client和applicationMaster。另外我們自定義的AM需要放在各個NM的classpath下,因為AM可能運行在任何NM所在的機器上。
原文鏈接:Yarn詳解(責編:Arron)