# 8-4. Apache Hadoop YARN

:::info
**過去**：Apache Hadoop 的初始設計專注在執行大量 MapReduce 作業來處理網路爬蟲。

**現況**：Hadoop 已成為資料和運算市集（共享和存取資料和運算資源的場所），遠遠超出了預期的目標，因而暴露了兩個關鍵的缺陷：
- 特定程式設計模型與資源管理的緊密耦合，迫使開發人員**濫用MapReduce 程式設計模型**
- 集中化處理作業的控制流程，導致沒有盡頭的**排程器可擴展性問題**

**本文**：總結了下一代 Hadoop 運算平台YARN的設計、開發和部署現狀。
- 將程式設計模型與資源管理基礎架構解耦
- 將許多調度功能（例如，任務容錯）委託給每個應用程式元件
:::

## 介紹

Apache Hadoop 是專注在解決索引網路爬蟲所需的前所未有的規模，特別調整成了適用該情況（對大量資料密集運算的強大容錯能力）的執行架構。

而 Hadoop 變成了工程師和研究人員即時且幾乎不受限制地存取大量運算資源和公司資料寶庫，此為 Hadoop 的成功之處，卻也是失敗的所在，因為開發人員將 MapReduce 程式設計模型延伸到了叢集管理底層的能力以外的範圍。

故本文提出了 Hadoop 的下一代計算平台 YARN，和原本熟悉的一體式的架構不同，透過**將資源管理功能與程式設計模型分離**，YARN **將許多與排程相關的功能委託給每個作業組件**。MapReduce 只是運行在 YARN 之上的應用程式之一。這種分離為程式框架的選擇提供很大的靈活性。YARN 上可用的替代程式設計模型的範例包括：Dryad、Giraph、Hoya、REEF、Spark、Storm 和 Tez。在 YARN 上運行的程式框架可以根據需要協調應用程式內部通訊、執行流程和動態進行最佳化，從而實現顯著的效能改進。

我們從早期架構師和實作者的角度描述了 YARN 的誕生、設計、開源開發和部署。

## （需求的）歷史和理由

YARN 的需求如何從實際需求中產生的歷史紀錄，不感興趣者可以跳過本節。

YARN 的**需求**整理：
1. Scalability 可擴展性
1. Multi-tenancy 多租戶
1. Serviceability 可維護性
1. Locality awareness 區域性意識
1. High Cluster Utilization 高叢集使用率
1. Reliability/Availability 可靠性/可用性
1. Secure and auditable operation 安全且可審計的操作
1. Support for Programming Model Diversity 支援多樣的程式設計模型
1. Flexible Resource Model 靈活的資源模型
1. Backward compatibility 向後兼容

## 架構

YARN 將資源管理提升到**平台**層面，把邏輯執行計畫(logical execution plan)的協調留給一群**框架**去實作。每個叢集的資源管理器 (RM) 負責追蹤資源使用和節點存活狀態，執行資源分配規則，並在租戶之間調解資源爭用。這些職責從 JobTracker 分離出來，使中央分配器只需了解租戶需求的抽象描述，不需要知道每個分配的細節。應用程式管理器 (AM) 則負責協調單個任務的邏輯計劃(logical plan)，向 RM 請求資源，根據獲得的資源產生物理計劃(physical plan)，並在故障時協調計劃執行。


> 縮寫
> **RM**: Resource Manager 資源管理器
> **NM**: Node Manager 節點管理器
> **AM**: Application Master 應用程式管理器

:::warning
### 概觀

**資源管理器(RM)的角色及功能**

RM 作為後台服務在指定的機器上執行，負責集中仲裁。根據應用程式需求、排程優先權和可用資源，RM 動態分配租約（即容器），讓應用程式在特定節點上執行。為了加強對資源分配的追蹤，RM 與節點管理器 (NM) 透過心跳通訊（考慮到擴展性）。NM 負責監控資源可用性、回報錯誤和管理容器生命週期，而 RM 則整合所有 NM 的狀態。

**任務提交和執行的流程**
1. **提交任務**：任務透過公共提交協議提交給資源管理器 (RM)。
2. **准入控制**：進入准入控制階段(admission control phase)，進行安全憑證驗證和各種操作與管理檢查。
3. **接受任務**：被接受的任務傳送給排程器進行執行。
4. **資源分配**：排程器獲得足夠資源後，將應用程式狀態從接受(accepted)轉為運行中(running)。
5. **啟動 AM**：
- 分配容器給應用程式管理器 (AM)
- 在集群中的節點上啟動 AM
6. **持久存儲**：將接受的應用程式記錄寫入持久存儲，以便在 RM 重啟或故障時恢復。

**應用程式管理器(AM)的角色及功能**

