# 8-4 Apache Hadoop YARN: Yet Another Resource Negotiator

## Introduction
:::info
YARN簡介
:::
* Hadoop在大規模、資料密集計算上提供了fault tolerance
* Hadoop成功主要是因為工程師和研究人員可以幾乎無限制的訪問大量計算資源和公司數據
* 其也是其最大的挑戰，Hadoop初始設計將MapReduce程式模型與資源管理緊密結合，這會使開發人員在不是用的情況下仍要使用MapReduce模型
* e.g. 開發者常常提交"map-only" job
* YARN
* 一個下個世代的Hadoop計算平台
* 將資源管理從模型中分離
* 將許多與scheduling相關的功能委派給每個作業的組件
* 這種分散式使框架提供了極大的靈活性
## History and ratonale
:::info
YARN的需求由來: Yahoo!
:::
* 背景與需求:
* Yahoo! 採用Apache Hadoop來替代驅動WebMap應用
* 需求
* 可擴展性: Hadoop具備高可擴展性，
* 多租戶: 由於Yahoo!的不同應用程序而驅動了多租戶需求
* 服務性: Yahoo!開發部署了Hadoop on Demand(HoD)來解決多租戶問題，在shared cluster中，多個用戶和app允許在共享硬體資源，分配Hadoop cluster
* HoD的侷限:
* 資源利用率: 分配節點數量未考慮到數據本地性，使大多數讀取都來自遠端主機
* cluster利用率: 固定cluster導致資源浪費
* shared cluster的挑戰
* 可靠性和可用性: JobTracker單點故障會使整個運行作業中斷
* 多租戶需要強大的認證和授權模型
* MapReduce模型不支援所有大規模計算，需支援多種程式模型
* 固定的map, reduce槽位固定配置會導致資源利用率低
* 故引入了YARN，通過分散資源管理和程式模型，解決Hadoop的可擴展性，可靠性，多租戶等多方面問題，滿足Yahoo!實際的各種需求
## Architecture

:::info
* YARN引入了Resource Manager和Application Master這種分離職責方法來解決挑戰，使資源管理和作業執行協調更高效
* Resource Manager
* YARN每個cluster都有個Resource Manager(RM)
* 職責:
* 來追蹤資源使用情況和節點存活狀態
* 強制執行資源分配的不變式
* 在租戶之間仲裁資源競爭
* 將以上職責從JobTracker中分離出來，中央資源分配器可以抽象描述租戶需求而不需了解分配的語意
* Application Master
* 職責:
* 協調單個作業的邏輯計畫
* 向RM請求資源
* 從獲取的資源生成物理計畫
* 協調計畫在故障下的執行
* 計畫協調工作委派給AM，RM可以專注於資源管理上，而不須了解每個作業詳細的執行過程
:::
### Overview
* RM在專用的機器上進行，用於仲裁資源
* RM具有全局視角，能夠在租戶之間執行公平性，容量，本地性等屬性
* 為了追蹤資源分配，RM與每個節點的NodeManager(NM)進行通訊
* RM和NM通訊式基於heartbeat確保資源訊息的更新
* NM負責監控資源可用性，報告故障和管理容器生命週期
* 工作會提交給RM批准，批准後會放到Scheduler運行，當Scheduler資源足夠則會將狀態轉為"running"
* AM為單個作業的管理者，AM需要多個節點資源來完成工作，故會向RM發出資源請求來獲取容器，AM接著將容器分配給具體任務，NM會啟動這些容器並監控運行狀況

### Resource Manager(RM)
* 公開interface:
* client提交application
* 給AM動態協商資源的interface
* 給NM監控和資源管理存取的內部interface
* RM的職責:
* 將全局cluster狀態與應用程序的資源需求進行匹配
* 確保全局調度屬性得到嚴格執行
* 要準確了解應用程式的資源需求
* AM的資源請求內容
* 容器數量, e.g. "200個容器"
* 每個容器的資源 e.g. "2GB RAM, 一個CPU"
* 本地性的偏好
* 應用程序內請求的優先級
* Scheduler的運作
* 資源分配
* 追蹤，更新並滿足來自AM的資源請求
* RM生成資源容器和授予資源訪問的令牌
* 資源回收請求
* 當cluster資源稀缺時向應用程序提出資源回收請求
* AM可以靈活處理這些搶占請求，例如釋放對其工作不太重義的容器
* 非RM的職責
* 不負責協調應用程式執行和任務容錯
* 不提供運行應用程式的狀態和指標(AM處理)
* 不提供特定框架的已完成作業報告(委派給每個框架的daemon)

