本文從利用率提升、多負載場景優化、穩定性提升、異地多活四個方面介紹了字節跳動在四年來對 Hadoop YARN 進行的一系列的優化，以及生產環境中的實踐經驗。

1.YARN 簡介

1.1 YARN 生態圈

YARN (Yet Another Resource Negotiator) 是 Hadoop 集群的資源管理系統，是 Hadoop 生態中非常重要的成員項目。

一般來說，離線生態可以分為五層：

最底層是裸金屬層，由眾多物理節點組成，每個節點上運行著通用的操作系統。
次底層是集群資源管理層， YARN 就處在這一層中。
再往上是分布式計算引擎層， MR/Spark/Flink 等計算引擎處于這層，為了能讓業務同學更加低成本的寫計算任務，各個引擎都支持 SQL 功能。
再往上是作業托管層，用來提交 ad-hoc 的作業，管理周期性的批處理作業，管理長時間運行的流式作業。
最上層是用戶邏輯層，如數據日報，數據分析，模型訓練等.

1.2 YARN 架構

上圖中灰色背景區域是 YARN 的主要架構，主要包含兩種角色：

ResourceManager整個集群的大腦，負責為應用調度資源，管理應用生命周期。對用戶提供接口，包括命令行接口，API, WebUI 接口。可以同時存在多個 RM，但同一時間只有一個在工作，RM 之間通過 ZK 選主。
NodeManager為整個集群提供資源，接受 Container 運行。管理 Contianer 的運行時生命周期，包括 Localization，資源隔離，日志聚合等。

YARN 上運行的作業:

在運行時會訪問外部的數據服務，常見的如 HDFS，Kafka 等
會在運行結束后由 YARN 負責將日志上傳到 HDFS 中

2.字節跳動對 YARN 的定制

字節跳動的 YARN 是在 16 年從社區當時最新的 2.6.0 版本中 fork 出來的，主要承載著公司內的離線作業/流式作業/模型訓練三大場景。由于公司內的 YARN 服務規模巨大、場景復雜，遇到了各種問題，在社區版本沒有提供解決方案之前，內部研發同學定制了許多內容來解決具體問題，經過 4 年來上千次的修改，公司內的版本已經跟社區的版本相差較大。

今天給大家介紹一些比較關鍵的定制，希望能給大家帶來一些啟發。這些關鍵定制主要包括四個方面：

利用率提升: 包括分配率提升和物理使用率提升。
多種負載場景優化: 包括批處理 / 流式 / 模型訓練三種場景下的體驗提升。
穩定性提升: 包括擺脫對 HDFS 強依賴, Container 分級與驅逐, 非受控 Container 管理。
異地多活: 包括統一的 YARN Client 和 UI 等內容。

2.1 利用率提升

2.1.1 多線程版本的 Fair Scheduler

社區原生版本的 FairScheduler 是單線程的，在節點數量較多時，是整體集群最大的瓶頸.

我們通過將 FairScheduler 改造為并發的多線程版本，并將調度器內部的鎖拆分為更加細粒度的讀鎖和寫鎖，將調度吞吐提升 7 倍以上，在生產環境中達到每秒 3K 個 Container 的速度(未觸及性能瓶頸)。

2.1.2 考慮節點 DRF 的調度

原生的 YARN 在調度時只考慮資源是否滿足，經常會出現一個節點 CPU 被打滿，但是內存還有剩余的情況。

我們引入節點 DRF(Dominant Resource Fairness)機制，計算每個節點的剩余資源的主資源，當調度的 Task 的主資源與節點的主資源不匹配時，先延遲此次調度，直到一定次數后再放松約束。

通過引入這個機制，集群資源的碎片化問題大幅降低，生產環境中可以達到 CPU 和內存的 24 小時平均利用率都在 90%以上。

2.1.3 提升單集群規模

單個集群的規模越大，就可以有更多的用戶和作業使用這個集群，這個集群的利用率也會更高。但是原生的 YARN 在達到 5K 節點規模時開始出現各種問題，比如說一次簡單的切主可能會導致整個集群雪崩。

我們為提升單集群規模做了一系列的優化。

首先，通過對 YARN 內部事件梳理調整，精準的修改了一些事件處理邏輯。
然后，將 NodeManager 節點的心跳機制改為根據 ResourceManager 的壓力動態調整。
之后，修改內存單位(int->long)突破單個集群 21 億 MB 的限制
再之后，通過對切主過程進行深度優化, 將切主時間控制在秒級

當然還有很多其它的細節優化不再一一列舉，最終的效果是讓單個生產集群達到了 2 萬節點的規模。

2.1.4 與流式&在線服務混部

公司內離線的資源全天都比較緊張，而流式作業和在線服務的資源使用量隨著用戶的行為，在時間上有明顯的波峰波谷，在凌晨時通過混部的方式將流式和在線富余的資源提供給離線可以全面的提升利用率。

我們通過將 NodeManager 改造為可以根據宿主機的富余資源動態的調整的 NM'，來達到與流式作業和在線服務的混部，為離線提供更多資源的目的。

目前生產環境中已有數萬臺節點進行了混部，混部后將原機器的 CPU 利用率絕對值提升了 20%以上。

2.1.5 Smart Resource : 在運行時/重啟時調整資源

原生的 YARN 中，用戶申請的資源和實際使用的資源經常會出現比較大的偏差, 導致出現大量的資源浪費的情況，為此我們開發了一整套的資源動態調整方案，可以將申請的資源調整到接近于實際使用資源的數值。

