Hadoop-YARN

Hadoop - YARN

舊的MapReduce架構

• JobTracker: 負責資源管理，跟蹤資源消耗和可用性，做業生命週期管理（調度做業任務，跟蹤進度，爲任務提供容錯）
• TaskTracker: 加載或關閉任務，定時報告認爲狀態

此架構會有如下問題：

1. JobTracker是MapReduce的集中處理點，存在單點故障
2. JobTracker完成了太多的任務，形成了過多的資源消耗，當MapReduce job 很是多的時候，會形成很大的內存開銷。這也是業界廣泛總結出老Hadoop的MapReduce只能支持4000 節點主機的上限
3. 在TaskTracker端，以map/reduce task的數目做爲資&##x6E90;的表示過於簡單，沒有考慮到cpu/ 內存的佔用狀況，若是兩個大內存消耗的task被調度到了一塊，很容易出現OOM
4. 在TaskTracker端，把資源強制劃分爲map task slot和reduce task slot, 若是當系統中只有map task或者只有reduce task的時候，會形成資源的浪費，也就集羣資源利用的問題

總的來講就是單點問題和資源利用率問題

YARN架構

YARN就是將JobTracker的職責進行拆分，將資源管理和任務調度監控拆分紅獨立#x7ACB;的進程：一個全局的資源管理和一個每一個做業的管理（ApplicationMaster） ResourceManager和NodeManager提供了計算資源的分配和管理，而ApplicationMaster則完成應用程序的運行

• ResourceManager: 全局資源管理和任務調度
• NodeManager: 單個節點的資源管理和監控
• ApplicationMaster: 單個做業的資源管理和任務監控
• Container: 資源申請的單位和任務運行的容器

架構對比

YARN架構下造成了一個通用的資源管理平臺和一個通用的應用計算^#x5E73;臺，避免了舊架構的單點問題和資源利用率問題，同時也讓在其上運行的應用再也不侷限於MapReduce形式

YARN基本流程

1. Job submission

從ResourceManager中獲取一個Application ID 檢查做業輸出配置，計算輸入分片 拷貝做業資源（job jar、配置文件、分片信息）到HDFS，以便後面任務的執行

2. Job initialization

ResourceManager將做業遞交給Scheduler（有不少調度算法，通常是根據優先級）Scheduler爲做業分配一個Container，ResourceManager就加載一個application master process並交給NodeManager管理ApplicationMaster主要是建立一系列的監控進程來跟蹤做業的進度，同時獲取輸入分片，爲每個分片建立一個Map task和相應的reduce task Application Master還決定如何運行做業，若是做業很小（可配置），則直接在同一個JVM下運行

3. Task assignment

ApplicationMaster向Resource Manager申請資源（一個個的Container，指定任務分配的資源要求）通常是根據data locality來分配資源

4. Task execution

ApplicationMaster根據ResourceManager的分配狀況，在對應的NodeManager中啓動Container 從HDFSN#x4E2D;讀取任務所需資源（job jar，配置文件等），而後執行該任務

5. Progress and status update

定時將任務的進度和狀態報告給ApplicationMaster Client定時向ApplicationMaster獲取整個任務的進度和狀態

6. Job completion

Client定時檢查整個做業是否完成 做業完成後，會清空臨時文件、目錄等

YARN - ResourceManager

負責全局的資源管理和任務調度，把整個集羣當&##x6210;計算資源池，只關注分配，無論應用，且不負責容錯

資源管理

1. 之前資源是每一個節點分紅一個個的Map slot和Reduce slot，如今是一個個Container，每一個Container能夠根據須要運行ApplicationMaster、Map、Reduce或者任意的程序
2. 之前的資源分配是靜態的，目前是動態的，資源利用率更高
3. Container是資源申請的單位，一個資源申請格式：<resource-name, priority, resource-requirement, number-of-containers>, resource-name：主機名、機架名或*（表明任意機器）, resource-requirement：目前只支持CPU和內存
4. 用戶提交做#x4F5C;業到ResourceManager，而後在某個NodeManager上分配一個Container來運行ApplicationMaster，ApplicationMaster再根據自身程序須要向ResourceManager申請資源
5. YARN有一套Container的生命週期管理機制，而ApplicationMaster和其Container之間的管理是應用程序本身定義的

任務調度

1. 只關注資源的使用狀況，根據需求合理分配資源
2. Scheluer能夠根據申請的須要，在特定的機器上申請特定的資源（ApplicationMaster負責申請資源時的數據本地化的考慮，ResourceManager將盡可能知足其申請需求，在指定的機器上分配Container，從而減小數據移動）

內部結構

• Client Service: 應用提交、終止、輸出信息（應用、隊列、集羣等的狀態信息）
• Adaminstration Service: 隊列、節點、Client權限管理
• ApplicationMasterService: 註冊、終止ApplicationMaster, 獲取ApplicationMaster的資源申請或取消的請求，並將其異步地傳給Scheduler, 單線程處理
• ApplicationMaster Liveliness Monitor: 接收ApplicationMaster的心跳消息，若是某個ApplicationMaster在必定時間內沒有發送心跳，則被任務失效，其資源將會被回收，而後ResourceManager會從新分配一個ApplicationMaster運行該應用（默認嘗試2次）
• Resource Tracker Service: 註冊節點, 接收各註冊節點的心跳消息
• NodeManagers Liveliness Monitor: 監控每一個節點的心跳消息，若是長時間沒有收到心跳消息，則認爲該節點無效, 同時全部在該節點上的Container都標記成無效，也不會調度任務到該節點運行
• ApplicationManager: 管理應用程序，記錄和管理已完成的應用
• ApplicationMaster Launcher: 一個應用提交後，負責與NodeManager交互，分配Container並加載ApplicationMaster，也負責終止或銷燬
• YarnScheduler: 資源調度分配， 有FIFO(with Priority)，Fair，Capacity方式
• ContainerAllocationExpirer: 管理已分配但沒有啓用的Container，超過必定時間則將其回收

