負責全局的資源管理和任務調度，把整個集群當成計算資源池，只關注分配，不管應用，且不負責容錯。 ## 資源管理 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. 用戶提交作業到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，超過一定時間則將其回收