Yarn（MapReduce V2）

這裏咱們先說一下MapReduce V1的侷限性：

• JobTracker單點瓶頸。MapReduce中的JobTracker負責做業的分發、管理和調度，同時還必須和集羣中全部的節點保持Heartbeat通訊，瞭解機器的運行狀態和資源狀況。很明顯，MapReduce中獨一無二的JobTracker負責了太多的任務，若是集羣的數量和提交Job的數量不斷增長，那麼JobTracker的任務量也會隨之快速上漲，形成JobTracker內存和網絡寬帶的快速消耗。這樣的最終結果就是JobTracker成爲集羣的瓶頸，成爲集羣做業的中心點和風險的核心。
• TaskTracker端，因爲做業分配信息過於簡單，有可能將多個資源消耗多或運行時間長的Task分配到同一個Node上，這樣會形成做業的單點失敗或等待時間過長。
• 做業延遲太高。在MapReduce運行做業以前，須要TaskTracker彙報本身的資源狀況和運行狀況，JobTracker根據獲取的信息分配做業，TaskTracker獲取任務以後開始運行。這樣的結果是通訊的延遲形成做業啓動時間過長。最顯著的影響是小做業並不能及時完成。
• 編程框架不夠靈活。雖然如今的MapReduce框架容許用戶本身定義各個階段的處理函數與對象，可是MapReduce框架仍是限制了編程的模式及資源的分配。

針對以上問題，MapReduce的設計者提出了下一代Hadoop MapReduce框架（官方稱爲MRv2/YARN）。

YARN(MapReduce V2)設計需求

• 可靠性（Reliability）。
• 可用性（Availability）。
• 擴展性（Scalability）。集羣支持擴展到10000個節點和200000個核心。
• 向後兼容性（Backward Compatibility）。保證用戶基於MapReduce V1編寫的程序無須修改就能運行在MapReduce V2上。
• 演化。使用戶可以控制集羣中軟件的升級。
• 可預測延遲（Predictable Latency）。提升小做業的反應和處理速度。
• 集羣利用率。好比Map Task和Reduce Task的資源共享等。
• 支持除了MapReduce編程框架外的其餘框架。這樣可以擴大MapReduce V2的適用人羣。
• 支持受限和短時間的服務

YARN(MapReduce V2)主要思想和架構

     鑑於MapReduce V2的設計需求和MapReduce V1中凸顯的問題，特別是JobTracker單點瓶頸問題（此問題影響着Hadoop集羣的可靠性、可用性和擴展性），MapReduce V2的主要設計思路是將JobTracker承擔的兩大塊任務—集羣資源管理和做業管理進行分離（其中分離出來的集羣資源管理由全局的資源管理器（ResourceManager）管理，分離出來的做業管理由針對每一個做業的應用主題（ApplicationMaster）管理），而後TaskerTracker演化成節點管理器（NodeManger）。這樣全局的資源管理器和局部的節點管理器就組成了數據計算框架，其中資源管理器將成爲整個集羣中資源最終的分配者。針對做業的應用主體就成爲具體的框架庫，負責兩個任務:與資源管理器通訊獲取資源，與節點管理器配合完成節點的Task任務。

　　　　　　　　　　圖 1      MapReduce V2結構圖

（1）資源管理器

      根據功能不一樣將資源管理器分紅兩個組件：調度器（scheduler）和應用管理器（ApplicationManager）。調度器根據集羣中容量、隊列和資源等限制，將資源分配給各個正在運行的應用。雖然被稱爲調度器，可是它僅負責資源的分配，而不負責監控各個應用執行狀況和任務失敗、應用失敗或硬件失敗時的重啓任務。調度器根據各個應用的資源需求和集羣各個節點的資源容器（Resource Containner，是集羣節點將自身內存、CPU、磁盤等資源封裝在一塊兒的抽象概念）進行調度。應用管理器負責接收做業，協商獲取第一個資源容器用於執行應用的任務主體併爲重啓失敗的應用主體分配容器。

