Yarn（MapReduce V2）

標籤：blog   http   使用   strong   檔案   資料   

這裡我們先說一下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版 陸嘉恒著