MapReduce

MapReduce的架構(gòu)

MapReduce是一個(gè)用于大規(guī)模數(shù)據(jù)處理的分布式計(jì)算模型
MapReduce模型主要有Mapper和Reducer兩個(gè)抽象類(lèi).
Mapper端主要負(fù)責(zé)對(duì)數(shù)據(jù)的分析處理,最終轉(zhuǎn)化為Key-value的數(shù)據(jù)結(jié)構(gòu)
Reducer端主要是獲取Mapper出來(lái)的結(jié)果欠啤，對(duì)結(jié)果進(jìn)行統(tǒng)計(jì)
MapReduce實(shí)現(xiàn)存儲(chǔ)的均衡萌壳，未實(shí)現(xiàn)計(jì)算的均衡

MapReduce的問(wèn)題

• JobTracker存在單點(diǎn)故障的隱患毁腿。在Yarn中RM實(shí)現(xiàn)了HA。
• JobTracker的職責(zé)多樣廓脆，且消耗的資源隨著集群和作業(yè)的數(shù)量增加而增加，更加劇了JobTracker掛掉的風(fēng)險(xiǎn)磁玉。
• 代碼復(fù)雜停忿，bug修復(fù)和新增功能難度較大。
• 無(wú)法支持更多的計(jì)算模型蚊伞。
• 資源劃分粒度過(guò)大：在 TaskTracker 端席赂，以 map/reduce task 的數(shù)目作為資源的表示過(guò)于簡(jiǎn)單，沒(méi)有考慮到 cpu/ 內(nèi)存的占用情況厚柳，這種基于無(wú)類(lèi)別slot的資源劃分方法的劃分粒度仍過(guò)于粗糙氧枣，往往會(huì)造成節(jié)點(diǎn)資源利用率過(guò)高或者過(guò)低 ，比如别垮，管理員事先規(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)致集群利用率過(guò)高龙填。如果兩個(gè)大內(nèi)存消耗的 task 被調(diào)度到了一塊胳泉，很容易出現(xiàn) OOM拐叉。
• 資源無(wú)法共享：在 TaskTracker 端，把資源強(qiáng)制劃分為 map task slot 和 reduce task slot扇商，且不允許共享凤瘦。對(duì)于一個(gè)作業(yè)，剛開(kāi)始運(yùn)行時(shí)案铺，Map slot資源緊缺而Reduce slot空閑蔬芥，當(dāng)Map Task全部運(yùn)行完成后，Reduce slot緊缺而Map slot空閑控汉。很明顯笔诵，這種區(qū)分slot類(lèi)別的資源管理方案在一定程度上降低了slot的利用率。在Yarn中是分階段獲取資源的姑子，且這個(gè)階段是可以配置的乎婿。
• 資源沒(méi)有有效的隔離：CPU無(wú)法進(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并沒(méi)有直接的協(xié)作關(guān)系，他們都是運(yùn)行在MapReduce鳞上、spark或Tez之上的这吻。

Yarn應(yīng)用

Yarn的架構(gòu)

Yarn架構(gòu)

我們?nèi)匀豢梢哉J(rèn)為它是采用了master/slave的架構(gòu)，主要由以下幾個(gè)部分組成：

1. 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)度器；
2. ApplicationMaster：負(fù)責(zé)管理單個(gè)應(yīng)用程序这难，它想RM申請(qǐng)資源舟误，并用這些資源啟動(dòng)內(nèi)部的任務(wù)，同時(shí)負(fù)責(zé)任務(wù)的運(yùn)行監(jiān)控和容錯(cuò)等姻乓。
3. NodeManager：集群中計(jì)算節(jié)點(diǎn)上的節(jié)點(diǎn)管理器嵌溢，負(fù)責(zé)單個(gè)節(jié)點(diǎn)上的資源管理和監(jiān)控眯牧，它定期將資源的使用情況報(bào)告給RM。并接收ApplicationMaster的命令以啟動(dòng)和回收Container等赖草。
4. Container：對(duì)資源的抽象封裝炸站，它按照配置封裝了某個(gè)節(jié)點(diǎn)上的CPU、內(nèi)存等資源疚顷，一個(gè)Container既可以是一個(gè)Linux進(jìn)程也可以是一個(gè)cGroup，這取決于具體的配置禁偎。

Yarn和MapReduce1的組件比較

ResourceManager

它同事包含兩個(gè)組件NodeManagers (NMs) 和 ApplicationMasters (AMs)如暖。

1. NodeManagers從RM接收指令并管理單個(gè)節(jié)點(diǎn)上的可用資源笆檀。
2. ApplicationMasters 與ResourceManager協(xié)調(diào)資源，并與NodeManagers一起啟動(dòng)容器盒至。
3. Scheduler: 支持插件酗洒，以實(shí)現(xiàn)不同的資源調(diào)度方案。