（2）節點管理器

     節點管理器是每一個節點的框架代理。它負責啓動應用的容器，監控容器的資源使用（包括CPU、內存、硬盤和網絡帶寬等），並把這些信息彙報給調度器。應用對應的應用主體經過協商從調度器處獲取資源容器，並跟蹤這些容器的狀態和應用執行狀況。

    集羣每一個節點上都有一個節點管理器，它主要負責:

    a.爲應用啓用調度器已分配給應用的容器。

    b.保證已啓動的容器不會使用超過度配的資源量。

    c.爲task構建容器環境，包括二進制可執行文件,jar等；

    d.爲全部的節點提供一個管理本地存儲資源的簡單服務。

    應用程序能夠繼續使用本地存儲資源，即便它沒有從資源管理器處申請。好比：MapReduce能夠利用這個服務存儲Map Task的中間輸出結果並將其shuffle給Reduce　 Task。

（3）應用主體

     應用主體和應用是一一對應的。它主要有如下職責：

      a.與調度器協商資源

　　b.與節點管理器合做，在合適的容器中運行對應的組件Task，並監控這些Task執行；

　　c.若是container出現故障，應用主體會重複向調度器申請其餘資源；

　　d.計算應用程序所需的資源量，並轉換成調度器可識別的協議信息包；

　　e.在應用主體出現故障後，應用管理器會負責重啓它，但由應用主體本身從以前保存的應用程序執行狀態中恢復應用程序。

 

　　　　　　　　　　　　　　圖2    應用主體組件事件流

　　1）事件調度組件，是應用主體中各個組件的管理者，負責爲其餘組件生成事件。

　　2）容器分配組件，負責將Task的資源請求翻譯成發送給調度器的應用主體的資源請求，並與資源管理器協商獲取資源。

　　3）用戶服務組件，將做業的狀態、計數器、執行進度等信息反饋給Hadoop Mapreduce的用戶。

　　4）任務監聽組件，負責接收Map或Reduce Task發送的心跳信息。

　　5）任務組件，負責接收Map或Reduce Task造成的心跳信息和狀態更新信息。

　　6）容器啓動組件，經過使節點管理器運行來負責容器的啓動。

　　7）做業歷史事件處理組件，將做業運行的歷史事件寫入HDFS。

　　8）做業組件，維護做業和組件的狀態。

（4）資源容器

      在MapReduce V2中，系統資源的組織形式是將節點上的可用資源分割，每一份經過封裝組織成系統的一個資源單元，即container（好比固定大小的內存分片，CUP核心數，網絡帶寬量和硬盤空間塊等。在如今提出的MapReduce V2中，所謂資源是指內存資源，每一個節點由多個512MB或1G大小的內存容器組成）。而不是像MapReduce V1中那樣，將資源組織成Map池和Reduce池。應用主體能夠申請任意多個內存整數倍大小的容器。因爲將每一個節點的內存資源分割成了大小固定、地位相同的容器，這些內存容器就能夠再任務執行中進行互換，從而提交利用率，避免了在MapReduce V1中做業在Reduce池上的瓶頸問題和缺少資源互換的問題。資源容器的主要職責就是運行、保存或傳輸應用主體提交的做業或須要存儲和傳輸的數據。

 MapReduce V2設計細節

      上面介紹了MapReduce V2的主體設計思想和架構及其各部分的主要職責，下面將詳細一些設計細節。

      1.資源協商

      應用主體經過適當的資源需求描述來申請資源容器，能夠報考一些指定的機器節點。應用主體還能夠請求同一臺機器上的多個資源容器。全部的資源請求受應用程序容量和隊列容量等的限制。因此爲了搞笑地分配集羣的資源容器，應用主體須要計算應用的資源需求，而且把這些需求封裝到調度器可以識別的協議信息包中，好比<priority,(host,rack,*),memory,#containers>。以MapReduce爲例，應用主體分析input-splits並將其轉化成以host爲key的轉置表發送給資源管理器，發送的信息中還包括在其執行期間隨着執行的進度應用對資源容器須要的變化。調度器解析出應用主體的請求信息以後，會盡可能分配請求的資源給應用主體。若是指定機器上的資源不可用，還能夠將同一機器或者不一樣機器上的資源分配給應用主體。在有些狀況下，因爲整個集羣很是忙碌，應用主體獲取的資源可能不是最合適的，此時它能夠拒絕這些資源並請求從新分配。

