MapReduce 離線計算引擎

 

一、Mapreduce 的基本概念

 

Mapreduce 是一個分散式的計算框架，提供計算的模型，框架和平臺，它易於程式設計，我們在進行功能元件開發的時候只需要通過程式碼表達我們需要做什麼就可以，具體的計算和操作交由執行框架進行處理即可。如果平臺效能無法滿足我們的需求的時候，我們只需要按需拓展我們的節點，通過 Scale-out 來進行效能線性拓展，而本身平臺又提供了高容錯性，我們可以通過計算遷移或者資料遷移操作，當節點出現故障的時候不會影響我們的現有業務。

 

它包含以下三層含義：

 

（1）MapReduce 是基於叢集的高效能平行計算平臺（ClusterInfrastructure）。這裡主要是指其在 Hadoop 中作為一個元件被使用，MapReduce 在大資料平臺中提供的是一個離線的分散式計算引擎。其可以和底層的儲存相關的元件進行互動，將檔案進行計算和其他相關的操作。

 

（2）MapReduce 是一個平行計算與執行軟體框架（SoftwareFramework）。

 

作為一個軟體框架，MapReduce 主要是被使用在程式設計語句中，進行相關的軟體編譯，比如其在 Python 中就作為了一個語句韌體被程式設計者使用。

 

（3）MapReduce 是一個並行程式設計模型（ProgrammingModel&Methodology）。在早期谷歌提出 MapReduce 的設計思想時，其實它並沒有一個專門的作用領域，而是作為一個思想來使用，它提供了計算的方法，所以在實際中，我們還可以按照這種設計模型和思想進行其他相關的開發。

MapReduce 具有如下的特點：

 

（1）易於程式設計：程式設計師僅需描述做什麼，具體怎麼做交由系統的執行框架處理。（2）良好的擴充套件性：可通過新增節點以擴充套件叢集能力。

 

（3）高容錯性：通過計算遷移或資料遷移等策略提高叢集的可用性與容錯性。

 

MapReduce 從誕生到目前的發展中主要的版本有以下幾個：MR1.3.0、MR1.3.1、MR1.5.0、MR1.5.1，但是在 MapReducev1 中，也同時存在以下幾個致命性的缺點：（1）拓展性受限，由於 MapReduce 在早期需要自己去維護節點，所以 Mapreduce 雖然拓展性很好，但是拓展是有限度的，無法進行無限的拓展。

 

MapReduce 作為一個計算引擎，其在早期的設計思路中，由於是獨立於所有元件存在的所以他除了需要進行相關的計算操作以外，還需要對自己所搭載的平臺進行相關的維護操作。這樣的話，MapReduce 除了計算就還要對裝置提供一部分的資源進行維護操作，那麼裝置越多我們為了維護裝置所需要從 MapReduce 中提供的資源也就越多。這樣的話，裝置多雖然可以提高計算的效率，但是裝置數目過大的時候，維護的開銷就會高於裝置所能提供的資源了。這樣就會到達一個平衡點。也就是指 MapReduce 在這種情況下就無法無限拓展了，所以其能夠計算的資料也就有了上限，但是這樣的話，就無法滿足資料增長的計算需求。

 

（2）單點故障：MapReduce 是部署在單個節點上的，所以一旦出現問題之後， MapReduce 就會直接無法使用，產生單點故障由於早期的 MapReduce 是一個單程序的引擎，和其他的元件不同的是，其他元件

 

都會有對應的保護措施，不管是對程序還是對資料，那麼 MapReduce 沒有提供任何的保護機制，一旦計算出現問題，那麼就直接中斷。MapReduce 作為一個離線

計算引擎，其主要提供的是針對於大量的資料的計算工作，計算的週期會很長，那麼一旦出現問題，計算中斷就會導致之前的計算全部失效。

 

（3）不支援 MR 之外的計算：MapReduce 只支援離線計算，對於線上計算和流處理計算的大量需求無法滿足，也就導致了其計算的滯後性。

 

這裡主要想要表達的是 MapReduce 對於計算引擎之間的低效問題。由於 MapReduce 本身只提供對海量檔案的計算，那麼從其設計的角度上來講，就是提供大量檔案的計算操作。對於延遲敏感型的業務或者是有其他相關需求的計算都是無法滿足的，那麼這樣就會導致其出現計算的單一性，沒有很廣泛的適用性。（4）計算框架之間無法進行共享，資源利用率低：目前我們使用的計算引擎主要有 MapReduce、Storm、Spark 等，不同的框架採用的不同的計算方法，框架之間 MapReduce 不支援進行資料共享就導致了其對於資源的利用率過低的問題。