ResourceManager

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)用程序的過(guò)程

• 步驟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開(kāi)始癞蚕，運(yùn)行一個(gè)分布式計(jì)算。

yarn應(yīng)用的啟動(dòng)

多種計(jì)算框架部署在Yarn上

隨著yarn和各個(gè)計(jì)算框架的發(fā)展辉哥，慢慢形成了一種以Yarn為核心的生態(tài)系統(tǒng)桦山，Yarn負(fù)責(zé)管理和監(jiān)控整個(gè)集群的的資源，好處是顯而易見(jiàn)的证薇。

1. 應(yīng)用程序的部署將變的簡(jiǎn)單度苔，管理員只需要部署Yarn服務(wù)即可，各類(lèi)應(yīng)用不需要自帶的服務(wù)浑度，它們?cè)谀承┮饬x上變成了編程庫(kù)寇窑。Spark集群不需要單獨(dú)部署，直接是Spark-On-Yarn箩张。甚至甩骏，我們可以自己寫(xiě)一些應(yīng)用跑在Yarn上窗市，后面我們會(huì)有spring-yarn的例子。
2. 服務(wù)之間是隔離的饮笛。Yarn提供的服務(wù)很專(zhuān)業(yè)也很純粹咨察，只是提供資源的管理和監(jiān)控，Yarn上面運(yùn)行什么服務(wù)是由用戶自己決定的福青。
3. 資源的彈性利用摄狱，對(duì)提高資源的利用效率有很大幫助，比如離線計(jì)算无午、實(shí)時(shí)計(jì)算媒役、DAG計(jì)算等。Yarn可以根據(jù)不同類(lèi)型的應(yīng)用程序壓力情況宪迟，調(diào)整對(duì)應(yīng)的資源使用量酣衷。

運(yùn)行在Yarn上的計(jì)算框架

下面舉幾個(gè)例子。

1. MapReduce-On-YARN：YARN上的離線計(jì)算次泽，YARN發(fā)行版中自帶該實(shí)現(xiàn)穿仪；
2. Spark-On-YARN：YARN上的內(nèi)存計(jì)算；
3. Storm-On-YARN：YARN上的實(shí)時(shí)/流式計(jì)算意荤；
4. Tez-On-YARN：YARN上的DAG計(jì)算啊片，我們目前的Hive底層就是用到了這個(gè)計(jì)算框架。

Yarn調(diào)度器

1. FIFO調(diào)度器：hadoop默認(rèn)的調(diào)度器袭异，它按照作業(yè)的優(yōu)先級(jí)高低先排序钠龙，再按照作業(yè)的先來(lái)后到排序執(zhí)行作業(yè)。
2. 計(jì)算能力調(diào)度器Capacity Scheduler：它配置了多個(gè)隊(duì)列御铃，每個(gè)隊(duì)列占用集群的一定百分比的資源量碴里，在每個(gè)隊(duì)列內(nèi)部采用FIFO調(diào)度策略，它的缺點(diǎn)在于犧牲了部分資源利用率上真。

調(diào)度器的一些配置

應(yīng)用允許的占用最大資源率

• 彈性隊(duì)列咬腋，單個(gè)作業(yè)的資源一般不會(huì)超過(guò)隊(duì)列的總量。如果多個(gè)資源運(yùn)行且當(dāng)前隊(duì)列的資源不夠用了睡互，是可以彈性的使用其他隊(duì)列的資源的根竿；另外，如果下面的選項(xiàng)yarn.scheduler.capacity.<queue-path>.user-limit-factor > 1 則y一個(gè)作業(yè)可以使用超過(guò)隊(duì)列總量的資源就珠。
• 隊(duì)列的等待與搶占寇壳，自己的隊(duì)列之前是空閑的，然后被被別的隊(duì)列占用了妻怎，那么只能是等待占用了這個(gè)資源的應(yīng)用釋放容器資源壳炎。還可以是搶占的，但是這樣會(huì)影響作業(yè)的執(zhí)行效率逼侦。
• 其他配置匿辩，可以配置用戶或者應(yīng)用最多能占用集群資源的多少腰耙，以及隊(duì)列的ACL認(rèn)證等。

用戶限制

3. 公平調(diào)度器Fair Scheduler
   公平調(diào)度器也可以有多隊(duì)列的組合铲球，并且可以給每個(gè)隊(duì)列配置一個(gè)權(quán)重挺庞。在隊(duì)列中允許以FIFO的策略執(zhí)行作業(yè)。
   
   公平調(diào)度器與多隊(duì)列

Yarn上最常見(jiàn)的三種調(diào)度器

reference:
http://www.reibang.com/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/

http://blog.csdn.net/suifeng3051/article/details/49508261