原 Hadoop MapReduce 框架的問題
從上圖中可以清楚的看出原 MapReduce 程序的流程及設計思路：
- 首先用戶程序 (JobClient) 提交了一個 job，job 的信息會發送到 Job Tracker 中，Job Tracker 是 Map-reduce 框架的中心，他需要與集羣中的機器定時通信 (heartbeat), 需要管理哪些程序應該跑在哪些機器上，需要管理所有 job 失敗、重啓等操作。
- TaskTracker 是 Map-reduce 集羣中每臺機器都有的一個部分，他做的事情主要是監視自己所在機器的資源情況。
- TaskTracker 同時監視當前機器的 tasks 運行狀況。TaskTracker 需要把這些信息通過 heartbeat 發送給 JobTracker，JobTracker 會蒐集這些信息以給新提交的 job 分配運行在哪些機器上。上圖虛線箭頭就是表示消息的發送 - 接收的過程。
可以看得出原來的 map-reduce 架構是簡單明瞭的，在最初推出的幾年，也得到了衆多的成功案例，獲得業界廣泛的支持和肯定，但隨着分佈式系統集羣的規模和其工作負荷的增長，原框架的問題逐漸浮出水面，主要的問題集中如下：
- JobTracker 是 Map-reduce 的集中處理點，存在單點故障。
- JobTracker 完成了太多的任務，造成了過多的資源消耗，當 map-reduce job 非常多的時候，會造成很大的內存開銷，潛在來說，也增加了 JobTracker fail 的風險，這也是業界普遍總結出老 Hadoop 的 Map-Reduce 只能支持 4000 節點主機的上限。
- 在 TaskTracker 端，以 map/reduce task 的數目作爲資源的表示過於簡單，沒有考慮到 cpu/ 內存的佔用情況，如果兩個大內存消耗的 task 被調度到了一塊，很容易出現 OOM。
- 在 TaskTracker 端，把資源強制劃分爲 map task slot 和 reduce task slot, 如果當系統中只有 map task 或者只有 reduce task 的時候，會造成資源的浪費，也就是前面提過的集羣資源利用的問題。
- 源代碼層面分析的時候，會發現代碼非常的難讀，常常因爲一個 class 做了太多的事情，代碼量達 3000 多行，，造成 class 的任務不清晰，增加 bug 修復和版本維護的難度。
- 從操作的角度來看，現在的 Hadoop MapReduce 框架在有任何重要的或者不重要的變化 ( 例如 bug 修復，性能提升和特性化 ) 時，都會強制進行系統級別的升級更新。更糟的是，它不管用戶的喜好，強制讓分佈式集羣系統的每一個用戶端同時更新。這些更新會讓用戶爲了驗證他們之前的應用程序是不是適用新的 Hadoop 版本而浪費大量時間。
YARN 基本架構
YARN是Hadoop 2.0中的資源管理系統，它的基本設計思想是將MRv1中的JobTracker拆分成了兩個獨立的服務：一個全局的資源管理器ResourceManager和每個應用程序特有的ApplicationMaster。
其中ResourceManager負責整個系統的資源管理和分配，而ApplicationMaster負責單個應用程序的管理。
YARN中包括以下幾個角色：
- 客戶端(Client)：向整個集羣提交MapReduce作業。
- YARN資源管理器(ResourceManager)：負責調度整個集羣的計算資源。
- YARN節點管理器(NodeManager)：在集羣的機器上啓動以及監控container。
- MapReduce應用管理器(MRAppMaster)： 調度某個作業的所有任務. 應用管理器和任務運行在container中, container由資源管理器調度, 由節點管理器管理。
一、YARN 概述
YARN 是一個資源調度平臺，負責爲運算程序提供服務器運算資源，相當於一個分佈式的操 作系統平臺，而 MapReduce 等運算程序則相當於運行於操作系統之上的應用程序
YARN 是 Hadoop2.x 版本中的一個新特性。它的出現其實是爲了解決第一代 MapReduce 編程 框架的不足，提高集羣環境下的資源利用率，這些資源包括內存，磁盤，網絡，IO等。Hadoop2.X 版本中重新設計的這個 YARN 集羣，具有更好的擴展性，可用性，可靠性，向後兼容性，以 及能支持除 MapReduce 以外的更多分佈式計算程序
1、YARN 並不清楚用戶提交的程序的運行機制
2、YARN 只提供運算資源的調度（用戶程序向 YARN 申請資源，YARN 就負責分配資源）
3、YARN 中的主管角色叫 ResourceManager
4、YARN 中具體提供運算資源的角色叫 NodeManager
5、這樣一來，YARN 其實就與運行的用戶程序完全解耦，就意味着 YARN 上可以運行各種類 型的分佈式運算程序（MapReduce 只是其中的一種），比如 MapReduce、Storm 程序，Spark 程序，Tez ……
6、所以，Spark、Storm 等運算框架都可以整合在 YARN 上運行，只要他們各自的框架中有 符合 YARN 規範的資源請求機制即可
7、yarn 就成爲一個通用的資源調度平臺，從此，企業中以前存在的各種運算集羣都可以整 合在一個物理集羣上，提高資源利用率，方便數據共享
二、原 MR框架的不足
1、JobTracker 是集羣事務的集中處理點，存在單點故障
2、JobTracker 需要完成的任務太多，既要維護 job 的狀態又要維護 job 的 task 的狀態，造成 過多的資源消耗
3、在 TaskTracker 端，用 Map/Reduce Task 作爲資源的表示過於簡單，沒有考慮到 CPU、內 存等資源情況，當把兩個需要消耗大內存的 Task 調度到一起，很容易出現 OOM
4、把資源強制劃分爲 Map/Reduce Slot，當只有 MapTask 時，TeduceSlot 不能用；當只有 Reduce Task 時，MapSlot 不能用，容易造成資源利用不足。
總結起來就是：
1、擴展性差
2、可靠性低
3、資源利用率低
4、不支持多種計算框架
三、新版 YARN 架構的優點
YARN/MRv2 最基本的想法是將原 JobTracker 主要的資源管理和 Job 調度/監視功能分開作爲 兩個單獨的守護進程。有一個全局的 ResourceManager(RM)和每個 Application 有一個 ApplicationMaster(AM)，Application 相當於 MapReduce Job 或者 DAG jobs。ResourceManager 和 NodeManager(NM)組成了基本的數據計算框架。ResourceManager 協調集羣的資源利用， 任何 Client 或者運行着的 applicatitonMaster 想要運行 Job 或者 Task 都得向 RM 申請一定的資 源。ApplicatonMaster 是一個框架特殊的庫，對於 MapReduce 框架而言有它自己的 AM 實現， 用戶也可以實現自己的 AM，在運行的時候，AM 會與 NM 一起來啓動和監視 Tasks。
四、Yarn基本架構
從YARN的架構圖來看，它主要由ResourceManager、NodeManager、ApplicationMaster和Container等以下幾個組件構成。
1）ResourceManager（RM）
YARN分層結構的本質是ResourceManager。這個實體控制整個集羣並管理應用程序向基礎計算資源的分配。ResourceManager將各個資源部分（計算、內存、帶寬等）精心安排給基礎NodeManager（YARN的每節點代理）。ResourceManager還與ApplicationMaster一起分配資源，與NodeManager一起啓動和監視它們的基礎應用程序。在此上下文中，ApplicationMaster承擔了以前的TaskTracker的一些角色，ResourceManager承擔了JobTracker 的角色。
總的來說，RM有以下作用
（1）處理客戶端請求
（2）啓動或監控ApplicationMaster
（3）監控NodeManager
（4）資源的分配與調度
2）ApplicationMaster（AM）
ApplicationMaster管理在YARN內運行的每個應用程序實例。ApplicationMaster負責協調來自ResourceManager的資源，並通過NodeManager監視容器的執行和資源使用（CPU、內存等的資源分配）。請注意，儘管目前的資源更加傳統（CPU 核心、內存），但未來會帶來基於手頭任務的新資源類型（比如圖形處理單元或專用處理設備）。從YARN角度講，ApplicationMaster是用戶代碼，因此存在潛在的安全問題。YARN假設ApplicationMaster存在錯誤或者甚至是惡意的，因此將它們當作無特權的代碼對待。
總的來說,AM有以下作用
（1）負責數據的切分
（2）爲應用程序申請資源並分配給內部的任務
（3）任務的監控與容錯
3）NodeManager（NM）
NodeManager管理YARN集羣中的每個節點。NodeManager提供針對集羣中每個節點的服務，從監督對一個容器的終生管理到監視資源和跟蹤節點健康。MRv1通過插槽管理Map 和Reduce任務的執行，而NodeManager管理抽象容器，這些容器代表着可供一個特定應用程序使用的針對每個節點的資源。
總的來說，NM有以下作用
（1）管理單個節點上的資源
（2）處理來自ResourceManager的命令
（3）處理來自ApplicationMaster的命令
4）Container
Container是YARN中的資源抽象，它封裝了某個節點上的多維度資源，如內存、CPU、磁盤、網絡等，當AM向RM申請資源時，RM爲AM返回的資源便是用Container表示的。YARN會爲每個任務分配一個Container，且該任務只能使用該Container中描述的資源。
總的來說，Container有以下作用
對任務運行環境進行抽象，封裝CPU、內存等多維度的資源以及環境變量、啓動命令等任務運行相關的信息
要使用一個YARN集羣，首先需要一個包含應用程序的客戶的請求。ResourceManager協商一個容器的必要資源，啓動一個ApplicationMaster來表示已提交的應用程序。通過使用一個資源請求協議，ApplicationMaster協商每個節點上供應用程序使用的資源容器。執行應用程序時，ApplicationMaster監視容器直到完成。當應用程序完成時，ApplicationMaster從 ResourceManager註銷其容器，執行週期就完成了。
通過上面的講解，應該明確的一點是，舊的Hadoop架構受到了JobTracker的高度約束，JobTracker負責整個集羣的資源管理和作業調度。新的YARN架構打破了這種模型，允許一個新ResourceManager管理跨應用程序的資源使用，ApplicationMaster負責管理作業的執行。這一更改消除了一處瓶頸，還改善了將Hadoop集羣擴展到比以前大得多的配置的能力。此外，不同於傳統的MapReduce，YARN允許使用MPI( Message Passing Interface) 等標準通信模式，同時執行各種不同的編程模型，包括圖形處理、迭代式處理、機器學習和一般集羣計算。
五、Yarn工作機制
1）Yarn運行機制
2）工作機制詳解
（0）Mr程序提交到客戶端所在的節點
（1）Yarnrunner向Resourcemanager申請一個Application。
（2）rm將該應用程序的資源路徑返回給yarnrunner
（3）該程序將運行所需資源提交到HDFS上
（4）程序資源提交完畢後，申請運行mrAppMaster
（5）RM將用戶的請求初始化成一個task
（6）其中一個NodeManager領取到task任務。
（7）該NodeManager創建容器Container，併產生MRAppmaster
（8）Container從HDFS上拷貝資源到本地
（9）MRAppmaster向RM 申請運行maptask容器
（10）RM將運行maptask任務分配給另外兩個NodeManager，另兩個NodeManager分別領取任務並創建容器。
（11）MR向兩個接收到任務的NodeManager發送程序啓動腳本，這兩個NodeManager分別啓動maptask，maptask對數據分區排序。
（12）MRAppmaster向RM申請2個容器，運行reduce task。
（13）reduce task向maptask獲取相應分區的數據。
（14）程序運行完畢後，MR會向RM註銷自己。
六、資源調度器
目前，Hadoop作業調度器主要有三種：FIFO、Capacity Scheduler和Fair Scheduler。Hadoop2.7.2默認的資源調度器是Capacity Scheduler。
具體設置詳見：yarn-default.xml文件
|
<property> <description>The class to use as the resource scheduler.</description> <name>yarn.resourcemanager.scheduler.class</name> <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler</value> </property> |
1）先進先出調度器（FIFO）
FIFO是Hadoop中默認的調度器，也是一種批處理調度器。它先按照作業的優先級高低，再按照到達時間的先後選擇被執行的作業。原理圖如下所示。
比如，一個TaskTracker正好有一個空閒的slot，此時FIFO調度器的隊列已經排好序，就選擇排在最前面的任務job1，job1包含很多map task和reduce task。假如空閒資源是map slot，我們就選擇job1中的map task。假如map task0要處理的數據正好存儲在該TaskTracker 節點上，根據數據的本地性，調度器把map task0分配給該TaskTracker。FIFO 調度器整體就是這樣一個過程。
2）容量調度器（Capacity Scheduler）
支持多個隊列，每個隊列可配置一定的資源量，每個隊列採用FIFO調度策略，爲了防止同一個用戶的作業獨佔隊列中的資源，該調度器會對同一用戶提交的作業所佔資源量進行限定。調度時，首先按以下策略選擇一個合適隊列：計算每個隊列中正在運行的任務數與其應該分得的計算資源之間的比值，選擇一個該比值最小的隊列；然後按以下策略選擇該隊列中一個作業：按照作業優先級和提交時間順序選擇，同時考慮用戶資源量限制和內存限制。 原理圖如下所示。
比如我們分爲三個隊列：queueA、queueB和queueC，每個隊列的 job 按照到達時間排序。假如這裏有100個slot，queueA分配20%的資源，可配置最多運行15個task，queueB 分配50%的資源，可配置最多運行25個task，queueC分配30%的資源，可配置最多運行25個task。這三個隊列同時按照任務的先後順序依次執行，比如，job11、job21和job31分別排在隊列最前面，是最先運行，也是同時運行。
3）公平調度器（Fair Scheduler）
同計算能力調度器類似，支持多隊列多用戶，每個隊列中的資源量可以配置，同一隊列中的作業公平共享隊列中所有資源。原理圖如下所示
比如有三個隊列：queueA、queueB和queueC，每個隊列中的 job 按照優先級分配資源，優先級越高分配的資源越多，但是每個 job 都會分配到資源以確保公平。在資源有限的情況下，每個 job 理想情況下獲得的計算資源與實際獲得的計算資源存在一種差距， 這個差距就叫做缺額。在同一個隊列中，job的資源缺額越大，越先獲得資源優先執行。作業是按照缺額的高低來先後執行的，而且可以看到上圖有多個作業同時運行。
七、作業提交全過程
1）作業提交過程之YARN
2）作業提交過程之MapReduce
3）作業提交過程之讀數據
4）作業提交過程之寫數據
5）作業提交詳解
（1）作業提交
client調用job.waitForCompletion方法，向整個集羣提交MapReduce作業 (第1步) 。 新的作業ID(應用ID)由資源管理器分配(第2步)。作業的client覈實作業的輸出, 計算輸入的split, 將作業的資源(包括Jar包, 配置文件, split信息)拷貝給HDFS(第3步)。最後, 通過調用資源管理器的submitApplication()來提交作業(第4步)。
（2）作業初始化
當資源管理器收到submitApplciation()的請求時, 就將該請求發給調度器(scheduler), 調度器分配container, 然後資源管理器在該container內啓動應用管理器進程, 由節點管理器監控(第5步)。
MapReduce作業的應用管理器是一個主類爲MRAppMaster的Java應用。其通過創造一些bookkeeping對象來監控作業的進度, 得到任務的進度和完成報告(第6步)。然後其通過分佈式文件系統得到由客戶端計算好的輸入split(第7步)。然後爲每個輸入split創建一個map任務, 根據mapreduce.job.reduces創建reduce任務對象。
（3）任務分配
如果作業很小, 應用管理器會選擇在其自己的JVM中運行任務。
如果不是小作業, 那麼應用管理器向資源管理器請求container來運行所有的map和reduce任務(第8步)。這些請求是通過心跳來傳輸的, 包括每個map任務的數據位置, 比如存放輸入split的主機名和機架(rack)。調度器利用這些信息來調度任務, 儘量將任務分配給存儲數據的節點, 或者分配給和存放輸入split的節點相同機架的節點。
（4）任務運行
當一個任務由資源管理器的調度器分配給一個container後, 應用管理器通過聯繫節點管理器來啓動container(第9步)。任務由一個主類爲YarnChild的Java應用執行。在運行任務之前首先本地化任務需要的資源, 比如作業配置, JAR文件, 以及分佈式緩存的所有文件(第10步)。最後, 運行map或reduce任務(第11步)。
YarnChild運行在一個專用的JVM中, 但是YARN不支持JVM重用。
（5）進度和狀態更新
YARN中的任務將其進度和狀態(包括counter)返回給應用管理器, 客戶端每秒(通過mapreduce.client.progressmonitor.pollinterval設置)嚮應用管理器請求進度更新, 展示給用戶。
（6）作業完成
除了嚮應用管理器請求作業進度外, 客戶端每5分鐘都會通過調用waitForCompletion()來檢查作業是否完成。時間間隔可以通過mapreduce.client.completion.pollinterval來設置。作業完成之後, 應用管理器和container會清理工作狀態, OutputCommiter的作業清理方法也會被調用。作業的信息會被作業歷史服務器存儲以備之後用戶覈查。
八、任務的推測執行
1）作業完成時間取決於最慢的任務完成時間
一個作業由若干個Map任務和Reduce任務構成。因硬件老化、軟件Bug等，某些任務可能運行非常慢。
典型案例：系統中有99%的Map任務都完成了，只有少數幾個Map老是進度很慢，完不成，怎麼辦？
2）推測執行機制：
發現拖後腿的任務，比如某個任務運行速度遠慢於任務平均速度。爲拖後腿任務啓動一個備份任務，同時運行。誰先運行完，則採用誰的結果。
3）執行推測任務的前提條件
（1）每個task只能有一個備份任務；
（2）當前job已完成的task必須不小於0.05（5%）
（3）開啓推測執行參數設置。Hadoop2.7.2 mapred-site.xml文件中默認是打開的。
|
<property> <name>mapreduce.map.speculative</name> <value>true</value> <description>If true, then multiple instances of some map tasks may be executed in parallel.</description> </property>
<property> <name>mapreduce.reduce.speculative</name> <value>true</value> <description>If true, then multiple instances of some reduce tasks may be executed in parallel.</description> </property> |
4）不能啓用推測執行機制情況
（1）任務間存在嚴重的負載傾斜；
（2）特殊任務，比如任務向數據庫中寫數據。
5）算法原理：
假設某一時刻，任務T的執行進度爲progress，則可通過一定的算法推測出該任務的最終完成時刻estimateEndTime。另一方面，如果此刻爲該任務啓動一個備份任務，則可推斷出它可能的完成時刻estimateEndTime`,於是可得出以下幾個公式：
estimateEndTime=estimatedRunTime+taskStartTime
estimatedRunTime=(currentTimestamp-taskStartTime)/progress
estimateEndTime`= currentTimestamp+averageRunTime
其中，
currentTimestamp爲當前時刻；
taskStartTime爲該任務的啓動時刻；
averageRunTime爲已經成功運行完成的任務的平均運行時間；
progress是任務運行的比例（0.1-1）；
這樣，MRv2總是選擇（estimateEndTime- estimateEndTime·）差值最大的任務，併爲之啓動備份任務。爲了防止大量任務同時啓動備份任務造成的資源浪費，MRv2爲每個作業設置了同時啓動的備份任務數目上限。
推測執行機制實際上採用了經典的優化算法：以空間換時間，它同時啓動多個相同任務處理相同的數據，並讓這些任務競爭以縮短數據處理時間。顯然，這種方法需要佔用更多的計算資源。在集羣資源緊缺的情況下，應合理使用該機制，爭取在多用少量資源的情況下，減少作業的計算時間。
參考鏈接：
https://www.cnblogs.com/frankdeng/p/9311474.html
https://blog.csdn.net/u014774781/article/details/50921006