Hadoop——分布式资源管理框架YARN总结
分布式資源管理框架YARN
1. YARN概述
??YARN是“Yet Another Resource Negotiator”的簡(jiǎn)稱。
??在進(jìn)一步了解 YARN 框架之前我們需要知道，相比較而言，MapReduce 則是 YARN 的一個(gè)特例。 YARN 則是 MapReduce 的一個(gè)更加通用和高級(jí)的框架形式，并在其上增加了更多的功能。例如通過(guò)加載分布式執(zhí)行腳本可以在集群節(jié)點(diǎn)上執(zhí)行獨(dú)立的腳本任務(wù)，并且更多功能正在被追加中。
??所以我們可以看到，YARN 可以直接運(yùn)行在 MapReduce 運(yùn)行的框架上而不會(huì)造成更多的干擾，并且會(huì)為集群的運(yùn)算帶來(lái)更多的好處。更一步的開(kāi)發(fā)顯示了 YARN 會(huì)允許開(kāi)發(fā)者根據(jù)自己的需求運(yùn)行不同版的MapReduce 在集群中，這將為開(kāi)發(fā)者提供更為便捷的服務(wù)。
??普遍認(rèn)為，云計(jì)算包括以下幾個(gè)層次的服務(wù): IaaS、PaaS和SaaS。這里所謂的層次，是分層體系架構(gòu)意義上的“層次”。laas. Paas、 Saas分別實(shí)現(xiàn)在基礎(chǔ)設(shè)施層、軟件開(kāi)放運(yùn)行平臺(tái)層、應(yīng)用軟件層。
- IaaS(Infrastructure-as-a-Service):基礎(chǔ)設(shè)施即服務(wù)。消費(fèi)者通過(guò)Internet可以從完善的計(jì)算機(jī)基礎(chǔ)設(shè)施獲得服務(wù)。laas 通過(guò)網(wǎng)絡(luò)向用戶提供計(jì)算機(jī)(物理機(jī)和虛擬機(jī))、存儲(chǔ)空間、網(wǎng)絡(luò)連接、負(fù)載均衡和防火墻等基本計(jì)算資源;用戶在此基礎(chǔ)上部署和運(yùn)行各種軟件，包括操作系統(tǒng)和應(yīng)用程序等。
- PaaS(Platform-as-a-Service):平臺(tái)即服務(wù)。PaaS 是將軟件研發(fā)的平臺(tái)作為一種服務(wù)，以SaaS的模式提交給用戶。平臺(tái)通常包括操作系統(tǒng)、編程語(yǔ)言的運(yùn)行環(huán)境、數(shù)據(jù)庫(kù)和Web服務(wù)器等，用戶可以在平臺(tái)上部署和運(yùn)行自己的應(yīng)用。通常而言，用戶不能管理和控制底層的基礎(chǔ)設(shè)施，只能控制自已部署的應(yīng)用。
- SaaS(Software-as-a-Service):軟件即服務(wù)。它是一種通過(guò)Internet提供軟件的模式，用戶無(wú)需購(gòu)買軟件，而是向提供商租用基于Web的軟件，來(lái)管理企業(yè)經(jīng)營(yíng)活動(dòng)。云提供商在云端安裝和運(yùn)行應(yīng)用軟件，云用戶通過(guò)云客戶端(比如Web瀏覽器)使用軟件。
??從云計(jì)算分層概念上講，YARN可看做PAAS層，它能夠?yàn)椴煌愋偷膽?yīng)用程序提供統(tǒng)一的管理和調(diào)度。
2. YARN 設(shè)計(jì)目標(biāo)
??通用的統(tǒng)一資源管理系統(tǒng)
??同時(shí)運(yùn)行長(zhǎng)應(yīng)用程序和短應(yīng)用程序
- 長(zhǎng)應(yīng)用程序
通常情況下，永不停止運(yùn)行
Service（Spark、Storm）、HTTP Server等 - 短應(yīng)用程序
短時(shí)間（秒級(jí)、分鐘級(jí)、小時(shí)級(jí)）內(nèi)會(huì)運(yùn)行結(jié)束的程序
MR job、Spark Job等
3.Hadoop1 MapReduce (架構(gòu)理解圖)
4. YARN架構(gòu)
關(guān)于上圖架構(gòu) ,主要包括以下幾種角色
ResourceManager(RM)：
??主要接收客戶端任務(wù)請(qǐng)求，接收和監(jiān)控NodeManager(NM)的資源情況匯報(bào)，負(fù)責(zé)資源的分配與調(diào)度，啟動(dòng)和監(jiān)控ApplicationMaster(AM)。
NodeManager：
??主要是節(jié)點(diǎn)上的資源管理，啟動(dòng)Container運(yùn)行task計(jì)算，上報(bào)資源、container情況給RM和任務(wù)處理情況給AM。
ApplicationMaster：
??主要是單個(gè)Application(Job)的task管理和調(diào)度，向RM進(jìn)行資源的申請(qǐng)，向NM發(fā)launch Container指令，接收NM的task處理狀態(tài)信息。
ResourceManager是Yarn的核心, 負(fù)責(zé)調(diào)度Application master, 來(lái)給每個(gè)NodeManager分配資源, 資源儲(chǔ)存在Container中, 此處的資源包括JVM,內(nèi)存等, 然后將程序copy到container中運(yùn)行, container還需要回報(bào)狀態(tài)給App master, 再有app master匯報(bào)給Resource manager, nodeManager也要按時(shí)匯報(bào)ResourceManager當(dāng)前節(jié)點(diǎn)的資源使用情況.
下面簡(jiǎn)單介紹以下提交一個(gè)job的處理過(guò)程
1、client submit一個(gè)job到RM，進(jìn)入RM中的Scheduler隊(duì)列供調(diào)度(Scheduler負(fù)責(zé)申請(qǐng)資源)
2、RM根據(jù)NM匯報(bào)的資源情況(NM會(huì)定時(shí)匯報(bào)資源和container使用情況)，請(qǐng)求一個(gè)合適的NM launch container，以啟動(dòng)運(yùn)行AM
3、AM啟動(dòng)后，注冊(cè)到RM上，以使client可以查到AM的信息，便于client直接和AM通信
4、AM啟動(dòng)后，根據(jù)Job 相關(guān)的split的task情況，會(huì)和RM協(xié)商申請(qǐng)container資源
5、RM分配給AM container資源后，根據(jù)container的信息，向?qū)?yīng)的NM 請(qǐng)求launch container
6、NM啟動(dòng)container運(yùn)行task，運(yùn)行過(guò)程中向AM匯報(bào)進(jìn)度狀態(tài)信息，類似于MRv1中 task的匯報(bào)；同時(shí)NM也會(huì)定時(shí)的向RM匯報(bào)container的使用情況。
7、在application(job)執(zhí)行過(guò)程中，client可以和AM通信，獲取application相關(guān)的進(jìn)度和狀態(tài)信息。
8、在application(job)完成后，AM通知RM clear自己的相關(guān)信息，并關(guān)閉，釋放自己占用的container。
5.YARN調(diào)度管理
yarn分為一級(jí)調(diào)度管理和二級(jí)調(diào)度管理
- 一級(jí)調(diào)度管理 (更近底層,更接近于操作資源, 更偏向于應(yīng)用層和底層結(jié)合)
計(jì)算資源管理(cpu,內(nèi)存等,計(jì)算復(fù)雜消耗的cpu多)
App生命周期管理 - 二級(jí)調(diào)度管理 (自己代碼的算法等, 更偏向于應(yīng)用層)
App內(nèi)部的計(jì)算模型管理
多樣化的計(jì)算模型
6. YARN 服務(wù)組件
- 組件： Client、 runjar 、 MRAppMaster、ResourceManager、Application Master NodeManager、Container yarnchild
- container 容器 （1.啟動(dòng) appmaster 2.container 列表 yarnchild）
- 其他組件
YARN 總體上仍然是Master/Slave(主/從) 結(jié)構(gòu)，在整個(gè)資源管理框架中，ResourceManager 為主Master ，NodeManager 為從Slave。
ResourceManager：
??負(fù)責(zé)對(duì)各個(gè)NodeManager 上的資源進(jìn)行統(tǒng)一管理和調(diào)度（自身的資源使用情況 自身的運(yùn)行情況 以及所給的命令）
RM: 從不主動(dòng) 通過(guò)心跳來(lái)完成 （1NM 報(bào)活 2RM 下達(dá)命令）
??當(dāng)用戶提交一個(gè)應(yīng)用程序時(shí)，需要提供一個(gè)用以跟蹤和管理這個(gè)程序的AM ApplicationMaster，它負(fù)責(zé)向ResourceManager 申請(qǐng)資源，并要求NodeManger啟動(dòng)container。
appMaster–RM–NM–container
application-specific協(xié)議（AM–yarnChild ）
am在通知nodemanager啟動(dòng)container的時(shí)候container-launch-specification
由于不同的ApplicationMaster 被分布到不同的節(jié)點(diǎn)上，因此它們之間不會(huì)相互影響
ResourceManager全局的資源管理器，整個(gè)集群只有一個(gè)，負(fù)責(zé)集群資源的統(tǒng)一管理和調(diào)度分配。
功能 :處理客戶端請(qǐng)求runjar client獲取AM
- 啟動(dòng)/監(jiān)控ApplicationMaster
- RM 啟動(dòng)第一個(gè)container（先啟動(dòng)appmaster ）AM 再次與RM 申請(qǐng)資源
- 監(jiān)控NodeManager （注意只能監(jiān)聽(tīng)容器和整臺(tái)機(jī)器的資源使用情況 不能查看具體的任務(wù)）
資源分配與調(diào)度
第一個(gè)容器在啟動(dòng)（AM） container-launch-specification
容器運(yùn)行 AM–yarnchild application-specific
Application Master
管理一個(gè)在YARN 內(nèi)運(yùn)行的應(yīng)用程序的每個(gè)實(shí)例，這個(gè)應(yīng)用在每個(gè)container中的進(jìn)程都交給AM管理
mr在運(yùn)行的時(shí)候 – 申請(qǐng)am — 申請(qǐng)子資源 — 返回容器的列表 – 機(jī)器的資源使用情況 — 節(jié)點(diǎn)數(shù)據(jù)
功能
- 數(shù)據(jù)切分 （找尋數(shù)據(jù)在哪個(gè)節(jié)點(diǎn)上，并且在這個(gè)節(jié)點(diǎn)上啟動(dòng)container）
- 為應(yīng)用程序申請(qǐng)資源，并進(jìn)一步分配給內(nèi)部任務(wù)
- 任務(wù)監(jiān)控與容錯(cuò)（yarnchild 宕機(jī) appmaster能夠監(jiān)聽(tīng)1到 再去申請(qǐng)啟動(dòng)）
- 負(fù)責(zé)協(xié)調(diào)來(lái)自ResourceManager的資源，幵通過(guò)NodeManager監(jiān)視容器的執(zhí)行和資源使用（CPU、內(nèi)存等的資源分配）。
NodeManager
整個(gè)集群有多個(gè)，負(fù)責(zé)單節(jié)點(diǎn)資源管理和使用
功能
- 單個(gè)節(jié)點(diǎn)上的資源管理和任務(wù)管理（監(jiān)控生命周期）
- 處理來(lái)自ResourceManager的命令（分配資源的命令）
- 處理來(lái)自ApplicationMaster的命令（啟動(dòng)容器的命令）
ApplicationManager container —> NodeManager
NodeManager管理抽象容器，這些容器代表著可供一個(gè)特定應(yīng)用程序使用的針對(duì)每個(gè)節(jié)點(diǎn)的資源。yarnchild
定時(shí)地向RM匯報(bào)本節(jié)點(diǎn)上的資源使用情況和各個(gè)Container的運(yùn)行狀態(tài)。(心跳機(jī)制匯報(bào))
Container
YARN中的資源抽象，封裝某個(gè)節(jié)點(diǎn)上多維度資源，如內(nèi)存、CPU、磁盤、網(wǎng)絡(luò)等，當(dāng)AM向RM申請(qǐng)資源時(shí)，RM向AM返回的資源便是用Container表示的。
YARN 會(huì)為每個(gè)任務(wù)分配一個(gè)Container，且該任務(wù)只能使用該Container中描述的資源。
功能
- 對(duì)任務(wù)運(yùn)行環(huán)境的抽象
- 描述一系列信息
- 任務(wù)運(yùn)行資源（節(jié)點(diǎn)、內(nèi)存、CPU）
- 任務(wù)啟動(dòng)命令
- 任務(wù)運(yùn)行環(huán)境
JobHistoryServer
??JobHistoryServer(將各個(gè)容器中的日志合并在一起展示 mr運(yùn)行結(jié)果之后 進(jìn)行合并結(jié)果日志的一個(gè)進(jìn)程)、只是適用于mr框架，作業(yè)歷史服務(wù),記錄歷史情況 , 通過(guò)mr-jobhistory-daemon.sh start historyserver 來(lái)啟動(dòng), 啟動(dòng)成功會(huì)出現(xiàn)JobHistoryServer進(jìn)程 , 并且可以從19888端口進(jìn)行查看日志詳細(xì)信息
TimelineServer
??通用的日志服務(wù)器
??用來(lái)寫日志服務(wù)數(shù)據(jù) , 一般來(lái)寫與第三方結(jié)合的日志服務(wù)數(shù)據(jù)(比如spark等) 所有計(jì)算框架的日志合并
7.YARN 優(yōu)勢(shì)
更快地MapReduce計(jì)算
??YARN利用異步模型對(duì)MapReduce框架的一些關(guān)鍵邏輯結(jié)構(gòu)（如JobInprogress、TaskInProgress等）進(jìn)行了重寫，相比于MRv1，具有更快地計(jì)算速度。
對(duì)多框架支持
?? YARN不再是一個(gè)單純的計(jì)算框架，而是一個(gè)框架管理器，用戶可以將各種各樣的計(jì)算框架移植到Y(jié)ARN之上。
框架升級(jí)更容易
??在YARN中，各種計(jì)算框架不再是作為一個(gè)服務(wù)部署到集群的各個(gè)節(jié)點(diǎn)上（比如MapReduce框架，不再需要部署JobTracler、TaskTracker等服務(wù)），而是被封裝成一個(gè)用戶程序庫(kù)（lib）存放在客戶端，當(dāng)需要對(duì)計(jì)算框架進(jìn)行升級(jí)時(shí)，只需升級(jí)用戶程序庫(kù)即可。
8.YARN 工作流程
??當(dāng)用戶向YARN中提交一個(gè)應(yīng)用程序后，YARN將分兩個(gè)階段運(yùn)行該應(yīng)用程序
- 第一個(gè)階段是啟動(dòng)ApplicationMaster；
- 第二個(gè)階段是由ApplicationMaster創(chuàng)建應(yīng)用程序，為它申請(qǐng)資源，并監(jiān)控它的整個(gè)運(yùn)行過(guò)程，直到運(yùn)行完成
- 在整個(gè)工作流程當(dāng)中，ResourceManager和NodeManager都是通過(guò)心跳保持聯(lián)系的，NodeManager會(huì)通過(guò)心跳信息向ResourceManager匯報(bào)自己所在節(jié)點(diǎn)的資源使用情況。
9.YARN通信協(xié)議
??RPC協(xié)議是連接各個(gè)組件的“大動(dòng)脈”，了解不同組件之間的RPC協(xié)議有助于我們更深人地學(xué)習(xí)YARN框架。在YARN中，任何兩個(gè)需相互通信的組件之間僅有一個(gè)RPC協(xié)議，面對(duì)于任何一個(gè)RPC協(xié)議，通信雙方有一端是Client, 另一端為Server, 且Client總是主動(dòng)連接 Server的，因此，YARN實(shí)際上采用的是拉式(ull-based) 通信模型。如下圖所示，箭頭指向的組件是RPC Server, 而箭頭尾部的組件是RPC Client,
YARN主要由以下幾個(gè)RPC協(xié)議組成:
??(1)JobClient(作業(yè)提交客戶端)與RM之間的協(xié)議—ApplicationClientProtocol
JobClient通過(guò)該RPC協(xié)議提交應(yīng)用程序、查詢應(yīng)用程序狀態(tài)等。
??(2)Admin(管理員)與RM之間的通信協(xié)議----ResourceManagerAdministrationProtocol:
Admin通過(guò)該RPC協(xié)議更新系統(tǒng)配置文件，比如節(jié)點(diǎn)黑白名單、用戶隊(duì)列權(quán)限等。
??(3)AM與RM之間的協(xié)議一ApplicationMasterProtocol: AM通過(guò)該RPC協(xié)議向RM注冊(cè)和撒銷自己，并為各個(gè)任務(wù)申請(qǐng)資源。
??(4)AM與NM之間的協(xié)議一-ContainerManagementProtocol: AM通過(guò)該RPC要求NM啟動(dòng)或者停止Container,獲取各個(gè)Container的使用狀態(tài)等信息。
??(5)NM與RM之間的協(xié)議一-ResuceTracker: NM通過(guò)該RPC協(xié)議向RM注冊(cè)，并定時(shí)發(fā)送心跳信息匯報(bào)當(dāng)前節(jié)點(diǎn)的資源使用情況和Container運(yùn)行情況。
10.YARN資源管理
?? 資源調(diào)度和資源隔離是YARN作為一個(gè)資源管理系統(tǒng)，最重要和最基礎(chǔ)的兩個(gè)功能。資源調(diào)度由ResourceManager完成，而資源隔離由各個(gè)NM實(shí)現(xiàn)。
??ResourceManager將某個(gè)NodeManager上資源分配給任務(wù)（這就是所謂的“資源調(diào)度”）后，NodeManager需按照要求為任務(wù)提供相應(yīng)的資源，甚至保證這些資源應(yīng)具有獨(dú)占性，為任務(wù)運(yùn)行提供基礎(chǔ)的保證，這就是所謂的資源隔離。
??當(dāng)談及到資源時(shí)，我們通常指內(nèi)存，CPU和IO三種資源。Hadoop YARN同時(shí)支持內(nèi)存和CPU兩種資源的調(diào)度。
??內(nèi)存資源的多少會(huì)會(huì)決定任務(wù)的生死，如果內(nèi)存不夠，任務(wù)可能會(huì)運(yùn)行失敗；相比之下，CPU資源則不同，它只會(huì)決定任務(wù)運(yùn)行的快慢，不會(huì)對(duì)生死產(chǎn)生影響。
??YARN允許用戶配置每個(gè)節(jié)點(diǎn)上可用的物理內(nèi)存資源，注意，這里是“可用的”，因?yàn)橐粋€(gè)節(jié)點(diǎn)上的內(nèi)存會(huì)被若干個(gè)服務(wù)共享，比如一部分給YARN，一部分給HDFS，一部分給HBase等，
YARN配置的只是自己可以使用的，配置參數(shù)如下：
?? (1) yarn.nodemanager.resource.memory-mb
表示該節(jié)點(diǎn)上YARN可使用的物理內(nèi)存總重，默認(rèn)是8192(MB)，注意，如果你的節(jié)點(diǎn)內(nèi)存資源不夠8CB,則懦要調(diào)減這個(gè)值，而YARN不會(huì)智能的探測(cè)節(jié)點(diǎn)的物理內(nèi)存總里。
?? (2) yarn.nodemanager.vmem-pmem-ratio
任務(wù)每使用1MB物理內(nèi)存，最多可使用虛擬內(nèi)存里，默認(rèn)是2.1.
?? (3) yarn.nodemanager.pmem-check-enabled
是否啟動(dòng)一個(gè)線程檢查每個(gè)任務(wù)正使用的物理內(nèi)存里，如果任務(wù)超出分配值，則直接將其殺掉，默認(rèn)是true
?? (4) yarn.nodemanager.vmem-check-enabled
是否啟動(dòng)一個(gè)線程檢查每個(gè)任務(wù)正使用的虛擬內(nèi)存里，如果任務(wù)超出分配值，則直接將其殺掉，默認(rèn)是true
?? (5) yarn.scheduler.minimum-allocation-mb
單個(gè)任務(wù)可申請(qǐng)的最少物理內(nèi)存里，默認(rèn)是1024(MB)，如果一個(gè)任務(wù)申請(qǐng)的物理內(nèi)存重少于該值，則該對(duì)應(yīng)的值改這個(gè)數(shù)。
?? (6) yarn.scheduler.maximum-allocation-mb
單個(gè)任務(wù)可申請(qǐng)的最多物理內(nèi)存里，默認(rèn)是8192(MB)。
?? 默認(rèn)情況下，YARN采用了線程監(jiān)控的方法判斷任務(wù)是否超量使用內(nèi)存，一旦發(fā)現(xiàn)超量，則直接將其殺死。由于Cgroups對(duì)內(nèi)存的控制缺乏靈活性（即任務(wù)任何時(shí)刻不能超過(guò)內(nèi)存上限，如果超過(guò)，則直接將其殺死或者報(bào)OOM），而Java進(jìn)程在創(chuàng)建瞬間內(nèi)存將翻倍，之后驟降到正常值，這種情況下，采用線程監(jiān)控的方式更加靈活（當(dāng)發(fā)現(xiàn)進(jìn)程樹(shù)內(nèi)存瞬間翻倍超過(guò)設(shè)定值時(shí)，可認(rèn)為是正?，F(xiàn)象，不會(huì)將任務(wù)殺死），因此YARN未提供Cgroups內(nèi)存隔離機(jī)制。
?? 目前的CPU被劃分成虛擬CPU（CPU virtual Core），這里的虛擬CPU是YARN自己引入的概念，初衷是，考慮到不同節(jié)點(diǎn)的CPU性能可能不同，每個(gè)CPU具有的計(jì)算能力也是不一樣的，比如某個(gè)物理CPU的計(jì)算能力可能是另外一個(gè)物理CPU的2倍，這時(shí)候，你可以通過(guò)為第一個(gè)物理CPU多配置幾個(gè)虛擬CPU彌補(bǔ)這種差異。用戶提交作業(yè)時(shí)，可以指定每個(gè)任務(wù)需要的虛擬CPU個(gè)數(shù)。在YARN中，CPU相關(guān)配置參數(shù)如下：
?? (1) yarn.nodemanager.resource.cpu-vcores
表示該節(jié)點(diǎn)上YARN可使用的虛擬CPU個(gè)數(shù), 默認(rèn)是8.注意.目前推薦將該值設(shè)為與物理CPU核數(shù)數(shù)目相同,如果你的節(jié)點(diǎn)CPU核數(shù)不8個(gè),則懦要調(diào)小這個(gè)值,而YARN不會(huì)智能的探測(cè)點(diǎn)物理CPU總數(shù).
?? (2) yarn.scheduler.minimum-allocation-vcores
單個(gè)任務(wù)可申請(qǐng)的最小虛擬cpu個(gè)數(shù)默認(rèn)是1, 如果一個(gè)任務(wù)申請(qǐng)的CPU個(gè)數(shù)少于該數(shù).則該對(duì)應(yīng)的值改為這個(gè)數(shù).
?? (3) yarn.scheduler.maximum-allocation-vcores
單個(gè)任務(wù)可申請(qǐng)的最多虛擬CPU個(gè)數(shù),默認(rèn)是32。
12、AM與RM的詳細(xì)交互
?? 用戶向YARN ResourceManager提交應(yīng)用程序，RM收到提交申請(qǐng)后，先向資源調(diào)度器申請(qǐng)用以啟動(dòng)AM 的資源，待申請(qǐng)到資源后，再由ApplicationMasterLauncher與對(duì)應(yīng)的NodeManager通信，從而啟動(dòng)應(yīng)用程序的ApplicationMaster。
?? ApplicationMaster啟動(dòng)完成后，ApplicationMasterLaucher會(huì)通過(guò)事件的形式，將剛剛啟動(dòng)的Application Master注冊(cè)到AMLiveMonitor，以啟動(dòng)心跳監(jiān)控。
?? ApplicationMaster啟動(dòng)后，先向ApplicatinMaterService注冊(cè)，并將自己所在host、端口號(hào)等信息匯報(bào)給它。
?? AM運(yùn)行過(guò)程中，周期性地向ApplicationMaserService回報(bào)心跳信息（信息中包含想要申請(qǐng)的資源描述）。
?? ApplicationMasterService每次收到ApplicationMaster心跳信息好后，將通知AMLivelinessMonitor更新應(yīng)用程序的最新回報(bào)心跳的時(shí)間。
?? 應(yīng)用程序運(yùn)行完成后，AM向AMService發(fā)送請(qǐng)求，注銷自己。
?? AMService收到注銷請(qǐng)求后，標(biāo)注應(yīng)用程序運(yùn)行狀態(tài)完成，同時(shí)通知 AMLivelinessMonitor移除對(duì)它的心跳監(jiān)控。
13.YARN 核心組件
14.Hadoop 發(fā)行版本
- Apache Hadoop
- Cloudera — CDH
- Hortonworks — HDP
- MapR
- EMC、IBM
- Intel、華為
- 其他
Cloudera Hadoop
?? 2008 年成立的 Cloudera 是最早將 Hadoop 商用的公司，為合作伙伴提供 Hadoop 的商用解決方案，主要是包括支持，咨詢服務(wù)，培訓(xùn)。
2009年Hadoop的創(chuàng)始人 Doug Cutting也加盟 Cloudera公司。Cloudera 產(chǎn)品主要為CDH，Cloudera Manager，Cloudera Support
CDH是Cloudera的Hadoop發(fā)行版，完全開(kāi)源，比Apache Hadoop在兼容性，安全性，穩(wěn)定性上有所增強(qiáng)。
?? Cloudera Manager是集群的軟件分發(fā)及管理監(jiān)控平臺(tái)，可以在幾個(gè)小時(shí)內(nèi)部署好一個(gè)Hadoop集群，并對(duì)集群的節(jié)點(diǎn)及服務(wù)進(jìn)行實(shí)時(shí)監(jiān)控。Cloudera Support即是對(duì)Hadoop的技術(shù)支持。
?? Cloudera 的標(biāo)價(jià)為每年每個(gè)節(jié)點(diǎn)4000美元。Cloudera開(kāi)發(fā)并貢獻(xiàn)了可實(shí)時(shí)處理大數(shù)據(jù)的Impala項(xiàng)目。
16.Hortonworks Hadoop
?? 2011年成立的Hortonworks是雅虎與硅谷風(fēng)投公司Benchmark Capital合資組建的公司
?? 公司成立之初就吸納了大約25名至30名專門研究Hadoop的雅虎工程師，上述工程師均在2005年開(kāi)始協(xié)助雅虎開(kāi)發(fā)Hadoop，這些工程師貢獻(xiàn)了Hadoop 80%的代碼。
雅虎工程副總裁、雅虎Hadoop開(kāi)發(fā)團(tuán)隊(duì)負(fù)責(zé)人Eric Baldeschwieler出任Hortonworks的首席執(zhí)行官。
?? Hortonworks 的主打產(chǎn)品是Hortonworks Data Platform (HDP)，也同樣是100%開(kāi)源的產(chǎn)品，HDP除了常見(jiàn)的項(xiàng)目外還包含了Ambari，一款開(kāi)源的安裝和管理系統(tǒng)。
?? HCatalog，一個(gè)元數(shù)據(jù)管理系統(tǒng)，HCatalog現(xiàn)已集成到Facebook 開(kāi)源的Hive中。Hortonworks的Stinger開(kāi)創(chuàng)性地極大地優(yōu)化了Hive項(xiàng)目。Hortonworks為入門提供了一個(gè)非常好的，易于使用的沙盒。
?? Hortonworks開(kāi)發(fā)了很多增強(qiáng)特性并提交至核心主干，這使得Apache Hadoop能夠在包括Windows Server和Windows Azure在內(nèi)的Microsoft Windows平臺(tái)上本地運(yùn)行。定價(jià)以集群為基礎(chǔ)，每10個(gè)節(jié)點(diǎn)每年為12500美元。
17.MapR Hadoop
?? 2009年成立的MapR公司在Hadoop領(lǐng)域顯得有點(diǎn)特立獨(dú)行，它提供了一款獨(dú)特的發(fā)行版 。
?? Hadoop在性能(在Hadoop1.X及其之前的設(shè)計(jì)中，所有的meta data操作都要通過(guò)集中式的NameNode來(lái)進(jìn)行，NameNode有可能是性能的瓶頸;M/R 應(yīng)用程序需要通過(guò)NameNode來(lái)訪問(wèn)HDFS, 這就涉及到額外的進(jìn)程切換和網(wǎng)絡(luò)傳輸開(kāi)銷)，可用性與擴(kuò)展性(NameNode，JobTracker單點(diǎn)問(wèn)題)，企業(yè)級(jí)應(yīng)用上的弱點(diǎn)(比如完全可讀寫的文件系統(tǒng)，snapshot，mirror等等)各大廠商均知，MapR則認(rèn)為，Hadoop的這些缺陷來(lái)自于其架構(gòu)設(shè)計(jì)本身，小修小補(bǔ)不能解決問(wèn)題。
?? 他們選擇了一條艱難得多的路： 用新架構(gòu)重寫HDFS，同時(shí)在API級(jí)別，和目前的Hadoop 發(fā)行版保持兼容。這家2009年成立的創(chuàng)業(yè)公司，在蟄伏了兩年之后，終于一鳴驚人，大放異彩。
?? 成功實(shí)現(xiàn)了“構(gòu)建一個(gè)HDFS的私有替代品，這個(gè)替代品比當(dāng)前的開(kāi)源版本快三倍，自帶快照功能，而且支持無(wú)NameNode單點(diǎn)故障(SPOF)，并且在API上和開(kāi)源版兼容，所以可以考慮將其作為替代方案”。
?? MapR版本不再需要單獨(dú)的NameNode機(jī)器，元數(shù)據(jù)分散在集群中，也類似數(shù)據(jù)默認(rèn)存儲(chǔ)三份，正如OpenStack對(duì)象存儲(chǔ)系統(tǒng)Swift的設(shè)計(jì)。
?? 也不再需要用網(wǎng)絡(luò)附加存儲(chǔ)(NAS)來(lái)協(xié)助NameNode做元數(shù)據(jù)備份，提高了機(jī)器使用率。還有個(gè)重要的特點(diǎn)是可以使用nfs直接訪問(wèn)hdfs，提供了與舊有應(yīng)用的兼容性
鏡像功能也很適合做數(shù)據(jù)備份，而且支持跨數(shù)據(jù)中心的鏡像，快照功能對(duì)于數(shù)據(jù)的恢復(fù)作用明顯。MapR還領(lǐng)導(dǎo)著Apache Drill項(xiàng)目，該項(xiàng)目是Google Dremel的開(kāi)源實(shí)現(xiàn)，目的是在Hadoop上執(zhí)行類似SQL的交互實(shí)時(shí)查詢。
?? MapR有免費(fèi)和商業(yè)兩個(gè)版本，免費(fèi)版本在功能上有所縮減。據(jù)報(bào)道MapR標(biāo)價(jià)也為每年每個(gè)節(jié)點(diǎn)4000美元。
Intel和華為等發(fā)行 Hadoop
?? Intel的商業(yè)版本，主要是強(qiáng)調(diào)其能提供全面的軟硬件解決方案設(shè)計(jì)，針對(duì)硬件具有更好的性能優(yōu)化，以及提供集群管理工具和安裝工具簡(jiǎn)化了 Hadoop 的安裝和配置，能夠提供項(xiàng)目規(guī)劃到實(shí)施各階段專業(yè)的咨詢服務(wù)，實(shí)際中采購(gòu)Intel版本貌似動(dòng)力不足。
華為在硬件上具有天然的優(yōu)勢(shì)，在網(wǎng)絡(luò)，虛擬化，PC機(jī)等都有很強(qiáng)的硬件實(shí)力。華為的 ?? FusionInsight Hadoop版本基于Apache Hadoop，構(gòu)建NameNode、 JobTracker、HiveServer的HA功能，進(jìn)程故障后系統(tǒng)自動(dòng)Failover，無(wú)需人工干預(yù)，這個(gè)也是對(duì)Hadoop的小修補(bǔ)，遠(yuǎn)不如MapR解決的徹底。華為在Hadoop社區(qū)中的Contributor和Committer也是國(guó)內(nèi)最多的，算是國(guó)內(nèi)技術(shù)實(shí)力較強(qiáng)的公司。
?? Microsoft和Hortonworks相互合作，特別是合作將Apache Hadoop引入到Windows Server操作系統(tǒng)和Windows Azure云服務(wù)中。
?? Oracle通過(guò)將自己的軟硬件與Cloudera的Apache Hadoop發(fā)行版本結(jié)合到一起，提供一個(gè)大數(shù)據(jù)應(yīng)用產(chǎn)品。
?? 像SAP、Talend這樣的軟件提供商則同時(shí)支持幾個(gè)不同的發(fā)行版本。
總結(jié)
以上是生活随笔為你收集整理的Hadoop——分布式资源管理框架YARN总结的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： mysql8.0数据源配置
- 下一篇： HDFS中常用的shell命令总结