本期作者
1.背景
在過去一年的時間裡，B站離線平台資源排程側的主要挑戰有兩個方面:
1) 随着業務的不斷增長，離線叢集規模快速膨脹，使用者對資源的需求在持續增大，主叢集長期處于Pending較高的狀态，資源需求超過傳遞量
2) 出于降本增效的考慮，消解Pending的方法不能僅靠實體機的增加了，而是需要在實體機整體數量不變的基礎上通過超賣來提升叢集整體的資源使用率。
為了應對上述挑戰，排程側在向内與向外兩個方向上進行了積極的探索。“向内”聚焦于單台實體機，通過超配的方式不斷提高單台實體機的使用率，使得單台節點能夠處理更多的任務；“向外”與雲平台部門合作，共同探索混部技術的落地，到目前為止，已經完成了離線超配，離線上混部、在離線混部等叢集建設以及潮汐混部的技術實作，使得不同叢集間的資源能夠被更充分地調動。
為此我們自研了元件Amiya，旨在解決大資料叢集資源缺口問題，自上線後較好的完成了Yarn離線叢集以及在離線混部叢集資源超配的工作。以離線主叢集為例，目前5000多台NodeManager所在的節點已完成了Amiya的部署。在Amiya開啟後，為Yarn額外提供了約683TB的可申請Memory（見下圖1）以及約137K的可申請VCore（見下圖2）。
圖1 Amiya為Yarn額外提供了約683TB的可申請Memory
圖2 Amiya為Yarn額外提供了約137K的可申請VCore
接下來，本文将對Amiya架構、功能子產品、效果等方面進行詳細闡述。
2.Amiya架構
超配元件所依賴的主要理論是“使用者申請的資源量一般大于使用者真實使用的資源量”。根據這個理論，實作超配元件的主要思路是，根據目前機器的實際負載情況，向排程元件虛報一定的資源量，使得更多的任務能夠被排程到該台機器上運作。然而，這種做法也帶來了一定的風險。在極端情況下，機器上運作的大部分任務的使用者申請量會接近于使用者真實使用的資源量。這種情況下，超配元件需要及時發現并響應，驅逐一定量的任務以保證機器整體的穩定運作。是以，超配元件必須具備智能管理的能力，能夠根據機器實際的負載情況和任務的資源需求，動态調整超配量，以保證機器整體的穩定性和可靠性。同時，超配元件還應該具備良好的容錯性和監控機制，能夠及時發現和處理機器故障或異常情況，保障業務的連續性和穩定性。總之，超配元件雖然能夠帶來更高的資源使用率，但也需要合理使用和管理，以避免帶來潛在的風險和損失。
由上述理論可知，對于超配元件來說，主要的北極星名額有兩個:
1) 盡量提高節點的超配率
2) 在超配率處于高水位的情況下，盡量降低節點上任務的驅逐率
Amiya的主要功能為動态超配，為了更好的執行動态超配，Amiya又添加了節點資訊收集管理、資源智能限制、跨Agent協同管理等一系列功能，這些功能的整合和實作旨在滿足高超配率和低驅逐率的要求。
圖3 Amiya v2整體架構圖（清晰大圖[1])
上圖為Amiya v2的整體架構圖，架構圖自上而下的子產品為AmiyaContext、StateStoreManager、CheckPointManager、NodeResourceManager、OperatorManager、InspectManager以及AuditManager。其中各元件的主要功能如下：
- AmiyaContext：當Amiya啟動時，會自動探測目前節點的環境、目前NodeManager的狀态等資訊，并記錄至AmiyaContext之中。各AmiyaManager會依據AmiyaContext中不同的狀态做出不同的應對方案；
- StateStoreManager：StateStoreManager是Amiya的資訊采集子產品，它會定時探測機器的各項名額。首先，這些名額是Amiya超配決策所依賴的基礎資訊；其次，這些名額可以通過Grafana等工具記錄下各時段機器的狀态；最後，Amiya采集到的部分資訊會通過OperatorManager傳遞給Yarn NodeManager與ResourceManager；
- CheckPointManager：CheckPointManager會将Amiya目前某些狀态記錄至硬碟，這些狀态在Amiya重新開機後能夠第一時間進行狀态恢複。目前版本記錄的狀态主要包括目前Amiya的超配比例以及目前NodeManager所觸發的Taint情況；
- NodeResourceManager：作為Amiya最核心的子產品，NodeResourceManager掌管了Amiya的資源超配、Taint、大磁盤任務驅逐、特定Container名額調整等一系列邏輯。最主要的邏輯是資源超配，它從StateStoreManager擷取目前節點資訊并加以判斷，能夠做出資源提高（OverCommit）、資源降低（DropOff）、保持目前資源（Keep）三類判斷，當判斷為資源調整的OverCommit或DropOff後，還會根據一系列規則計算出目前Yarn NodeManager應該調整的具體資源量，并将其發送給OperatorManager，通過OperatorManager傳遞給NodeManager；
- OperatorManager：由上文NodeResourceManager的描述可知，OperatorManager是Amiya與其他元件互動的橋梁。目前的OperatorManager主要實作了與Yarn以及K8S的互動功能；
- InspectManager：機器層面的定期巡檢節奏與任務巡檢不一緻，故将機器層面的巡檢邏輯拆分開，通過InspectManager統一規範實作；
- AuditManager：Amiya會執行Container級别以及Application級别的的驅逐等操作，這類操作的審計資訊會通過AuditManager批量插入至TiDB中，再通過觀遠形成各類前端報表以供查驗。
3.關鍵實作
Amiya的關鍵實作主要分為三個部分，分别為超配邏輯實作、驅逐優化實作以及混部模式實作，其中前兩項對應上述Amiya兩個北極星名額，最後一項是Amiya在混部場景下的一些邏輯實作，這部分邏輯與離線場景相異。
3.1 超配邏輯實作
3.1.1 超配流程
圖4 Amiya在離線場景下的超配決策邏輯（清晰大圖[2])
Amiya在離線場景下的超配決策邏輯如上圖所示，這部分邏輯主要在Amiya的NodeResourceManager中實作。正如在架構中所介紹的，超配邏輯可以分為做出判斷與資源計算兩個步驟。與Yarn排程的資源相同，Amiya在超配過程中考慮的資源有Memory與CPU兩類。
在做出判斷的過程中，NodeResourceManager會從StateStoreManager内拿取Memory與CPU的兩個使用率，一個是機器目前的使用率CPU/MemoryPercent，另一個是目前NodeManager占機器總使用量的比率CPU/MemoryNMPercent。首先判斷目前機器的CPU/MemoryPercent是否低于門檻值OverCommitThreshold，如果低于門檻值則說明機器的剩餘資源量較多，Amiya會給出資源提高（OverCommit）的判斷；若目前機器CPU/MemoryPercent高于門檻值OverCommitThreshold，則說明機器已經飽和，此時再考察CPU/MemoryNMPercent，若CPU/MemoryNMPercent高于門檻值DropOffThreshold，則說明在資源飽和的機器内，NodeManager任務的資源占有量已經達到了預期之外，Amiya會給出資源降低（DropOff）的判斷以抑制後續任務的送出，并且記錄下具體超過門檻值的資源為Memory或者CPU，這些資訊在Container驅逐中會發揮作用。若CPU/MemoryNMPercent低于門檻值DropOffThreshold，則說明NodeManager任務的資源占有量還在預期内，Amiya會給出保持目前資源（Keep）的判斷，并持續觀察機器資源的後續變化情況。
在得到判斷的類型後，NodeResourceManager會通過OperatorManager擷取到目前Yarn的資源量CurrentResource，并通過資源變化率CPU/MemoryChangeRatio與之相乘，得到本次所期待的資源變化量，其中OverCommit是正變化量，DropOff是負變化量。将變化量與CurrentResource相加，即為本次Amiya希望變更的Yarn資源量。
接着，這個資源量會接受三重檢驗。首先是資源量的變化不能超過Amiya所設的範圍内，這個範圍的上限是實體機總資源量的一個比率CPU/MemoryRatio，下限為NodeManager自身配置中的Memory及CPU的資源量。目前B站離線叢集的CPURatio設定為2，MemoryRatio設定為1.5，即NodeManager能夠通過Amiya得到的最大VCore為機器CPU核數的2倍，最大Memory為機器Memory的1.5倍；其次若資源變化量在一定的範圍（resRange）内，Amiya會認為這個波動屬于無效波動，并拒絕該次資源變化請求，旨在降低NodeManager資源的變化頻率；最後Amiya會觀測兩次資源變化的時間間隔，隻有在時間間隔大于CapacityIncInterval的情況下才會允許資源變更，達到減小NodeManager資源抖動的目的。
3.1.2 資源上限優化
在生産環境中，不同的機型采用相同的CPU/MemoryRatio計算得出的超配上限會導緻資源配置設定不均衡。舉例來說，在首次上線時，Amiya在機器上的超配上限為1倍實體機記憶體（Yarn可申請資源量由cgroup路徑"/hadoop-yarn"下的213GB上升到了實體機記憶體256GB）、2倍實體機CPU，此時對于<256GB，48Core>的機型，經過超配後CPU使用率能穩定在70%左右，而<256GB，96Core>的機型CPU的使用率超配後的CPU使用率僅30%左右。根據經驗，生産中使用者申請的資源配比約為4GB:1VCore。對于48Core的節點來說，給到NodeManager的資源配比約為2.67GB:1Core；對96Core的節點來說，資源配比約為1.33GB:1Core。
圖5 首次上線時的資源配置設定模拟
如上圖所示，我們假設有N個符合4GB:1VCore的Container向兩種類型的機器送出任務，48Core的機器最終的CPU申請率為62.5%，而由于記憶體瓶頸，96Core機器的最終CPU申請率僅為31.25%。能夠推斷出，Memory與CPU的配比約接近4:1，兩種資源的平均申請率越高，這也是我們日後調整資源上限的目标。
為了提升CPU的使用率，首先需要提高對記憶體的超配以降低記憶體瓶頸，在經過線上較長時間的驗證後，我們發現對于256GB記憶體的機型，在記憶體超配為實體機記憶體的1.5倍（384GB）時，記憶體實際使用量與驅逐率能夠達到我們可接受的平衡。此時48Core機器的配比為4GB:1VCore，96Core機器的配比為2GB:1VCore。對于48Core的機器，如下圖所示，在夜間高峰2:30至10:00時段，機器級别的記憶體使用率均值在60%左右，其中NodeManager的Cgroup下記憶體使用率均值在65%左右，且基本未觸發Amiya Container驅逐，CPU均值在80%左右，達到了超配的預期效果。
圖6 48Core機型夜間高峰時段資源使用率
而對于96Core的機器來說，記憶體瓶頸的效應仍然較為明顯，如下圖所示，在夜間高峰2:30至10:00時段，機器級别的記憶體使用率均值在70%左右，其中NodeManager的Cgroup下記憶體使用率均值甚至達到了在81.5%左右，且多次觸發了Amiya Container級别驅逐，但CPU均值僅為45%左右。此時再通過超配記憶體來拉升CPU使用率已意義不大。
圖7 96Core機型夜間高峰時段資源使用率
為了進一步提高96Core機型的CPU使用率，我們計算了目前記憶體的缺口。對于96Core的機器來說，CPU超配後的可申請量為96*2=192VCore。在記憶體超配1.5倍的情況下，添加一條128GB的記憶體條，能夠使得目前的Memory可申請量提升到(256+128)*1.5=576GB，此時資源配比可以提升至3GB:1VCore，在記憶體用滿的情況下同時拉高CPU的使用率。且在後續驅逐優化完成後，能夠拉高384GB記憶體機型的Cgroup Memory Limit，将該批機器進一步提升至記憶體2倍超配，進而達到4GB:1VCore的資源配比。就目前1.5倍記憶體超配而言，如圖所示，在夜間高峰2:30至10:00時段，機器級别的記憶體使用率均值在62%左右，NodeManager的Cgroup下記憶體使用率均值為在84%左右，與未添加記憶體時保持了一緻的高使用率，但是CPU的使用率從45%提升至約70%，基本符合了超配預期。
圖8 96Core機型添加記憶體後夜間高峰時段資源使用率
3.2 驅逐優化實作
對于超配元件來說，驅逐邏輯關系着機器、任務、自身的穩定性，如何在保證高超配率的同時維持叢集的穩定運作，是Amiya一直在探索的問題。目前Amiya的驅逐包含了Container驅逐、Application驅逐、Node驅逐三個次元，通過對三個次元的把控，保證叢集在超配情況下處于較為穩定的狀态。
3.2.1 Container驅逐
Container驅逐是Amiya在DropOff後觸發的操作。由于Memory的短暫打滿極有可能導緻整機夯死，嚴重影響節點上所有元件的正常運作，而CPU的短暫打滿是可以忍受的，故OperatorManager在向下調整NodeManager資源後，會檢查DropOff的原因。如果是因為Memory達到門檻值觸發的DropOff，OperatorManager會在判斷目前Memory的上升斜率是否達到門檻值，若達到門檻值則立即進入Container驅逐的邏輯；若是CPU觸發的DropOff，OperatorManager會維護一個時間視窗，隻有在視窗中多次CPU打滿才會進入Container驅逐邏輯。通過這個優化能夠極大的降低Container的驅逐率。
Container驅逐需要遵循一定的規則。進入驅逐邏輯後，Amiya會對目前"/hadoop-yarn"的Cgroup進行一次快照，擷取各Container Memory或CPU的真實用量并進行排序，并根據使用量從大到小進行驅逐，直到真實使用量小于DropOff後的NodeManager資源量。在驅逐的過程中，Amiya會跳過一些特定的Container。目前Amiya支援跳過AM、根據Yarn的Priority跳過高優Container、跳過高優隊列的Container、跳過特定隊列中特定Priority的Container共四類Container強保設定。
在實際運作的過程中，我們發現在極端情況下，若大部分Container都命中了強保邏輯，則會導緻Amiya驅逐效果不明顯，高優的大記憶體Container仍然持續申請Memory，進而最終導緻整機夯死。對于這種情況，我們做了兩方面的優化。在Yarn層面，我們盡量打散了大記憶體Application的Container分布，不讓單台節點上出現大量的高優大記憶體Container，抑制熱點節點的形成；在Amiya層面，我們引入了極限驅逐（ExtremeKill）的概念，ExtremeKill僅在Memory DropOff時生效，當Amiya探測到無Container可驅逐且MemoryPercent達到危險水位時，會直接驅逐掉目前Memory占用最大的一個Container，并通過AuditManager進行風險操作記錄。
通過Amiya驅逐的Container是因為節點資源壓力的原因而被驅逐的，而非自身原因導緻的失敗，故不應算作運作失敗的Container。我們在Yarn的NMWebService中添加了專供Amiya驅逐的API，并通過特殊的DiagnosticInfo與ExitCode進行辨別。同時我們改造了Spark與Hive使之能夠識别這些驅逐導緻的task失敗，跳過正常的失敗次數累計邏輯，不計入真正的失敗，直接進行重試，避免了因為task失敗過多導緻的作業失敗。
3.2.2 Application驅逐
圖9 Application驅逐邏輯
我們叢集上經常有一些需要大量寫本地盤的任務，比如大量shuffle spill導緻磁盤容量占滿進而打挂節點，為此amiya實作了Application驅逐功能，如上圖所示，Application驅逐主要是對大磁盤任務的驅逐。Amiya通過StateStoreManager對SSD盤(任務的臨時目錄存放在SSD盤)進行監控，當SSD盤使用量達到預警門檻值後，Amiya會對目前Application在本節點的磁盤占用量進行排序，查找是否存在占用量大于一定門檻值的Application，若存在則對該Appliction進行驅逐，以保證較為健康的節點磁盤容量。
進一步地，Amiya會向RMProxy查詢目前Application對應的JobID，并向作業畫像元件标記該Job為大磁盤作業。之後該Job的Application再次送出時，會自動添加上大磁盤的Policy（如下圖所示），使該Application的Container配置設定在磁盤剩餘容量較多的節點上，同時會對Container進行打散，避免在一台機器上配置設定過多container
圖10 被标記為大磁盤Policy的Application
3.2.3 Node驅逐
Amiya化用了K8S中Taint的語義，為需要驅逐的節點添加不同的Taint，以達到阻止ResourceManager對其繼續配置設定的目的。目前Amiya支援的Taint包括：
- OOMTaint：節點觸發了oom-killer後，Amiya會向NodeManager發送OOMTaint信号阻止新的任務向該節點配置設定，并持續監控節點MemoryPercent，直到小于門檻值後解除OOMTaint，Node Manager可以繼續配置設定；
- HighLoadTaint：節點Load5MinPerCore超過Taint觸發門檻值後，Amiya認為該節點的Load負載已經過高，向NodeManager發送HighLoadTaint阻止新的任務配置設定，直到Load5MinPerCore低于Taint後取消門檻值。Taint觸發門檻值一般與Taint取消門檻值保持一定內插補點，防止Taint頻繁抖動觸發；
- HighDiskTaint：由節點SSD盤使用量觸發的Taint，可以設定MaxPolicy與MinPolicy。其中MaxPolicy指SSD盤中存在使用量超過90%的盤則觸發Taint，将該節點過濾；MinPolicy指SSD盤中使用量最低的的盤的使用量超過90%則觸發Taint，将該節點過濾；
- LowResourceTaint：在混部叢集中，可能出現單台節點資源縮減過少的情況(比如縮減到單台1core 2GB)，我們不希望這類節點承接任務後由于資源不足導緻任務運作過慢，故在節點資源低于門檻值時，Amiya會向NodeManager發送LowResourceTaint以阻止任務配置設定，待上報的資源量符合預期後再取消該Taint；
- NeedToStopTaint：僅通過API觸發的Taint。在潮汐混部的場景中，大資料服務管理平台BMR會退避部分NodeManager節點給到線上應用，在退避前會向Amiya發送請求，觸發NodeManager的優雅下線請求，此時Amiya會立即發送NeedToStopTaint給NodeManager阻止其繼續接受任務，并在經過一段等待時長後對NodeManager進行優雅關閉。
Amiya資訊與NodeManager資訊互通，如下圖所示，節點Taint資訊可以直接在ResourceManager的WebUI上進行展示，友善管理者進行排查。
圖11 Taint資訊在ResourceManager Web UI上的展示
3.3 混部模式實作
圖12 在離線混部架構
如上圖所示，混部叢集是我們在公司的線上容器雲上部署的一套Yarn On k8s，其中NM和Amiya在Pod内，我們基于任務和叢集的資源畫像通過RMProxy&Yarn Federation會路由一些低優先級作業到混部叢集。Amiya在v2版本中支援了對混部叢集中的NodeManager Pod的資源管控。在之前的混部叢集裡，NodeManager Pod的資源由K8S Agent進行統一比例超配後上報給ResourceManager，無法做到根據節點資訊進行動态超配。如下圖所示，Amiya v2将Amiya作為SideCar部署進NodeManager Pod中，進而輔助父應用NodeManager Container進行資源超配等一系列操作。
圖13 Amiya作為SideCar部署進NodeManager Pod中
在部署的過程中，需要将Cgroup位址挂載進Amiya Container中，并且申明與NodeManager Container共享程序命名空間，使NodeManager的PID對Amiya可見。
在Amiya v2部署後，目前混部叢集Yarn資源上報流程如下圖所示。首先，K8S Agent不再負責統一比例的資源超配，而是将為NodeManager Pod預留的真實資源量通過Unix domain socket的方式傳遞給Amiya。其次，Amiya接受到這個值後會将其視為目前NodeManager Pod的實體資源上限，根據這個上限與從Cgroup中擷取的目前資源使用量進行超配預期的計算，得到目前NodeManager的期待資源量。最終将這個期待量傳輸給NodeManager，改變其資源量，完成一次動态超配的調整。
圖14 混部叢集Yarn資源上報流程
4.超配效果
超配效果的評估主要有兩個名額，一個是排程元件層面的資源可申請量的提升量，另一個是節點層面的資源真實使用量的提升量。在Amiya的場景下，排程元件層面的提升量是Yarn Memory與VCore的提升量，節點層面的提升量是Amiya真實超配量。
在離線主叢集，Amiya部署在5000多台節點上，Amiya為Yarn帶來了約<683TB, 137kVCore>的額外資源可申請量。
Amiya真實超配量的計算如下公式所示：
其中YarnUsed為目前Yarn的已申請量，YarnGuarantee是Yarn Config中申明的節點最大資源量，YarnGuarantee的值在Amiya啟動後會被Amiya計算出的超配值所覆寫。進而
可以表示由于Amiya超配而獲得的申請量占總申請量的比例，用這個比例将目前節點的資源真實使用量拆分為“因Amiya超配而獲得的真實使用量”與“未超配時就能夠達到的真實使用量”兩部分，我們将“因Amiya超配而獲得的真實使用量”作為Amiya真實超配量。
更進一步地，通過如下公式能夠計算出Amiya超配等效增加的機器數量，其中分母為叢集主力機型的memory.limit_in_bytes：
根據上述公式計算得出，這些可申請資源量最終轉化為了186TB（夜間高峰2:30至10:00均值）～ 288TB（七日峰值）的直接記憶體收益，相當于添加了約 900～1400 台節點的算力。
其中某天的Amiya真實超配收益、真實收益台數的Grafana監控如下圖所示。
圖15 某天Amiya真實超配收益監控
根據實體機内Cgroup擷取的統計值，我們能夠進一步統計出Amiya單台真實超配收益。對于Memory來說，部署Amiya後單台節點Memory使用量提升的每日均值為33.26GB，日均提升為15.62%；對于CPU來說，部署Amiya後單台節點的CPU使用率提升每日均值為18.56%，對于占據主叢集超半數的主力配置來說，單台節點的CPU使用率每日均值的提升更是達到了22.04%。
在關注超配量的同時，驅逐率也是我們主要關注的名額。目前Amiya的驅逐率在 0.56%（夜間高峰2:30至10:00均值） ～ 2.73%（七日峰值）之間。其中某天的Amiya驅逐率的Grafana監控如下圖所示。
圖16 某天Amiya驅逐率監控
Amiya嚴格遵守B站Yarn SLA規定，在驅逐時對高優先級的任務無影響，對中優先級的任務在極端情況下會出現ExtremeKill，主要被驅逐的是低優先級任務。
在混部叢集，Amiya已上線了全量節點，上線後混部叢集的機器CPU使用率約提升了10%左右，下圖為上線後首日的使用率截圖。
圖17 上線首日嘉定機器使用率提升情況
5.總結與展望
目前Amiya已經能夠較穩定的支援離線場景、混部場景的Yarn資源超配功能，且協助Yarn進行了一定的排程管理。目前Amiya正在進行的改造主要有三點：
1.在Yarn任務記憶體消耗極大極快的情況下，會導緻系統來不及回收記憶體而直接夯住，影響節點上DataNode的正常運作。針對這個場景，Amiya正在與B站核心組合作，支援Group Identity、OOM Priority、Async Reclaim等一系列核心優化，以期徹底消除超配導緻整機夯死的情況，降低NodeManager超配對DataNode和系統程序等高優元件的影響。
2.目前的驅逐政策對低優先級的大記憶體任務不甚友好，可能導緻個别大記憶體任務頻繁觸發Container驅逐進而導緻任務運作過慢，Amiya需要得知Application層級的驅逐情況，并對驅逐頻繁的Application進行特殊處理。
3.正如上述第二點所說，Amiya目前和Nodemanager一起僅部署在worker節點上，隻能探知目前節點的Container級别的資訊，無法彙總成Application級别的作業資源畫像，無法支援全局的資源把控、驅逐政策、更靈活的動态max_ratio超配等功能。目前正在開發的Amiya v3版本希望支援Amiya的Master-Worker架構。Amiya Worker部署在節點上，通過心跳發送節點資訊給Amiya Master，Amiya Master再進行更高次元的決策。另外Amiya目前依賴Yarn ResourceManager WebUI來展示資訊，Amiya Master建成後能夠将Amiya資訊展示遷移回Master，降低Amiya與Yarn的耦合。
在本篇文章中，我們主要介紹了B站大資料排程側在“向内”超配所達到的階段性效果，對于“向外”進行叢集混部的進展，請關注後續文章《B站大資料叢集混部實踐（下）》。
高清圖檔連結：
[1] Amiya v2整體架構圖：https://ibb.co/RPxjstc
[2] Amiya在離線場景下的超配決策邏輯：https://ibb.co/LrTbdLG
<EOF>