如上圖所示：由於在早期，我們的儲存元件是直接對接的計算引擎的，而計算引擎之間又無法做相關的共享操作，所以這個時候如果元件與元件之間需要做相關的資料共享，或者中間結果共享，那麼就會出現問題，MapReduce 作為計算引擎必須將自己的計算結果先存入到底層的儲存元件中，才能被其他元件呼叫到，那麼資料下盤第一個會造成的問題在於，這裡的資料作為一個臨時結果對於 HDFS 等儲存元件來說，認知就是一個數據，那麼就會啟用對應的保護機制，以及元資料修改等操作，而且本身資料下盤就要消耗時間，所以整個流程，會耗費掉大量的時間，而且一個計算過程中間會出現多次呼叫，那麼這種過程就會持續多次，整體的程序非常消耗相關的計算資源，而且如果這些元件都部署在一臺節點上，本身在記憶體中進行資料轉換就可以完成的事情，這裡必須要執行相當複雜的操作才能執行完成。所以資源的利用率和任務的執行時間都是非常的差的。

 

 

二、Yarn 簡介

 

Apache Hadoop YARN （Yet Another Resource Negotiator，另一種資源協調者）是一種新的 Hadoop 資源管理器，它是一個通用資源管理系統，可為上層應用提供統一的資源管理和排程，它的引入為叢集在利用率、資源統一管理和資料共享等方面帶來了巨大好處。

 

Yarn 的出現主要是為了解決上邊我們說到的 MapReduce v1 版本的問題，其實 MapReduce 的問題也是同樣出現在其他的計算引擎中的，所以 Yarn 的出現不僅僅是解決了 MapReduce 的問題還將以往離散的不關聯的各個元件在底層柔和為了一體，那麼 Yarn 主要帶來了以下的幾個好處：

（1）增大拓展性：前面說到拓展性的受限主要是由於計算引擎需要自身去維護節點，那麼 Yarn 第一步就將節點的維護作業從引擎身上解除安裝到 Yarn 來做，以往每個引擎都需要自身去維護，可能一個節點安裝了 5 個計算引擎，那麼 5 個計算引擎就會有 5 個節點維護程序，現在交由 Yarn 做之後，就會將這些程序全部解除安裝到自身，糅合成了一個程序來統一進行維護，這樣做就減小了計算引擎的其他工作，減少了引擎的額外開銷。

 

（2）單點故障：Yarn 的第二個作用就是解決了單點故障的問題，yarn 將計算引擎的任務也解除安裝到了自身，這樣傳統的計算引擎就不需要對計算的任務進行規劃和控制了，一方面減小了開銷，另一方面也有利於引擎與引擎之間的計算共享，任務管理不再交由計算引擎來進行維護，而是交由 Yarn 來進行。如果傳統的計算引擎需要執行跨引擎的計算，一方面會無法監控任務的執行狀態，另一方面，如果跨引擎執行計算，那麼引擎還需要額外的分配一部分資源來做跨引擎的計算維護，反而消耗的資源會更多。當 Yarn 將整體任務規劃執行監控解除安裝到自身之後，一方面會增大各個計算元件之間的相容性和控制能力，另一方面如果計算引擎出現故障，任務就不會再丟失，Yarn 就可以根據執行的進度，重新下發任務，思想很類似於網路中的斷點重傳。

 

（3）計算框架之間的共享：Yarn 的出現遮蔽了計算引擎之間的差異，主要是從任務、資源以及資料上，任務的遮蔽在第二條已經寫出，那麼資源的遮蔽主要體現在傳統的計算引擎中，每個計算引擎都會維護自身的資源，這個時候如果某一一引擎有突發的計算，其他的引擎是無法共享相關的資源，當 Yarn 出現之後，它將所有引擎的資源進行了整合，這樣做有利於進行統一調配實現高利用率，而且還節省了計算引擎的開銷。另外傳統的計算引擎在資料上無法共享，那麼 Yarn 接管了資源和任務相關的管理許可權之後，所有計算引擎的計算臨時結果都是快取在 yarn 管理的資源上，這個時候，我們的臨時資料就不需要在執行寫入操作，直接在記憶體中進行資源分配， 將包含資料的那一部分記憶體直接呼叫給其他引擎進行使用，就可以實現記憶體中的資料轉換和跨引擎呼叫。