并且，在實際使用中發現，如果資源調整必須以一個核為最小粒度的話，還是會出現很嚴重的浪費，比如用戶真實的需求可能是 0.001 個核*1000，原生的 YARN 只能分配 1000 個核，就白白浪費了 999 個核。我們開發了以千分之一核為最小粒度的功能，可以有效的減少資源的浪費。并且千分之一核與資源動態調整結合，可以更加精細化的調整資源。

2.2 多種負載場景優化

字節跳動的 YARN 承載了公司內的批處理 / 流式 / 模型訓練三大場景，由于 YARN 天生是為批處理而設計的，很多地方與流式 / 模型訓練場景并不匹配，為了給這些場景更好的體驗，需要做一些定制工作。

2.2.1 YARN Gang Scheduler 調度器

流式作業和訓練作業的調度需求與批處理有很大的不同：批處理強調的是高吞吐，而流式/訓練類型的作業更加強調低延遲和全局視角。為了彌補原生 YARN 在低延遲和全局視角上的缺陷，我們開發了一個全新的調度器 Gang Scheduler。

Gang Scheduler 提供了一個 All-or-Nothing (一次全交付或不交付)的語義，如作業申請 1000 個 container，那么要么直接返回 1000 個 container，要么就返回失敗，并提示失敗的原因。這樣可以有效的避免兩個作業都只拿到一半的資源，誰也無法啟動的互鎖局面。

除此之外，Gang Scheduler 還有個特性是超低延遲，它可以在毫秒級給出 All-or-Nothing 的結論，這樣可以大大緩解流式作業在重啟時的 lag 積壓問題。

最重要的是，Gang Scheduler 為流式作業和訓練作業提供了全局視角，每個作業可以通過配置自己定制的強約束和弱約束來達到全局最優的放置策略。其中，強約束是指必須要滿足的條件；弱約束是指盡量滿足，但確實無法滿足時可以接受降級的約束。目前支持的強約束包括節點屬性, 高負載等；支持的弱約束包括：節點屬性，高負載，Container 打散，Quota 平均，GPU 親和性等。

2.2.2 更加精細化的 CPU 使用策略

除了開啟 YANR 原生默認支持的 CGroup 限制之外，我們還配置了更加豐富的 CGroup 管理策略，比如在 share 模式下支持自定義的最大值限制，支持綁核，支持綁 NUMA 節點等. 通過這些措施，給流式作業和訓練作業更加靈活的管控策略，滿足不同場景下的隔離或共享需求。

2.2.3 訓練場景下的其它定制

對于訓練場景，我們還定制了更豐富的內容。包括：

為了更好的隔離性，定制了支持 GPU 和 Ceph 的 Docker
為了更靈活的資源申請，定制了帶范圍的資源值 (傳統的 YARN 資源只有個數, 沒有范圍，比如多少個 CPU，多少 GB 內存，但在訓練場景下，有時希望有范圍，比如當需要兩個 GPU 卡時，不止希望隨意的兩張卡，而是希望要一臺機器上兩個連號的 GPU 卡，比如卡 0 和卡 1 是連號的，而卡 0 和卡 2 不是連號的。這個場景同樣也適用于端口號。)
為了更高效的同時使用 CPU 和 GPU 機器，定制了節點屬性功能。

2.2.4 跳過高 Load 節點

離線批處理場景經常會遇到"Fetch Failed"的問題，主要來源是本地的磁盤 IOPS 不足，導致 Shuffle Service 卡住，為了緩解這個問題，我們在資源調度的過程中加入目標主機 LoadAvg 的考慮因素，如果一臺機器的 LoadAvg 過高，則暫時跳過對其分配新任務. 通過這個機制，將"Fetch Failed"問題降低了約 40%。

2.3 穩定性優化

字節跳動的 YARN 服務規模巨大，在穩定性方面遇到了很多挑戰，有很多細節方面的優化, 在這里由于時間有限，挑選幾個比較有代表性的優化點跟大家分享一下：

將 HDFS 做成弱依賴對于一般的離線批處理來說，如果 HDFS 服務不可用了，那么 YARN 也沒必要繼續運行了。但是在字節跳動內部由于 YARN 還同時承載流式作業和模型訓練，因此不能容忍 HDFS 故障影響到 YARN。為此，我們通過將 NodeLabel 存儲到 ZK 中，將 Container Log 在 HDFS 的目錄初始化和上傳都改為異步的方式，擺脫了對 HDFS 的強依賴。
Container 分級與驅逐某些 Container 的磁盤空間占用過高，或者將單機 Load 打得非常高，會比較嚴重的影響到其它 Container 的正常運行，為此，我們為 YARN 定制了 Container 分級與驅逐機制。對于可能會嚴重影響到其它 Container 的 Container 會進行主動驅逐。對于被驅逐的作業，可申請到獨立的 Label 中運行。
非受控 Container 的清理機制由于種種原因，線上總是會出現一些 Container 明明還在運行，但是已經不受 YARN 的管控。通常是由于不正常的運維操作產生，或者機器本身出現故障導致。對于這些 Container 如果不加管制，不僅會讓單機的實際資源緊張，有時還會造成 Kafka Topic 的重復消費導致線上事故。為此我們在 YARN 的 NodeManager 中增加了非受控 Container 的清理機制。