一.Hadoop YARN產生背景

• Mapreduce1.0版本固有的問題
  

  • 擴充套件性受限
  • 單點故障
  • 難以支援MR之外的計算
• 資源利用率
  
• 運維成本和資料共享【多計算框架各自為戰，資料共享困難】
  
  •  MR：離線計算框架
     Storm：實時計算框架
     Spark：記憶體計算框架
  • 運維成本 如果採用“一個框架一個叢集”的模式，則可能需要多個管理員管理這些叢集，進而增加運維成本， 而共享模式通常需要少數管理員即可完成多個框架 的統一管理。
• 資料共享
  
  • 隨著資料量的暴增，跨叢集間的資料移動不僅需花 費更長的時間，且硬體成本也會大大增加，而共享叢集模式可讓多種框架共享資料和硬體資源，將大大減小資料移動帶來的成本。

二. Hadoop YARN基本構成與資源排程

1.YARN基本架構

• YARN基本架構
  
• ResourceManager
  
  • 整個叢集只有一個，負責叢集資源的統一管理和排程
  • 詳細功能
    處理客戶端請求
    啟動/監控ApplicationMaster
    監控NodeManager
    資源分配與排程
• NodeManager
  
  • 整個叢集有多個，負責單節點資源管理和使用
  • 詳細功能
    單個節點上的資源管理和任務管理
    處理來自ResourceManager的命令
    處理來自ApplicationMaster的命令
• ApplicationMaster
  
  • 每個應用有一個，負責應用程式的管理
  • 詳細功能
    資料切分
    為應用程式申請資源，並進一步分配給內部任務
    任務監控與容錯
• Container
  
  • 對任務執行環境的抽象
  • 描述一系列資訊
    任務執行資源（節點、記憶體、CPU）
    任務啟動命令
    任務執行環境

2.YARN執行過程

3.YARN的容錯性

• ResourceManager
  存在單點故障；
  正在基於ZooKeeper實現HA。
• NodeManager
  失敗後，RM將失敗任務告訴對應的AM；
  AM決定如何處理失敗的任務。
• ApplicationMaster
  失敗後，由RM負責重啟；
  AM需處理內部任務的容錯問題；
  RMAppMaster會儲存已經執行完成的Task，重啟後無需重新執行。

4.YARN排程框架

• 雙層排程框架
  RM將資源分配給AM
  AM將資源進一步分配給各個Task
• 基於資源預留的排程策略
  資源不夠時，會為Task預留，直到
  資源充足
  與“all or nothing”策略不同（Apache Mesos）

5.YARN資源排程器

• 多型別資源排程
  
  • 採用DRF演算法
    （論文：“Dominant Resource Fairness: Fair Allocation of Multiple Resource Types”）
    目前支援CPU和記憶體兩種資源
• 提供多種資源排程器
  
  • FIFO
  • Fair Scheduler
  • Capacity Scheduler
• 多租戶資源排程器
  
  • 支援資源按比例分配
  • 支援層級佇列劃分方式
  • 支援資源搶佔

6.YARN資源隔離方案

• 支援記憶體和CPU兩種資源隔離
  
  • 記憶體是一種“決定生死”的資源
  • CPU是一種“影響快慢”的資源
• 記憶體隔離
  
  • 基於執行緒監控的方案
  • 基於Cgroups的方案
• CPU隔離
  
  • 預設不對CPU資源進行隔離
  • 基於Cgroups的方案

7.YARN支援的排程語義

• 支援的語義
  
  • 請求某個特定節點/機架上的特定資源量
  • 將某些節點加入（或移除）黑名單，不再為自己分配這些節點上的資源
  • 請求歸還某些資源
• 不支援的語義
  
  • 請求任意節點/機架上的特定資源量
  • 請求一組或幾組符合某種特質的資源
  • 超細粒度資源
  • 動態調整Container資源

三.Hadoop YARN上的計算框架

1.YARN設計目標

• 通用的統一資源管理系統
  
  • 同時執行長應用程式和短應用程式