三、Yarn 架構

 

ResourceManager(RM)：負責叢集中所有資源的統一管理和分配。它接收來自各個節點（NodeManager）的資源彙報資訊，並根據收集的資源按照一定的策略分配給各個應用程式。

 

RM 作為資源的管理者，其只對資源做管理，不對資源做維護，資源主要涉及的

是記憶體和 CPU 資源。所有的應用在被提交之後首先第一步都是需要做資源的申請的。業務提交之後會根據自身的資源消耗情況向 RM 做申請，RM 需要做資源的分配，以及資源的回收監控。

 

NodeManager(NM)：是每個節點上的代理，它管理 Hadoop 叢集中單個計算節點，包括與 ResourceManger 保持通訊，監督 Container 的生命週期管理，監控每個 Container 的資源使用（記憶體、CPU 等）情況，追蹤節點健康狀況，管理日誌和不同應用程式用到的附屬服務（auxiliary service）。

 

這裡我們說 RM 本身是資源的管控者，資源是在 NM 上的，相當於 NM 實際擁有這些資源，但是管理權和所有權是歸屬於 RM 的，就像買房，土地是國家的，產權是自己的。NM 需要上報自己的資源擁有狀況給 RM，RM 在根據相關任務情況，對這些資源做統一的分配操作。

 

Application Master(AM)：負責一個 Application 生命週期內的所有工作。包括：與 RM 排程器協商以獲取資源；將得到的資源進一步分配給內部任務（資源的二次分配）；與 NM 通訊以啟動/停止任務；監控所有任務執行狀態，並在任務執行失敗時重新為任務申請資源以重啟任務。

 

Container：Yarn 中的資源抽象，它封裝了某個節點上的多維度資源，如記憶體、CPU、磁碟、網路等。

 

容器是在 MapReduce 中執行任務的工作單位，其是一個資源的集合體，它是一個邏輯的概念，使用的時候將其分配建立，任務執行完畢之後，就會將容器回收，容器回收就是指回收容器中的 CPU 和記憶體資源。RM 分配 NM 的資源，在 NM 上建立一個 CPU 和記憶體的集合體，這個集合體就是 Container。

 

NodeManager 主要工作是節點資源管理監控和容器管理，RM 是系統中將資源分配給各個應用的最終決策者。

 

四、MapReduce 在 Yarn 中的任務排程

（1）使用者向 YARN 中提交應用程式， 其中包括 ApplicationMaster 程式、啟動 ApplicationMaster 的命令、使用者程式等。

 

這裡 Client 還是一個程序，並非是使用者的程式，Client 用於提交執行應用，對使用者提供一個可以進行訪問的介面，使用者通過該介面連線到 MapReduce 服務，然後提交對應的應用，然後 Client 將應用轉發到 RM 上進行進一步的操作，應用是由使用者的程式進行封裝之後的一個執行包，該執行包中需要有以下的內容，AMaster（用於進行應用的資源申請，分配，管理等操作，在整個業務執行的過程中都會被使用，AMaster 和其他的組價進行互動，完成相關的作業），Amaster相關的附屬命令以及我們所需要執行的具體程式。

 

（ 2） ResourceManager 為該應用程式分配第一個 Container，並與對應的 NodeManager 通 信 ， 要 求 它 在 這 個 Container 中 啟 動 應 用 程 序 的ApplicationMaster。

 

RM 中有兩個主要的子程序，一個是 AppManager，一個是 ResourceScheduler， AppManager 主要是對提交到引擎上的多個應用進行一個統一集中的管理，保證整體業務的執行。ResourceScheduler 是用於管理和監控資源的程序，它用於分配資源，管理資源，監控資源和回收資源。使用者將應用提交之後，首先第一步， RM 會根據使用者提交的應用中關於 AppMaster 的資訊，為其分配一部分的記憶體和 CPU 的資源，然後通告對應 NM 節點，在其身上拉起一個 Container，由於 Appmaster 本身也是一個程式，需要消耗資源，所以其會在 RM 分配 NM 拉起的這個 Container 中執行 AppMaster。

（3）ApplicationMaster 首先向 ResourceManager 註冊，這樣使用者可以直接通過 ResourceManage 檢視應用程式的執行狀態，然後它將為各個任務申請資源，並監控它的執行狀態，直到執行結束，即重複步驟 4~7。

 