　   從上面介紹的資源協商的過程能夠看出，MapReduce V2中的資源並再也不是來自Map池和reduce池，而是來自統一的資源容器，這樣應用主體能夠申請所需數量的資源，而不會由於資源並不是所需類型而掛起。須要注意的是，調度器不容許應用主體無限制地申請資源，它會根據應用限制，用戶限制，隊列限制和資源限制等來控制應用主體申請到的資源規模，從而保證集羣資源不被浪費。

      2.調度

      調度器收集全部正在運行應用程序的資源請求並構建一個全局的資源分配計劃。調度器會根據應用程序相關的約束（如合適的機器）和全局約束（如隊列資源總量，隊列限制，用戶限制等）分配資源。調度器使用與容器調度相似的概念，採用容量保證做爲基本的策略在多個競爭關係的應用程序間分配資源。調度器的調度步驟以下:

　　1）選擇系統中「最低服務」的隊列。這個隊列可使等待時間最長的隊列，或者等待時間和已分配資源之比最大的隊列等。

　　2）從隊列中選擇擁有最高優先級的做業。

　　3）知足被選出的做業的資源請求。

　　MapReduce V2中只有一個接口用於應用主體向調度器請求資源。接口以下：

　　Response allocate（list<ResourceRequest> ask, List<Container> release）

　　應用主體使用這個接口中的ResourceRequest列表請求特定的資源，同時使用接口中的Container列表告訴調度器本身釋放的資源容器。

　　調度器接收到應用主體的請求以後會根據本身的全局計劃及各類限制返回對請求的回覆。回覆中主要包括三類信息：最新分配的資源容器列表、在應用主體和資源管理器上次交互以後完成任務的應用指定資源容器的狀態、當前集羣中應用程序可用的資源數量。應用主體能夠收集完成容器的信息並對失敗任務做出反應。可用資源量能夠爲應用主體接下來的自願申請提供參考，好比應用主體可使用這些信息來合理分配Map和Reduce各自請求的資源數量，進而防止死鎖（最明顯的狀況是Reduce請求佔用全部的剩餘可用資源）。

　   3.資源監控

 　　調度器按期從節點管理器處收集已分配資源的使用信息。同時，調度器還會將已完成任務容器的狀態設置爲可用，以便有需求的應用申請使用。

　　4.應用提交

      如下是應用提交的步驟。

　　1）用戶提交做業到應用管理器。具體的步驟是在用戶提交做業之後，MapReduce框架爲用戶分配一個新的應用ID，並將應用的定義打包上傳到HDFS上用戶的應用緩存目錄中。最後提交此應用給應用管理器。

　　2）應用管理器接受應用提交。

　　3）應用管理器同調度器協商獲取運行運行應用主體所需的第一個資源容器，並執行應用主體。

　　4）應用管理器將啓動的應用主體細節返還給用戶，以便其監督應用進度。

　　5.應用管理器組件

　　應用管理器負責啓動系統中全部應用主體並管理其生命週期。在啓動應用主體以後，應用管理器經過應用主體按期發送的「心跳」來監督應用主體，保證其可用性，若是主體失敗，就須要將其重啓。

　　爲了完成上述任務，應用管理器包含如下組件：

　　1）調度協商組件，負責與調度器協商應用主體所須要的資源容器。

　　2）應用主體容器管理組件，負責經過與節點管理器通訊來啓動或中止應用主體容器。

　　3）應用主體監控組件，負責監控應用主體的狀態，保持其可用，而且在必要的狀況下重啓應用主體。

     6.MapReduce V2做業執行流程

　　因爲主要組件發生了更改，MapReduce V2中的做業執行流程也有所變化。做業的執行流程圖以下所示（僅說明主要的流程，一些反饋流程和心跳通訊並未標註）。