• 長應用程式
  
  • 通常情況下，永不停止執行的程式
  • Service、HTTP Server等
• 短應用程式
  
  • 短時間（秒級、分鐘級、小時級）內會執行結束的程式
  • MR job、Spark Job等

2.以YARN為核心的生態系統

【1】離線計算框架：MapReduce

• 將計算過程分為兩個階段，Map和Reduce
  
  • Map 階段並行處理輸入資料
  • Reduce階段對Map結果進行彙總
• Shuffle連線Map和Reduce兩個階段
  
  • Map Task將資料寫到本地磁碟
  • Reduce Task從每個Map Task上讀取一份資料
• 僅適合離線批處理
  
  • 具有很好的容錯性和擴充套件性
  • 適合簡單的批處理任務
• 缺點明顯
  
  • 啟動開銷大、過多使用磁碟導致效率低下等

【2】DAG計算框架：Tez

• 多個作業之間存在資料依賴關係，並形成一個依賴關係有向 圖（ Directed Acyclic Graph），該圖的計算稱為“DAG計算”
• Apache Tez：基於YARN的DAG計算框架
  
  • 執行在YARN之上，充分利用YARN的資源管理和容錯等功能；
  • 提供了豐富的資料流(dataflow）API；
  • 擴充套件性良好的“Input-Processor-Output”執行時模型；
  • 動態生成物理資料流關係。
    
    未使用Tez
    
    使用Tez
    

Tez 應用場景

• 直接編寫應用程式
  
  • Tez提供了一套通用程式設計介面
  • 適合編寫有依賴關係的作業
• 優化Pig、Hive等引擎
  
  • 下一代Hive：Stinger
  • 好處1：避免查詢語句轉換成過多的MapReduce作業後產 生大量不必要的網路和磁碟IO
  • 好處2：更加智慧的任務處理引擎

【3】流式計算框架：Storm

• 流式（Streaming）計算，是指被處理的資料像流水一樣不斷流入系統，而系統需要針對每條資料進行實時處理和計算，並永不停止（直到使用者顯式殺死程序）；
• 傳統做法：由訊息佇列和訊息處理者組成的實時處理網路 進行實時計算；
  
  • 缺乏自動化
  • 缺乏健壯性
  • 伸縮性差
    
    
    

【4】記憶體計算框架：Spark

• 克服MapReduce在迭代式計算和互動式計算方面的不足；
• 引入RDD（ Resilient Distributed Datasets）資料表示模型；
• RDD是一個有容錯機制，可以被並行操作的資料集合，能夠被快取到記憶體或磁碟上。

spark on yarn

四.MapReduce 2.0與YARN

• 一個MR應用程式的成功執行需要若干模組：
  
  • 任務管理和資源排程
  • 任務驅動模組（MapTask、ReduceTask）
  • 使用者程式碼（Mapper、Reducer…）
• MapReduce 2.0和YARN區別：
  
  • YARN是一個資源管理系統，負責資源管理和排程
  • MapReduce只是執行在YARN上的一個應用程式
  • 如果把YARN看做“ android”，則MapReduce只是一個“ app”
• MapReduce2.0組成：
• YARN(整個叢集只有一個)
• MRAppMaster（一個應用程式一個）
• 使用者程式碼（ Mapper、 Reducer…）
• MapReduce 1.0和MapReduce 2.0區別：
  
  • MapReduce 1.0是一個獨立的系統，直接執行在Linux之上
  • MapReduce 2.0則是執行YARN上的框架，且可與多種框架一起 執行在YARN上

五.總結

本部落格主要介紹了YARN的產生背景，整體架構，執行在yarn上面的hadoop生態系統，最後介紹了Mapreduce2.0與YARN的區別。YARN是一個資源排程的框架和平臺，可以理解為一個作業系統，在這個“作業系統上面可以安裝執行N多個軟體，比如storm，spark等系統，完成某一項特定的功能。YARN的功能就是為這些應用提供資源和任務調動，HDFS就相當於一塊硬碟，用來儲存軟體系統所需要的資料。