AppMaster 啟動之後，首先第一步需要向 AppManager 去進行相關的註冊操作，否則 Appmaster 將會是一個非法的程式。

 

（4）ApplicationMaster 採用輪詢的方式通過 RPC 協議向 ResourceManager 申

 

請和領取資源。

 

AppMaster 註冊之後，根據設計的思想，它首先第一步會將程式做切分，分為執行的階段，最終切分為執行的一個個計算工作，我們稱之為 task，之後它會計算當前的 task 所需要消耗資源，然後向 ResourceScheduler 進行資源的申請操作，ResourceScheduler 同意之後將和 NM 進行通訊，通知 NM 分配相關的資源使用權給 AppMaster。

 

（5）一旦 ApplicationMaster 申請到資源後，便與對應的 NodeManager 通訊，要求它啟動任務。

 

AppMaster 獲取到使用權之後，就會和 NM 進行通訊，要求 NM 將對應的資源封裝為 Container，然後拉起，隨後 AppMaster 會將對應的 task 下發到 Container 中

 

進行執行計算。AppMaster 會採用輪詢的方式，也就是指，資源並不是根據程式所需要消耗的量一次性申請的，而是根據 task 消耗的資源，一個一個進行的申請，RM 在收到對應的申請請求時，會根據當前 NM 的負載情況（資源的分配情況，以及當前計算的開銷），隨機的選擇當前負載最低的 NM，將其資源分配給

AppMaster。

 

（6）NodeManager 為任務設定好執行環境（包括環境變數、JAR 包、二進位制程式等）後，將任務啟動命令寫到一個指令碼中，並通過執行該指令碼啟動任務。

（7）各個任務通過某個 RPC 協議向 ApplicationMaster 彙報自己的狀態和進度，以讓 ApplicationMaster 隨時掌握各個任務的執行狀態，從而可以在任務失敗時重新啟動任務。

 

在應用程式執行過程中，使用者可隨時通過 RPC 向 ApplicationMaster 查詢應用程式的當前執行狀態。在 task 執行完成之後，Container 會自己關閉，然後 NM 就會感知到資源釋放，隨後和 RM 通訊時，就會反饋資源已經處於可分配的狀態。（8）應用程式執行完成後，ApplicationMaster 向 ResourceManager

（AppManager）登出並關閉自己。

五、Yarn 通訊協議

Application Client Protocol ：JobClient 通過該 RPC 協議提交應用程式、查詢應用程式狀態等。

 

Resource Manager Administration Protocol：Admin 通過該 RPC 協議更新系統配置檔案，比如節點黑白名單、使用者佇列許可權等。

 

Application Master Protocol ：AM 通過該 RPC 協議向 RM 註冊和撤銷自己，併為各個任務申請資源。

 

Container Management Protocol ： AM 通過該 RPC 要求 NM 啟動或者停止Container，獲取各個 Container 的使用狀態等資訊。

 

Resource Tracker ：NM 通過該 RPC 協議向 RM 註冊，並定時傳送心跳資訊彙報當前節點的資源使用情況和 Container 執行情況。

 

六、MapReduce 過程詳解

Job 的建立、申請與 Map 流程：

 

（1）首先在進行啟動 MapReduce 計算前，我們先保證資料在 HDFS 中，避免由於檔案不存在導致的處理失敗（2）確認檔案存在之後，我們下一步就需要做任務的提交工作，應用將工作提

 

交給 RM 模組進行處理，RM 模組會針對請求建立 Job，每個應用的請求都會有一個唯一的 JobID 進行區分。

 

我們將工作提交給 Client 之後，Client 會接收相關的資料並且將資料提交給 RM

 

模組，RM 模組收到之後，首先第一步需要建立一個 job 並且分配 jobID。這裡的 JobID 主要是用於區分業務，我們可以記錄相關的操作日誌。用於區分。

 

（3）Job 建立完成之後，我們會將待處理的檔案進行分片操作，通過分片，我們將分片與 MapTask 進行一一對應。

 

