MapReduce
MapReduce的架構(gòu)
MapReduce是一個(gè)用于大規(guī)模數(shù)據(jù)處理的分布式計(jì)算模型
MapReduce模型主要有Mapper和Reducer兩個(gè)抽象類.
Mapper端主要負(fù)責(zé)對(duì)數(shù)據(jù)的分析處理,最終轉(zhuǎn)化為Key-value的數(shù)據(jù)結(jié)構(gòu)
Reducer端主要是獲取Mapper出來的結(jié)果，對(duì)結(jié)果進(jìn)行統(tǒng)計(jì)
MapReduce實(shí)現(xiàn)存儲(chǔ)的均衡，未實(shí)現(xiàn)計(jì)算的均衡
MapReduce的問題
- JobTracker存在單點(diǎn)故障的隱患。在Yarn中RM實(shí)現(xiàn)了HA。
- JobTracker的職責(zé)多樣，且消耗的資源隨著集群和作業(yè)的數(shù)量增加而增加，更加劇了JobTracker掛掉的風(fēng)險(xiǎn)。
- 代碼復(fù)雜，bug修復(fù)和新增功能難度較大。
- 無法支持更多的計(jì)算模型。
- 資源劃分粒度過大：在 TaskTracker 端，以 map/reduce task 的數(shù)目作為資源的表示過于簡(jiǎn)單，沒有考慮到 cpu/ 內(nèi)存的占用情況，這種基于無類別slot的資源劃分方法的劃分粒度仍過于粗糙，往往會(huì)造成節(jié)點(diǎn)資源利用率過高或者過低 ，比如，管理員事先規(guī)劃好一個(gè)slot代表2GB內(nèi)存和1個(gè)CPU，如果一個(gè)應(yīng)用程序的任務(wù)只需要1GB內(nèi)存，則會(huì)產(chǎn)生“資源碎片”，從而降低集群資源的利用率，同樣，如果一個(gè)應(yīng)用程序的任務(wù)需要3GB內(nèi)存，則會(huì)隱式地?fù)屨计渌蝿?wù)的資源，從而產(chǎn)生資源搶占現(xiàn)象，可能導(dǎo)致集群利用率過高。如果兩個(gè)大內(nèi)存消耗的 task 被調(diào)度到了一塊，很容易出現(xiàn) OOM。
- 資源無法共享：在 TaskTracker 端，把資源強(qiáng)制劃分為 map task slot 和 reduce task slot，且不允許共享。對(duì)于一個(gè)作業(yè)，剛開始運(yùn)行時(shí)，Map slot資源緊缺而Reduce slot空閑，當(dāng)Map Task全部運(yùn)行完成后，Reduce slot緊缺而Map slot空閑。很明顯，這種區(qū)分slot類別的資源管理方案在一定程度上降低了slot的利用率。在Yarn中是分階段獲取資源的，且這個(gè)階段是可以配置的。
- 資源沒有有效的隔離：CPU無法進(jìn)行隔離，應(yīng)用之間產(chǎn)生資源競(jìng)爭(zhēng)，相互干擾影響執(zhí)行效果。
Yarn MapReduce2
Apache Yarn(Yet Another Resource Negotiator) 是Hadoop的新一代集群資源管理系統(tǒng)。最初，Yarn的出現(xiàn)是為了改善之前版本中MapReduce中的缺陷，但是Yarn被設(shè)計(jì)的有足夠的抽象與通用，現(xiàn)在，MapReduce任務(wù)只是Yarn 應(yīng)用中的一種，它還支持Tez、Spark等分布式計(jì)算模式。我們比較熟悉的hive、pig與Yarn并沒有直接的協(xié)作關(guān)系，他們都是運(yùn)行在MapReduce、spark或Tez之上的。
Yarn的架構(gòu)
我們?nèi)匀豢梢哉J(rèn)為它是采用了master/slave的架構(gòu)，主要由以下幾個(gè)部分組成：
- ResourceManager：負(fù)責(zé)Yarn集群的資源管理，任務(wù)的調(diào)度和監(jiān)控。整個(gè)系統(tǒng)只有一個(gè)是live狀態(tài)的（HA的時(shí)候另外一個(gè)是stand狀態(tài)的），它支持可插拔的資源調(diào)度器，自帶了FIFO、Fair Scheduler和Capacity Scheduler三種調(diào)度器；
- ApplicationMaster：負(fù)責(zé)管理單個(gè)應(yīng)用程序，它想RM申請(qǐng)資源，并用這些資源啟動(dòng)內(nèi)部的任務(wù)，同時(shí)負(fù)責(zé)任務(wù)的運(yùn)行監(jiān)控和容錯(cuò)等。
- NodeManager：集群中計(jì)算節(jié)點(diǎn)上的節(jié)點(diǎn)管理器，負(fù)責(zé)單個(gè)節(jié)點(diǎn)上的資源管理和監(jiān)控，它定期將資源的使用情況報(bào)告給RM。并接收ApplicationMaster的命令以啟動(dòng)和回收Container等。
- Container：對(duì)資源的抽象封裝，它按照配置封裝了某個(gè)節(jié)點(diǎn)上的CPU、內(nèi)存等資源，一個(gè)Container既可以是一個(gè)Linux進(jìn)程也可以是一個(gè)cGroup，這取決于具體的配置。
Yarn和MapReduce1的組件比較
| MapReduce1 | Yarn |
|---|---|
| JobTracker | ResourceManager、application master、時(shí)間軸服務(wù)器 |
| TaskTracker | NodeManager |
| Slot | Container |
ResourceManager
它同事包含兩個(gè)組件NodeManagers (NMs) 和 ApplicationMasters (AMs)。
- NodeManagers從RM接收指令并管理單個(gè)節(jié)點(diǎn)上的可用資源。
- ApplicationMasters 與ResourceManager協(xié)調(diào)資源，并與NodeManagers一起啟動(dòng)容器。
- Scheduler: 支持插件，以實(shí)現(xiàn)不同的資源調(diào)度方案。
Yarn的資源管理方案
Yarn丟棄了在MapReduce1中的slot的概念，而是讓ApplicationMaster向RM申請(qǐng)自己需要的資源（比如某個(gè)任務(wù)可申請(qǐng)1.5GB 內(nèi)存和1個(gè)CPU），而調(diào)度器則按照任務(wù)實(shí)際需求為其精細(xì)地分配對(duì)應(yīng)的資源量，不再簡(jiǎn)單的將一個(gè)Slot分配給它，Hadoop 2.0正式采用了這種基于真實(shí)資源量的資源分配方案。
http://dongxicheng.org/mapreduce-nextgen/hadoop-1-and-2-resource-manage/
提交Yarn應(yīng)用程序的過程
- 步驟1：用戶（客戶端）將應(yīng)用程序提交到ResourceManager上，請(qǐng)求允許application master；
-
步驟2：RM找到一個(gè)可以在容器里啟動(dòng)這個(gè)application master的節(jié)點(diǎn)。
- 這里如果能夠完成計(jì)算的話就計(jì)算并返回結(jié)果到客戶端。
- 步驟3：還可以從RM請(qǐng)求更多的容器（資源）。
- 步驟4a和4b：從第步驟3開始，運(yùn)行一個(gè)分布式計(jì)算。
多種計(jì)算框架部署在Yarn上
隨著yarn和各個(gè)計(jì)算框架的發(fā)展，慢慢形成了一種以Yarn為核心的生態(tài)系統(tǒng)，Yarn負(fù)責(zé)管理和監(jiān)控整個(gè)集群的的資源，好處是顯而易見的。
- 應(yīng)用程序的部署將變的簡(jiǎn)單，管理員只需要部署Yarn服務(wù)即可，各類應(yīng)用不需要自帶的服務(wù)，它們?cè)谀承┮饬x上變成了編程庫。Spark集群不需要單獨(dú)部署，直接是Spark-On-Yarn。甚至，我們可以自己寫一些應(yīng)用跑在Yarn上，后面我們會(huì)有spring-yarn的例子。
- 服務(wù)之間是隔離的。Yarn提供的服務(wù)很專業(yè)也很純粹，只是提供資源的管理和監(jiān)控，Yarn上面運(yùn)行什么服務(wù)是由用戶自己決定的。
- 資源的彈性利用，對(duì)提高資源的利用效率有很大幫助，比如離線計(jì)算、實(shí)時(shí)計(jì)算、DAG計(jì)算等。Yarn可以根據(jù)不同類型的應(yīng)用程序壓力情況，調(diào)整對(duì)應(yīng)的資源使用量。
運(yùn)行在Yarn上的計(jì)算框架
下面舉幾個(gè)例子。
- MapReduce-On-YARN：YARN上的離線計(jì)算，YARN發(fā)行版中自帶該實(shí)現(xiàn)；
- Spark-On-YARN：YARN上的內(nèi)存計(jì)算；
- Storm-On-YARN：YARN上的實(shí)時(shí)/流式計(jì)算；
- Tez-On-YARN：YARN上的DAG計(jì)算，我們目前的Hive底層就是用到了這個(gè)計(jì)算框架。
Yarn調(diào)度器
- FIFO調(diào)度器：hadoop默認(rèn)的調(diào)度器，它按照作業(yè)的優(yōu)先級(jí)高低先排序，再按照作業(yè)的先來后到排序執(zhí)行作業(yè)。
- 計(jì)算能力調(diào)度器Capacity Scheduler：它配置了多個(gè)隊(duì)列，每個(gè)隊(duì)列占用集群的一定百分比的資源量，在每個(gè)隊(duì)列內(nèi)部采用FIFO調(diào)度策略，它的缺點(diǎn)在于犧牲了部分資源利用率。
調(diào)度器的一些配置
- 彈性隊(duì)列，單個(gè)作業(yè)的資源一般不會(huì)超過隊(duì)列的總量。如果多個(gè)資源運(yùn)行且當(dāng)前隊(duì)列的資源不夠用了，是可以彈性的使用其他隊(duì)列的資源的；另外，如果下面的選項(xiàng)yarn.scheduler.capacity.<queue-path>.user-limit-factor > 1 則y一個(gè)作業(yè)可以使用超過隊(duì)列總量的資源。
- 隊(duì)列的等待與搶占，自己的隊(duì)列之前是空閑的，然后被被別的隊(duì)列占用了，那么只能是等待占用了這個(gè)資源的應(yīng)用釋放容器資源。還可以是搶占的，但是這樣會(huì)影響作業(yè)的執(zhí)行效率。
- 其他配置，可以配置用戶或者應(yīng)用最多能占用集群資源的多少，以及隊(duì)列的ACL認(rèn)證等。
-
公平調(diào)度器Fair Scheduler
公平調(diào)度器也可以有多隊(duì)列的組合，并且可以給每個(gè)隊(duì)列配置一個(gè)權(quán)重。在隊(duì)列中允許以FIFO的策略執(zhí)行作業(yè)。
公平調(diào)度器與多隊(duì)列
reference:
http://www.itdecent.cn/p/b3afeb1daf3a
http://hadoop.apache.org/docs/r2.4.1/hadoop-yarn/hadoop-yarn-site/YARN.html
http://dongxicheng.org/mapreduce-nextgen/apache-hadoop-yarn-paper-on-socc2013/
