YARN與MRv1的對比

YARN與MRv1的對比

---

轉載請註明出處：http://www.cnblogs.com/BYRans/

Hadoop 1.0存在的問題

因爲Hadoop 1.0的良好特性，Hadoop 1.0被應用到了各行各業。可是Hadoop的最初設計是爲了用於搜索引擎業務（如Yahoo、Google等公司），其最初的設計中存在的一些問題逐漸凸現出來。主要存在如下幾個方面：

• 存在單點故障，影響可擴展性和穩定性
  Hadoop 1.0中HDFS的NameNode和MapReduce的JobTracker設計爲單一節點，這將是整個系統的單點故障源（SPOF）。單點故障主要由如下兩個緣由致使：
  • NameNode內存消耗過大
    DataNode會按期向NameNode發送Block Report，這些數據是佔用內存空間的，隨着Hadoop集羣存儲空間的增多，這些Block Report會愈來愈多，所以NameNode的內存容量成爲制約Hadoop集羣的一個重要因素。
  • JobTracker內存消耗過大
    隨着JobTracker處理的job數量的增加，任務數量也隨着增加，從而致使JobTracker的內存消耗過大，同時任務失敗的機率也隨着增長。
    
• 資源管理方案不靈活
  • slot數目沒法動態修改。Hadoop 1.0採用了靜態slot資源設置策略，即每一個節點實現配置好可用的slot總數，這些slot數目一旦啓動後沒法再動態修改。
  • 資源沒法共享。Hadoop 1.0將slot分爲Map slot和Reduce slot兩種，且不容許共享。對於一個做業，剛開始運行時，Map slot資源緊缺而Reduce slot空閒，當Map Task所有運行完成後，Reduce slot緊缺而Map slot空閒。很明顯，這種區分slot類別的資源管理方案在必定程度上下降了slot的利用率。
  • 資源劃分粒度粗糙。這種基於slot的資源劃分方法的劃分粒度仍過於粗糙，每每會形成節點資源利用率太高或者太低。好比，Hadoop默認爲每一個slot分配2G內存和1個CPU，若是一個應用程序的任務只須要1GB內存，則會產生「資源碎片」，從而下降集羣資源的利用率；一樣，若是一個應用程序的任務須要3GB內存，則會隱式地搶佔其餘任務的資源，從而產生資源搶佔現象，可能致使集羣利用率太高。另外，slot只是從內存和CPU的角度對資源進行分配，在實際系統中，資源自己是多維度的，例如：CPU、內存、網絡I/O和磁盤I/O等。
  • 沒引入有效的資源隔離機制。Hadoop 1.0僅採用了基於jvm的資源隔離機制，這種方式仍過於粗糙，不少資源，好比CPU，沒法進行隔離，這會形成同一個節點上的任務之間干擾嚴重。
• 計算模式單一。只支持MapReduce模式，不能有效的支持Storm、Spark等計算框架。

舉個栗子，假設Hadoop 1.0同時運行10個job，每一個job有100個task，假設每一個task運行在不一樣的機器上，那麼，就有10000個幾點在同時運行。若是每一個節點（即每一個task）每一個5分鐘向JobTracker發送心跳，那麼JobTracker節點的壓力會特別大，因此正常狀況下Hadoop 1.0的集羣規模只能達到4000臺左右。JobTracker壓力太重也是形成Hadoop 1.0單點故障和可擴展性差的重要緣由。

YARN的改進

在Hadoop 1.0中JobTracker主要完成兩項功能：資源的管理和做業控制。在集羣規模過大的場景下，JobTracker壓力太重，所以在YARN的設計中，資源的管理和做業控制是分離開的。取代JobTracker的是ResourceManager、ApplicationMaster、NodeManager三個部分。以下圖所示：

• Resource Manager是一個全局的資源管理器 ，它作的事情是調度、啓動每個Job所屬的ApplicationMaster、另外監控ApplicationMaster的存在狀況。注：RM只負責監控AM，在AM運行失敗時候啓動它，RM並不負責AM內部任務的容錯，這由AM來完成。
• ApplicationMaster是每個Job（不是每一種）都有的一個部分，ApplicationMaster能夠運行在ResourceManager之外的機器上。
• NodeManager是ResourceManager的在每一個節點的代理，負責 Container 狀態的維護，並向RM保持心跳。
• 另外，YARN使用Container對資源進行抽象，它封裝了某個節點上必定量的資源（如今YARN僅支持CPU和內存兩種資源）。當AM向RM申請資源時，RM爲AM返回的資源使用Container表示。YARN會爲每一個任務分配一個或多個Container，且該任務只能使用該Container中描述的資源。注：AM也是運行在一個Container中。