在我們對應用分配了 JobID 之後，在 job 在進行提交之前，首先會將檔案進行分片的操作。由於整體檔案一般過大，沒有某一個節點可以完全執行計算的操作，那麼我們就需要將檔案進行切分，然後將任務打散在不同的裝置上去執行，這樣也體現了 MapReduce 的分散式的特點。我們預設一個分片對應的就是一個 task （這裡的 Task 就是用於執行輸入的 MapTask），每個 task 會攜帶一個 key 值。（4）分片完成之後，下一步就是提交 Job，RM 會根據收到的 Job 和 NM 模組目前的負載選擇合適的 NM 去排程 AM，AM 在收到 Job 之後，會對工作進行初始化，衡量計算所需的資源並向 RM 申請，RM 收到申請之後，將會針對 task 排程某一些

NM 模組啟動 Container 程序來執行 task 任務。

 

計算與 Reduce 程序：

 

（1）Map 輸入的資源在計算完成之後，暫存在一個環形快取分割槽中，當快取分割槽寫滿，最前端的資料就會溢位寫入到本地磁碟中，觸發 Reduce 程序 Map 任務主要執行的就是資料的輸入，切分，以及計算的操作，計算中會產生大量的臨時結果，這個時候我們就需要將這些檔案儲存在記憶體中，進行第一步的快取操作，我們在記憶體中分配了一個環形的記憶體緩衝區進行資料的臨時存放，緩衝區是一個有大小限制的空間，它是一個邏輯的概念，實際上是一個連續的記憶體分配地址。資料按照先後順序入棧，那麼一旦緩衝區寫滿，最前端的也就是最先入棧的資料，就會溢位，溢位之後我們就會將這些臨時的資料進行下盤操作進行儲存，因為記憶體的大小是有限的，而且臨時檔案又很多，所以我們無法保證所有的臨時檔案都儲存在記憶體中，而且程序本身又佔用了部分的記憶體所以我們需要進行這個出入棧的快取操作。

（2）在進行 Reduce 輸出之前，由於我們在計算中產生了很多的臨時檔案，那麼檔案過於碎片化，就會在匯出時影響整體的匯出效率，所以在輸出之前，我們可選執行以下幾個操作：分割槽，排序，組合，合併（這些操作都是針對於執行相關的結果內容的）

 

①分割槽：MR 框架會根據 Reduce 程序的個數建立對應個數的分割槽，將相同 key 值的資料存放到同一個分割槽中。例如：一次計算程序被分為了多個 job 進行計算，那麼輸出的時候為了保證對應的資料最終被組合成唯一的計算結果，所以我們需

要對資料進行分割槽，那麼每個 job 都會有一個 key 值保證最終的計算結果被儲存到同一個分割槽中。

 

分割槽的主要作用就是用於對應結果的，我們將切片後的 Maptask 執行結果又按照 Key 值進行了歸類，這樣做就可以將具有相同 key 值的臨時檔案存放到同一個分割槽中，結果整合有利於減小輸出的檔案個數，對我們的執行結果輸出更加有利。②排序：根據 Map 的輸出順序，RM 模組會將 Reduce 計算出來的結果進行排序（可選）

 

③組合：根據使用者的要求，可選將結果進行組合，最終產生一個總結果（可選）

 

④合併：由於計算之後會產生大量的資料，所以我們在寫入資料的時候可以將檔案進行合併操作，按照上邊說的三種方式或者採用壓縮方案，最終將溢位檔案合併為 MOF 檔案進行輸出，MOF（MapOutputFile）

 

組合和合並的區別：組合是將我們執行的臨時檔案的結果進行整理和合並操作，組合會減小檔案的大小，但是減小的是單個檔案內的內容，所以單個檔案的大小會縮減，但是合併是針對於溢位檔案來進行一個檔案級別的合併操作，所以合併做操作是減小整體所有檔案所消耗的空間大小。所以我們可以理解為組合是對內容作的操作，合併是對檔案做的操作。

 

（3）MOF 檔案在進行輸出的時候首先是放置在記憶體（這裡所說的記憶體並不是之前所提到的記憶體的緩衝區，而是單獨獨立於環形記憶體緩衝區的新分配的一塊記憶體區域）之中的，當 MOF 檔案輸出佔任務總輸出的 3%以上時，就會啟動 reduce 程序，隨著檔案數的增加，我們針對檔案進行分割槽、排序、組合、合併之後，將小的 MOF 檔案逐步整合為大的 MOF 檔案，直到最終最後一次 MOF 合併生成的就是輸出結果。

 

總體來說：MapReduce 的程序分為 Map 程序和 Reduce 程序，主要程序為：commit、Split、Map、Sort/Merge、Reduce。在計算程序中又包含了針對臨時檔案的操作。程序之間相互協作完成對應的目標。

 