YARN - NodeManager

Node節點下的Container管理

1. 啓動時向ResourceManager註冊並定時發&##x9001;心跳消息，等待ResourceManager的指令
2. 監控Container的運行，維護Container的生命週期，監控Container的資源使用狀況
3. 啓動或中止Container，管理任務運行時的依賴包（根據ApplicationMaster的須要，啓動Container以前將須要的程序及其依賴包、配置文件等拷貝到本地）

內部結構

• NodeStatusUpdater: 啓動向ResourceManager註冊，報告該節點的可用資源狀況，通訊的端口和後續狀態的維護

• ContainerManager: 接收RPC請求（啓動、中止），資源本地化（下載應用須要的資源到本地，根據須要共享這些資源）

  PUBLIC: /filecache</local-dir>

  PRIVATE: /usercache//filecache</local-dir>

  APPLICATION: /usercache//appcache//（在程序完成後會被刪除）</app-id></local-dir>

• ContainersLauncher: 加載或終止Container

• ContainerMonitor: 監控Container的運行和資源使用狀況
• ContainerExecutor: 和底層操做系統交互，加載要運行的程序

YARN - ApplicationMaster

單個做業的資源管理和任務監控

具體功能描述#x8FF0;：

1. 計算應用的資源需求，資源能夠是靜態或動態計算的，靜態的通常是Client申請時就指定了，動態則須要ApplicationMaster根據應用的運行狀態來決定
2. 根據數據來申請對應位置的資源（Data Locality）
3. 向ResourceManager申請資源，與NodeManager交互進行程序的運行和監控，監控申請的資源的使用狀況，監控做業進度
4. 跟蹤任務狀態和進度，定時向ResourceManager發送心跳消息，報告資源的使用狀況和應用的進度信息
5. 負責本做業內的任務的容錯

ApplicationMaster能夠是用任何語言編寫的程序，它和ResourceManager和NodeManager之間是經過ProtocolBuf交互，之前是一個全局的JobTracker負責的，如今每一個做業都一個，可伸縮性更強，至少不會由於做業太多，形成JobTracker瓶頸。同時將做業的邏輯放到一個獨立的ApplicationMaster中，使得靈活性更加高，每一個做業均可以有本身的處理方式，不用綁定到MapReduce的處理模式上

如何計算資源需求

通常的MapReduce是根據block數量來定Map和Reduce的計算數量，而後通常的Map或Reduce就佔用一個Container

如何發現數據的本地化

數據本地化是經過HDFS的block分片信息獲取的

YARN - Container

1. 基本的資源單位（CPU、內存等）
2. Container能夠加載任意程序，並且不限於Java
3. 一#x4E2A;Node能夠包含多個Container，也能夠是一個大的Container
4. ApplicationMaster能夠根據須要，動態申請和釋放Container

YARN - Failover

失敗類型

1. 程序問題
2. 進程崩潰
3. 硬&#x#x4EF6;問題

失敗處理

任務失敗

1. 運行時異常或者JVM退出都會報告給ApplicationMaster
2. 經過心跳來檢查掛住的任務(timeout)，會檢查屢次（可配置）才判斷該任務是否失效
3. 一個做業的任務失敗率超過配置，則認爲該做業失敗
4. 失敗的任務或做業都會有ApplicationMaster從新運行

ApplicationMaster失敗

1. ApplicationMaster定時發送心跳信號到ResourceManager，一般一旦ApplicationMaster失敗，則認爲失敗，但也能夠經過配置屢次後才失敗
2. 一&##x65E6;ApplicationMaster失敗，ResourceManager會啓動一個新的ApplicationMaster
3. 新的ApplicationMaster負責恢復以前錯誤的ApplicationMaster的狀態(yarn.app.mapreduce.am.job.recovery.enable=true)，這一步是經過將應用運行狀態保存到共享的存儲上來實現的，ResourceManager不會負責任務狀態的保存和恢復
4. Client也會定時向ApplicationMaster查詢進度和狀態，一旦發現其失敗，則向ResouceManager詢問新的ApplicationMaster

NodeManager失敗

1. NodeManager定時發送心跳到ResourceManager，若是超過一段時間沒有收到心跳消息，ResourceManager就會將其移除
2. 任何運行在該NodeManager上的#x7684;任務和ApplicationMaster都會在其餘NodeManager上進行恢復
3. 若是某個NodeManager失敗的次數太多，ApplicationMaster會將其加入黑名單（ResourceManager沒有），任務調度時不在其上運行任務

ResourceManager失敗

1. 經過checkpoint機制，定時將其狀態保存到磁盤，而後失敗的時候，從新運行
2. 經過zookeeper同步狀態和實現透明的HA

能夠看出，通常的錯誤處理都是由當前模塊的父模塊進行監控（心跳）和恢復。而最頂端的模塊則經過定時保存、同步狀態和zookeeper來ֹ#x5B9E;現HA