AM是任務的主控制者，負責資源的動態增減、管理執行流程、處理故障和計算偏差，以及執行其他本地最佳化等等生命週期面向上的管理。實際上，AM 可以運行任意使用者用任何程式語言撰寫的程式碼，只要滿足對 RM 和 NM 的通訊協議要求即可。透過將這些功能委派給 AM，YARN 的架構獲得了很大的擴展性、程式設計模型靈活性，以及可能的改進升級/測試（同一框架的多個版本可以共存）。

**資源管理與容器運行流程**
1. **資源申請**：AM向RM發出資源請求，內容包括區域性偏好及容器屬性。
2. **資源分配**：RM根據可用性和排程策略分配資源給各個應用程式，當資源被分配給AM時，RM生成一個資源租約。
3. **租約驗證**：AM透過心跳拿到資源租約，使用基於token的安全機制驗證租約的真實性。
4. **啟動容器**：AM發現可用的容器後，將應用程式特定的啟動請求與租約一起編碼。在MapReduce中，容器中運行的程式碼為map或reduce任務。
5. **狀態通訊**：需要時，運行中的容器可透過應用程式特定的協議與AM直接通訊，報告狀態和存活情況，並接收框架特定的指令。

YARN部署提供基本但穩固的基礎設施來管理和監控容器生命周期。應用程式特定的語義由各框架自行管理。
:::

### 資源管理器 Resource Manager (RM)

RM 有兩個 public 介面：

1. 用戶端提交應用程式
2. AM 動態協商對資源的存取

以及一個內部的介面：

1. NM 監控叢集和管理資源存取

重點會放在 RM 和 AM 之間的公開協定。

RM 將++叢集狀態的全域模型++與++運行中的應用程式報告的資源需求摘要++進行比較，讓實現全域排程屬性（如容量或公平性）變得可能，但前提是排程器能正確理解應用程式的資源需求。為了適應應用程式需求和叢集規模，溝通訊息和排程器狀態需保持小巧而有效率。排程器只負責應用程式的資源配置，不處理本地最佳化和內部應用程式流程。YARN 完全脫離了 map 和 reduce 的資源靜態劃分，將叢集資源視為（離散的）連續體，顯著提高了叢集使用率。

AM 將資源需求編碼成一個或多個 **ResourceRequests**，追蹤：
1. 容器數量
2. 容器的資源 (像是 2GB RAM, 1 CPU)
3. 區域性偏好
4. 應用程式內請求的優先權

ResourceRequests 讓使用者能夠詳細或匯總地描述其需求，這使得請求可以緊湊地表示，並允許對其大小設限，從而達成有效的通訊和儲存。同時，這種設計在無法達到完美區域性時，能夠引導排程器選擇較好的替代方案。

開發中的擴展：對群組排程(gang-scheduling)需求的明確追蹤，以及表達任意共置(arbitrary co-location)或分離放置(disjoint placement)的軟/硬約束條件。

根據 NM 心跳，排程器更新和滿足資源請求，RM 為 AM 生成容器和授權token，並報告 finished 容器的 exit 狀態。AM 會在有新 NM 加入叢集時被通知，以便在新節點上請求資源。

協定的最近擴展允許 RM 在資源不足時請求應用程式歸還資源，使用類似 ResourceRequests 的結構來捕捉區域性偏好。AM 可以靈活應對這些「搶占」請求，允許應用程式保留工作，而非強制終止容器以滿足資源限制。如果應用是非協作的，RM可以在等待一定時間後，透過指示NM強制終止容器來取得所需的資源。

**RM ++不負責++協調應用程式執行和任務容錯**
1. 不提供運行中應用程式的狀態或指標（AM的工作）
2. 不提供特定框架已完成作業的報告（已委託給每個框架的後台服務）

這和 ResourceManager 應該只處理即時資源排程的觀點一致，有助於 YARN 中的中央元件擴展到 Hadoop 1.0 JobTracker 之外。

### 應用程式管理器 Application Master (AM)

> 一個應用程式可以是數個行程的靜態集合、工作的邏輯敘述，或是一個長時間運行的服務。

> ApplicationMaster 是一個協調應用程式在叢集中執行的行程，本身就像任何其他容器一樣在叢集中運行，由 RM 啟動。

- AM 定期向 RM 發送心跳，確認存活狀態並更新需求記錄。
- AM 會收到一個綁定了叢集中特定節點資源的 *container lease*。
- 根據從 RM 收到的容器資源，AM 可能會更新 execution plan 以適應。
- *late binding*: 資源實際的綁定發生在資源使用的租約階段，而不是在最初的請求階段。由於應用程序管理器發出資源請求時的條件可能在實際分配資源時發生變化：
- 資源容器的語義是可以替換的 (fungible)，而非固定用於某一特定任務或用途，可根據需要重新分配或使用。
- 根據不同框架需求進行調整 (framework-specific)
- AM 更新對 RM 的 resource asks（收到的容器資源對當前和未來產生影響）