　　　　　　圖 3  MapReduce V2做業執行流程

      步驟1：MapReduce框架接收用戶提交的做業，併爲其分配一個新的應用ID，併爲其分配一個新的應用ID，並將應用的定義打包上傳到HDFS上用戶的應用緩存目錄中，而後提交此應用給應用管理器。

　　步驟2：應用管理器同調度器協商獲取運行應用主體所需的第一個資源容器。

　　步驟3：應用管理器在獲取的資源容器上執行應用主體。

　　步驟4：應用主體計算應用所需的資源，併發送資源請求到調度器。

　　步驟5：調度器根據自身統計的可用資源狀態和應用主體的資源請求，分配合適的資源容器給應用主體。

　　步驟6: 應用主體與所分配容器的節點管理器通訊，提交做業狀況和資源使用說明。

　　步驟7：節點管理器啓用容器並運行任務。

　　步驟8：應用主體監控容器上任務的執行狀況。

　　步驟9：應用主體反饋做業的執行狀態信息和完成狀態。

　　7. MapReduce V2系統可用性保證

　　系統可用性主要指 MapReduce V2中各個組件的可用性，即保證能使其在失敗以後迅速恢復並提供服務，好比保證資源管理器、應用主體等的可用性。首先介紹MapReduce V2如何保證MapReduce 應用和應用主體的可用性。在以前已有介紹，資源管理器中的應用管理器負責監控MapReduce 應用主體的執行狀況。在應用主體發生失敗以後，應用管理器僅重啓應用主體，再由應用主體恢復某個特定的MapReduce做業。應用主體在恢復MapReduce做業時，有三種方式可供選擇：徹底重啓MapReduce做業；重啓未完成的Map和Reduce任務；嚮應用主體標明失敗時正在運行的Map和Reduce任務，而後恢復做業執行。第一種方式的代價比較大，會重複工做；第二種方法效果較好，但仍有可能重複Reduce任務的部分工做；第三種方式最爲理想，從失敗點直接從新開始，沒有任何重複工做，但這種方式對系統的要求太高。在MapReduce V2中選擇第二種恢復方式，具體實現方式是：應用管理器在監督MapReduce任務執行的同時記錄日誌，標明已完成的Map和Reduce任務；在恢復做業時，分析日誌後重啓未完成的任務便可。

　　接下來介紹MapReduce如何保證資源管理器的可用性。資源管理器在運行服務過程當中，使用ZooKeeper保存資源管理的狀態，包括應用管理器進程狀況、隊列定義、資源分配狀況、節點管理器狀況等信息。在資源管理器失敗以後，由資源管理器根據本身的狀態進行自我恢復。

      8.MapReduce  V2的優點

　　1）分散了JobTracker的任務。資源管理任務由資源管理器負責，做業啓動、運行和檢測任務由分佈正在集羣節點上的應用主體負責。這樣大大減緩了MapReduce V1中JobTracker單點瓶頸和單點風險的問題，大大提升了集羣的擴展性和可用性。

　　2）在MapReduce V2中應用主體（ApplicationMaster）是一個用戶可自定製的部分，所以用戶能夠針對編程模型編寫本身的應用主體程序。這樣大大擴展了MapReduce V2的適用範圍。

　　3）在資源管理器上適用ZooKeeper實現故障轉移。當資源管理器故障時，備用資源管理器將根據保存在ZooKeeper中的集羣狀態快速啓動。MapReduce V2支持應用程序指定檢查點。這就能保證應用主體在失敗後能迅速的根據HDFS上保存的狀態重啓。這兩個措施大大提升了MapReduce V2的可用性。

　　4）集羣資源統一組織成資源容器，而不像MapReduce V1中的Map和Reduce池有所差異。這樣只要有任務請求資源，調度器就會將集羣中的可用資源分配給請求任務，而無關資源類型。這樣大大提升了集羣資源的利用率。

 

參考資料：Hadoop實戰 第2版 陸嘉恆著