MapReduce 完全詳細程序：

使用者向 Client 提交應用執行請求

Client 收到請求之後，受理請求並且接收相關的資料

Client 會向 RM 提交申請

RM 受理申請並且建立和反饋 JobID

Client 將應用提交到 RM 上

RM 受理應用，並且啟動 APPManager，啟動之後，RM 會根據 NM 的負載情況，選擇當前負載最小的 NM，通知其在自身啟動一個容器，之後 RM 會將 APPMaster 下發到該容器中進行執行操作。

AppMaster 在啟動之後，首先會向 AppManager 執行註冊操作。之後會根據job，計算當前任務執行所需要的資源的總量，並且將 job 切分為 task，以 task 為單位向 RS 去申請。

RS 在收到請求之後，會檢查當前叢集內 NM 的負載情況，選擇負載最低的 NM，並且向 AppMaster 返回對應的資訊

AppMaster 在收到 RS 的確認資訊之後，會要求該 NM 啟動容器，並且將 task 進行傳送。

NM 在拉起容器之後，將任務加入到容器中進行執行，執行完成之後其會將結果整合成臨時檔案反饋到 Appmaster 的記憶體中。AppMaster 的記憶體中會有一個環形臨時緩衝區，各個 task 執行之後的臨時檔案都會在這裡儲存。當環形緩衝區溢位時，就會觸發下一步的操作。

在進行下一步輸出之前，首先要執行 4 步操作 11.1 分割槽：檔案會按照雜湊演算法得到的 key 值進行分割槽，也就相當於根據分片

我們最終將相同分片的執行結果的臨時檔案放到相同的分割槽內。 11.2 排序：我們會將計算出的結果按照我們想要的格式進行排序操作

組合：多個結果之間可能會出現重複的情況，那麼為了減小輸出的檔案大小，並且利於表達，我們可以選擇執行組合的操作 合併：我們將分割槽內多個臨時溢位檔案進行整合，整合為 MOF 檔案

 

整合為 MOF 檔案之後，在 MOF 檔案輸出進度為 3%的時候我們就會啟動 Reduce 程序。我們會將 MOF 檔案做連續和合並和排序操作，直到最終整合為一個完 er資源，AppMaster 要向 AppManager 登出。並將執行結果通過 client 反饋給使用者。

使用者收到結果之後關閉應用，RM 將 JOBID 回收並且記錄執行日誌。

七、Yarn 的資源分配

 

當前 YARN 支援記憶體和 CPU 兩種資源型別的管理和分配。每個 NodeManager 可分配的記憶體和 CPU 的數量可以通過配置選項設定（可在 yarn 服務配置頁面配置）。（1）yarn.nodemanager.resource.memory-mb

用於當前 NodeManager 上正執行的容器的實體記憶體的大小。單位：MB。必須小於

NodeManager 伺服器上的實際記憶體大小（2）yarn.nodemanager.vmem-pmem-ratio

為容器設定記憶體限制時虛擬記憶體跟實體記憶體的比值。容器分配值使用實體記憶體表示的，虛擬記憶體使用率超過分配值的比例不允許大於當前這個比例。

（3）yarn.nodemanager.resource.cpu-vcore可分配給 container 的 CPU 核數。建議配置為 CPU 核數的 1.5-2 倍。

 

資源分配模型：

排程器維護一群佇列的資訊。使用者可以向一個或者多個佇列提交應用。每次 NM 心跳的時候，排程器根據一定的規則選擇一個佇列，再在佇列上選擇一個應用，嘗試在這個應用上分配資源。

 

排程器會優先匹配本地資源的申請請求，其次是同機架的，最後是任意機器的。當任務提交上來，首先會宣告提交到哪個佇列上，排程器會分配佇列，如果沒有指定則任務執行在預設佇列。

佇列是封裝了叢集資源容量的資源集合，佔用叢集的百分比例資源，佇列分為父佇列，子佇列，任務最終是執行在子佇列上的。父佇列可以有多個子佇列。排程器選擇佇列上的應用，然後根據一些演算法給應用分配資源

八、容量排程器

容量排程器使得 Hadoop 應用能夠共享的、多使用者的、操作簡便的執行在叢集上，同時最大化叢集的吞吐量和利用率。

容量排程器以佇列為單位劃分資源，每個佇列都有資源使用的下限和上限。每個使用者可以設定資源使用上限。管理員可以約束單個佇列、使用者或作業的資源使用。支援作業優先順序，但不支援資源搶佔。