因為 RM 不解釋容器狀態，AM 根據 NM 透過 RM 回報的容器狀態判定成功或失敗。雖然 YARN 提供一些恢復支持，但由於應用程式語義和容錯相互交織，容錯能力重度依賴於 AM。

### 節點管理器 Node Manager (NM)

The NodeManager is the “worker” daemon in YARN.
- 驗證容器的租約
- 管理容器的相依性
- 監控容器的執行
- 提供服務給容器

NM 向註冊的 RM 透過 heartbeats 回報狀態（記憶體、CPU等可用資源），以及接收指令。

YARN 中所有的容器都可以透過 ***container launch context (CLC)*** 描述。

CLC 包含
- 環境變數
- 儲存在遠端的相依性
- 安全 token
- NM 服務的負載
- 創建行程必要的指令

NM **驗證租約的真實性後，用指定的資源限制配置容器環境**。將依賴項複製到本地儲存，包括資料文件和可執行文件等，並管理它們在容器之間的共用。未使用的依賴項最終會被垃圾收集。

NM 會**根據 RM 或 AM 指令殺死容器**，可能是因為應用完成、驅逐（排程器決定把資源給另一個應用）或租用限制，也會在容器退出後進行清理，並在應用程式完成時丟棄資源。

NM 會**定期檢查節點運作狀況**，標記磁碟問題等問題。發現問題時轉換自身狀態變成 unhealthy 並通知 RM，RM 可能會停止容器分配，直到問題解決。

NM 為容器提供 local services，例如 *log aggregation* 會在應用完成後將 stdout 和 stderr 寫下的資料上傳到 HDFS。

管理員可用一組 *auxiliary services* 插件來配置 NM。容器可以在其生命週期之外保留選定的輸出，並由節點管理。

### YARN 框架/應用程式編寫者

YARN應用程式作者的職責：
1. **提交**：向 RM 提交 AM 的 CLC。
2. **註冊**：當 RM 啟動 AM 後，AM 應向 RM 註冊，並用 heartbeats 定期更新存活狀態與資源要求。
3. **容器管理**：當 RM 分配一個容器後，AM 透過 CLC 在 NM 上啟動應用程式。AM 同時也監控容器的執行狀態，停止並回收容器。
4. **註銷**：一旦 AM 完成了所有工作，就該向RM取消註冊，並在清理資源後退出。
5. **控制流程（可選）**：實作 control flow，用於報告作業狀態並提供 control plane。

開發 AM 可能很複雜；YarnClient 等用戶端程式庫可簡化開發。挑戰在於確保容錯和應用程式的安全性。

### 容錯和可用性

YARN 繼承了 Hadoop 對使用者隱藏偵測硬體錯誤和從中恢復的複雜度，只是責任分攤到叢集中運行的 RM 和 AM。

在YARN架構中，RM仍是單一故障點。當RM故障時，它會從持久儲存恢復狀態，並重新啟動所有AM。若框架支援恢復（大部分都會），平台會自動恢復使用者的pipeline。正在改進的功能包括讓AM在RM重啟時繼續運行，並在RM恢復後重新同步，以及實現RM的高可用性（主備切換）。

當NM故障時，RM透過心跳超時偵測到，將該節點上的容器標記為killed，並通知所有運行中的AM。如果故障是暫時性的，NM會重新同步RM並繼續運行。AM需要對節點故障做出反應，可能需要重新執行故障期間的工作。

AM故障不影響叢集可用性，但會增加應用程序中斷的風險。RM可能重啟AM，但平台不支援恢復AM狀態。重啟後的AM需自行與運行中的容器同步，如Hadoop MapReduce AM能恢復已完成的任務，但運行中的任務和恢復期間完成的任務會被重新執行。

容器本身的故障處理完全由框架負責。RM收集NM發送的所有容器退出事件，並在心跳回應中傳遞給相應的AM。MapReduce AM監聽這些通知，並透過向RM請求新容器來重試map或reduce任務。

## 結論

由於資源管理與程式框架的分離，YARN 提供了：

1) 更大的擴展性
2) 更好的效率
3) 使大量不同的框架能有效地共享叢集

這些優點透過實驗及 Yahoo! 大規模生產經驗得到了證實。

---

## References

原文 https://dl.acm.org/doi/10.1145/2523616.2523633
筆記
[Hadoop筆記 (YARN) - Yu Samantha](https://hackmd.io/@uf57VA2KROuAfxAa6dLehQ/S1BCe7XH3#YARN-Yet-Another-Resource-Negotiator-%E5%B7%A5%E4%BD%9C%E8%B3%87%E6%BA%90%E6%8E%92%E7%A8%8B)
[spark 笔记 4：Apache Hadoop YARN: Yet Another Resource Negotiator - 过雁](https://www.cnblogs.com/zwCHAN/p/4240539.html)