### Application Master(AM)
* 應用程序的描述: 可以是一個靜態的進程，一個邏輯的工作描述，甚至是一個長
* AM的運作
* Heartbeat機制
* AM週期性的向RM發送訊號以確認其存活並更新其需求紀錄
* 建立需求模型後，AM會在Heartbeat中向RM編碼其偏好和約束
* 在發Heartbeat訊號後，AM收到綁訂到cluster特定節點的資源綑綁容器租約
* 資源請求和調整
* AM根據RM獲得的容器，可能會更新執行計畫，以適應感知到的資源量
* 生成的進程不綁訂到請求而是綁訂到租約
* AM也會根據收到的容器影響當前和未來請求
* 容器狀態和故障恢復
* RM不解是容器狀態，由AM決定容器退出狀態的成功和失敗語意
* AM本身也是容器運行的容器，因此應要去有故障恢復能力
* YARN提供一些恢復支持，由於容錯和應用語意密切相關，故大部分恢復負擔落在AM上

### Node Manager(NM)
* 為worker的daemon，職責為包括認證容器的租約，管理容器的依賴關係，監控容器執行，並向容器提供一系列服務
* 主要功能:
* 資源報告: 報告該節點上可用資源
* NM註冊到RM後，通過heartbest報告狀態並接收指令
* 容器啟動上下文(CLC):
* 容器描述: YARN中所有容器(包括AM)都由CLC描述，包括環境變數映射，存儲在遠程可訪問存儲中的依賴關系，安全令牌，NM服務的負載和創進進程所需命令
* 租約認證: 驗證租約後NM會配置容器環境
* 啟動容器: NM將所有必要依賴項複製到本地存儲。依賴項可以在應用程序中的容器間或同一租戶啟用的容器間，甚至租戶間共享
* 容器終止
* NM根據RM或AM的指令終止容器。
* 可能情況:
* RM報告其擁有的應用程序已完成
* 調度器決定將其驅逐
* 清理: 當容器退出，NM會清理其本地存儲中的工作目錄，清除容器所擁有的資源
* 健康監控: NM週期性監控物理節點的健康狀況，如本地磁盤問題
* 本地服務
* log聚合: 應用程序完成後，NM會將其stdout/stderr數據上傳到HDFS
* 輔助服務
### Responsibilities of A YARN Application
1. 提交應用程序：通過將AM的CLC傳遞給RM來提交應用程序。
2. AM註冊：當RM啟動AM時，它應該向RM註冊並定期通過心跳協議廣告其存活和需求。
3. 容器啟動：一旦RM分配了一個容器，AM可以構建一個CLC在相應的NM上啟動容器。它還可以監控運行中容器的狀態，並在需要回收資源時停止它。監控容器內完成的工作的進度完全是AM的責任。
4. 工作完成：一旦AM完成其工作，它應該從RM注銷並清潔退出。
### Fault Tolerance and Availability
* RM單點故障:
* RM是單點故障。RM從持久存儲恢復其狀態以初始化
* 恢復過程完成後，會終止cluster所有container，包括活動的AM，然後啟動每個AM的新實例
* NM故障處理:
* NM故障會由RM通過Heartbeat檢測到，會將該節點所有容器標註為已終止，並向所有運行的AM報告故障
* 如果故障是暫時的NM將重新與RM同步，清理本地狀態並繼續運行
* AM也要對節點故障做出反應，可能需要重新執行故障期間在該節點上運行的工作

## Experiments
* 比較對象：與Hadoop 1.0
* CPU利用率：
* Hadoop 1.0 CPU利用率為320%，YARN CPU利用率幾乎翻倍
* 提升主因是因為移除了map和reduce槽位之間的靜態分割，使資源分配更靈活
* 作業處理能力：
* Hadoop 1.0每天處理的作業數量約為77k
* 在YARN上，每天增加到100k，高峰時會150k
* 任務數量也從Ｈadoop 1.0的400萬提升到YARN上的1000萬，高峰1500萬
## Conclusion
* 用來解決Hadoop架構的限制，YARN提供了更大的擴展性，靈活性，效率，支持大量不同框架
* Yahoo!的已經展示了YARN的成功應用，現在已經100％運行在YARN上