YARN設計的優勢

• 將資源管理和做業控制分離，減少JobTracker壓力
  • YARN的設計大大減少了 JobTracker（也就是如今的 ResourceManager）的資源消耗，而且讓監測每個 Job 子任務 (tasks) 狀態的程序分佈式化了，更安全、更優美。
  • 老的框架中，JobTracker一個很大的負擔就是監控job下的tasks的運行情況，如今，這個部分就扔給ApplicationMaster作了而ResourceManager中有一個模塊叫作ApplicationsManager(ASM)，它負責監測ApplicationMaster的運行情況。
• 可以支持不一樣的計算框架
  將計算框架和底層存儲調度分開，以支持更多的計算框架。在YARN中ApplicationMaster是一個可變動的部分，用戶能夠對不一樣的計算框架寫本身的 AppMst，讓更多類型的計算框架可以跑在Hadoop集羣中，能夠參考YARN官方配置模板中的mapred-site.xml配置。
• 資源管理更加合理
  • 使用Container對資源進行抽象，Container不一樣於MRv1中的slot，它是一個動態資源劃分單位，是根據應用程序的需求動態生成的，比以前以slot數目更合理。
  • 且使用了輕量級資源隔離機制Cgroups進行資源隔離。
  • Container的設計避免了以前的map slot/reduce slot分開形成集羣資源閒置的尷尬狀況。

YARN與Mesos的對比

	Mesos	YARN
框架擔任的角色	各個計算框架需在Mesos中部署後才能使用，徹底融入到Mesos中	計算框架只是做爲客戶端的庫使用，不在YARN中部署便可使用
調度機制	雙層調度；第一層由Mesos Master將空閒資源分配給框架，第二層由各個框架自帶的調度器對資源的使用進行分配	雙層調度，第一層由RM分配資源，第二層再對框架的任務進行調度
資源分配	先粗粒度分配，再細粒度分配	細粒度分配
資源隔離性	採用Linux Container對內存和CPU兩種資源進行隔離	當前採用OS進程級別隔離
擴展性	支持6,000 ~ 50,000個節點	目標是支持6,000 ~ 100,000個節點

YARN的不足與展望

YARN是一個雙層調度器（Two-level scheduler），解決了中央調度器（Monolithic scheduler）的不足（中央調度器典型的表明就是JobTracker)，雙層調度架構看上去爲調度增長了靈活性和併發性，但實際上它保守的資源可見性和上鎖算法（使用悲觀併發）也限制了靈活性和併發性。第一，保守的資源可見性致使各框架沒法感知整個集羣的資源使用狀況，有空閒資源沒法通知排隊的進程，容易形成資源的浪費；第二，上鎖算法下降了併發性，調度器會將資源分配給一個架構，只有該架構返回資源後，調度器纔回將該部分資源分配給其餘架構，在第一個分配過程當中，資源至關於被鎖住，從而下降了併發性。總結來講，YARN同其餘雙層架構的調度器（例如：Mesos）都有的不足爲：

• 各個應用沒法感知集羣總體資源的使用狀況，只能等待上層調度推送信息。
• 資源分配採用輪詢、ResourceOffer機制（mesos)，在分配過程當中使用悲觀鎖，併發粒度小。
• 缺少一種有效的競爭或優先搶佔的機制。

爲了改善雙層調度系統的的不足，尤爲是各個應用沒法感知集羣總體資源的使用狀況和悲觀加鎖控制致使的併發性不高這兩個不足，共享狀態調度器（Shared State Scheduler）被愈來愈多的人所重視，其中最具表明性的就是Google的Omega。共享狀態調度器在雙層調度器的基礎上作了改進：

• 簡化了雙層調度器中的全局資源管理器，改成由一個Cell State來記錄集羣內的資源使用狀況，這些使用狀況都是共享的數據，以此來達到與全局資源管理器相同的效果。
• 全部任務訪問共享數據時，採用樂觀併發控制方法。

共享調度器也存在不足。例如，當某一資源被不一樣任務同時訪問時容易產生衝突，訪問的任務越多時，衝突次數就會越多，衝突次數越高調度器的性能降低越快，這將影響調度器的工做效率和工做性能。