特點：

容量保證：管理員可為每個佇列設定資源最低保證和資源使用上限，所有提交到該佇列的應用程式共享這些資源。

靈活性：如果一個佇列中的資源有剩餘，可以暫時共享給那些需要資源的佇列，當該佇列有新的應用程式提交，則其他佇列釋放的資源會歸還給該佇列。

支援優先順序：佇列支援任務優先順序排程（預設是 FIFO）。

多重租賃：支援多使用者共享叢集和多應用程式同時執行。為防止單個應用程式、使用者或者佇列獨佔叢集資源，管理員可為之增加多重約束。

動態更新配置檔案：管理員可根據需要動態修改配置引數，以實現線上叢集管理。任務選擇：排程時，首先按以下策略選擇一個合適佇列：

資源利用量最低的佇列優先，比如同級的兩個佇列 Q1 和 Q2，它們的容量均為 30，而 Q1 已使用 10，Q2 已使用 12，則會優先將資源分配給 Q1；

最小佇列層級優先，例如：QueueA 與 QueueB.childQueueB，則 QueueA 優先；資源回收請求佇列優先。

然後按以下策略選擇該佇列中一個任務：

按照任務優先順序和提交時間順序選擇，同時考慮使用者資源量限制和記憶體限制。

動態記憶體管理可用來優化 NodeManager 中 Containers 的記憶體利用率。任務在執行過程中可能產生多個 Container。

當前，當單個節點上的 Container 超過機器執行記憶體大小時，即使叢集總的配置記憶體利用還很低，NodeManager 也會終止這些 Containers。這樣就會經常使使用者作業失敗。

動態記憶體管理特性在當前是一個改進，只有當 NodeManager 中的所有 Containers 的總記憶體使用超過了已確定的閾值，那麼那些記憶體使用過多的 Containers 才會被終止。NM 總記憶體閾值的計算方法是：

NM.MEM=yarn.nodemanager.resource.memory*1024*1024*yarn.nodemanager.dy namic.memory.usage.threshold、單位 GB NM.MEM=分配給容器執行任務的記憶體*1024*1024*nodemanager 動態記憶體使用閾值

舉例，假如某些 Containers 的實體記憶體利用率超過了配置的記憶體閾值，但所有 Containers 的總記憶體利用率並沒有超過設定的叢集記憶體閾值，那麼那些記憶體使用過多的 Containers 仍可以繼續執行。

十、Yarn 的標籤排程制度

在沒有標籤排程之前，任務提交到哪個節點上是無法控制的，會根據一些演算法及條件，叢集隨機分配到某些節點上。而標籤排程可以指定任務提交到哪些節點上。比如之前需要消耗高記憶體的應用提交上來，由於執行在那些節點不可控，任務可能執行在普通效能的機器上。Label based scheduling 是一種排程策略。該策略的基本思想是：使用者可以為每個 nodemanager 標註一個標籤，比如 high-memory， high-IO 等進行分類，以表明該 nodemanager 的特性；同時，使用者可以為排程器中每個佇列標註一個標籤，即佇列與標籤繫結，這樣，提交到某個佇列中的作業， 只會使用標註有對應標籤的節點上的資源，即任務實際執行在打有對應標籤的節 點上。將耗記憶體消耗型的任務提交到綁定了 high-memry 的標籤的佇列上，那麼任務就可以執行在高記憶體機器上。

十一、Yarn 的 AM 作業保留機制

在 YARN 中， ApplicationMaster(AM) 與其他 Container 類 似 也 運 行 在

NodeManager 上（忽略未管理的 AM）。AM 可能會由於多種原因崩潰、退出或關閉。如果 AM 停止執行，ResourceManager(RM)會關閉 ApplicationMaster 中管理的所有 Container，包括當前任務在 NodeManager(NM)上正在執行的所有Container。

RM 會在另一計算節點上啟動新的 ApplicationMaster。不同型別的應用希望以多種方式處理 AM 重新啟動的事件。MapReduce 類應用目標是不丟失任務狀態，

但也能允許一部分的狀態損失。但是對於長週期的服務而言，使用者並不希望僅僅由 於 AM 的 故 障 而 導 致 整 個 服 務 停 止 運 行 。 YARN 支 持 在 新 的

ApplicationMaster 啟動時，保留之前 Container 的狀態，因此執行中的作業可以繼續無故障的執行。