8-2 Hadoop Yarn 在小米的實踐.pdf

1、HADOOP YARN HADOOP YARN 在小米的實踐在小米的實踐涂瑜 計算平臺-高級軟件開發工程師|工作經歷小米 計算平臺-高級軟件開發工程師 主要負責大數據離線資源調度的開發與維護知乎 計算平臺-高級軟件開發工程師 曾負責知乎高并發網關建設，大數據存儲與離線資源調度服務的開發與維護|個人簡介個人對大數據計算存儲，網絡，高并發編程相關領域感興趣0101調度優化實踐調度優化實踐0303Yarn Yarn 擴展性與其他優化擴展性與其他優化0202資源優化實踐資源優化實踐0404Yarn Yarn 元倉建設元倉建設目錄目錄 CONTENT|最大規模節點數集群數量最大規模隊列數集群現狀20+6

2、K+1K+|調度優化實踐調度優化實踐請01|問題修復-節點資源更新導致調度卡頓問題|-隊列資源異步批量更新異步批量更新，節點上報不直接觸發資源更新問題描述-節點資源變動導致長時間更新資源更新-與調度線程持有同一把鎖-隊列數過多導致情況加劇解決方案1.使用 legacyMergeSort -Djava.util.Arrays.useLegacyMergeSort=true2.調度線程使用深拷貝隊列數據進行調度過程的計算|問題修復-Global Scheduler 多線程調度崩潰問題描述-RM 因調度線程崩潰導致長時間 hang 住不做任何調度TimSort自反性：x，y 的比較結果和 y，x 的

3、比較結果相反傳遞性：xy,yz,則 xz對稱性：x=y,則 x,z 比較結果和 y，z 比較結果相同解決方案 YARN-10178-仲裁線程根據分配結果修改子隊列資源配額-調度線程隊列排序不整體加鎖不整體加鎖，導致資源變動-打破 TimSort 數據要求，導致調度線程異常崩潰分析問題描述-調度分配獲取隊列 ResourceLimit 時，Resources.min 基于 DRF 只考慮了主導資源，導致調度線程通過超過隊列 max capacity 資源申請-仲裁線程嚴格判斷各項資源，導致大量的 Failed to accept this proposal 失敗，嚴重影響調度性能|問題修復-Re

4、sourceLimit 計算邏輯導致調度性能問題解決方案 YARN-11083-通過 RponentwiseMin 返回各項資源限制的最小值跳過 userlimit 計算邏輯 -背景 內部場景不需要隊列級別多用戶之間的資源隔離機制 大量無效計算，導致調度效率不高 -優化手段 配置加載時，基于隊列 minimum-user-limit-percent,userlimit-factor 計算是否關閉 userlimit 計算，節省大量計算邏輯單次分配多個 container -背景 調度鏈路在隊列數較多時產生大量排序工作 集群規模較大時，可以接受放棄一定的隊列公平性來提升集群的調度性能 -優化手段

5、 調度嘗試選擇出子隊列之后，嘗試分配多個 container 以提升單位時間分配的 container 數量|性能優化|性能優化效果 通過 SLS 壓測工具，CPS 3k+-5k+60%左右的性能提升 userlimit 大概有 30%左右的提升 單次分配 2 個 container 大概有 30%左右的提升資源優化實踐請02|彈性調度彈性資源default資源節省資源離線集群資源運行曲線期望的資源使用方式|AppAppAppApp00:0012:0000:0012:0000:00App彈性資源時間低優不適合彈性高優適合彈性作業篩選根據以下兩個維度對歷史作業進行篩選時間維度：作業運行時長、是否

6、與節點下線時間重合優先級維度：高優、默認、低優作業配置將篩選出來的作業，通過內部的作業提交工具，把 Label 表達式的配置統一設置，用戶無感知節點下線時間節點下線時間彈性調度作業篩選|彈性調度方案細節思考點|-AM AM 避開彈性節點類不穩定資源-Label|表達式 開發標簽或表達式支持 label1|label2 配置，作業可使用兩類資源-Remote Shuffle Service shuffle 數據不落本地盤，避免 shuffle 數據丟失帶來的任務重算-Graceful Decomission 節點下線前預先做 graceful decomission，盡量保證作業的穩定性更詳細方

7、案介紹 彈性成果與集群負載更加匹配的集群資源彈性資源彈性資源類型類型彈性資源彈性資源占比占比集群集群總成本總成本成本節約成本節約比率比率無0%1000%公有云按需實例25%8812%公有云搶占實例25%8020%顯著的成本優化|單機節點資源超賣問題描述-業務 container 申請量與使用量不符，導致單機利用率比較低-靜態超賣，單機存在穩定性問題解決方案-單機上報資源大于節點可供 YARN 使用資源(real+overuse)，-基于 Cgroup 進行節點穩定性管控(elastic+enforce)NM 如何利用 Cgroup 保障當單機內存利用率過高情況下的穩定性？|單機節點資源超賣El

8、astic Memory Controlhadoop-yarn cgroup 整個內存層級整個內存層級 memory.limit=節點可提供內存 oom_control 中 disable oom killer，-內存滿，NM 監聽內核事件對運行 container 進行處理單個單個 container 層級層級 memory.limit=container 申請量 -由原單線程掃描機制管控Resolve OOM-NM 監聽到內核的事件，基于策略選擇 container 進行 kill-小米內部擴展支持優先級策略可觀測性elastic kill 指標+清晰的 cgroup 診斷信息|Elast

9、ic Memory ControlFlink Container Lost-流式集群 Flink 作業因堆外內存溢出導致被 NM KILL-大量 Container Lost 影響業務問題描述解決方案-單機內存不觸發系統 OOM-KILLER，允許 container 內存超用-流式集群上線 NM Elastic Memory Control 機制保障穩定性-Flink 同事繼續解決堆外溢出問題效果container lost 1k+-500+,下降接近 50%|基線任務執行優化基線任務-作業管理平臺配置基線任務指定產出時間-作業管理平臺推導出上游任務作業執行時間-基線任務高優先級更快獲得資源

10、問題隊列內 APP 只能基于 fifo+priority 的策略排序，內部需求按照同等優先級公平分配，高低優先級高優先分配解決方案內部開發支持 fair+priority 的比較器，滿足特定分配需求擴展性及其他優化請03|問題描述擴展性-Federation目前小米內部遇到兩個問題：1.如何適配新的機房，如何對外屏蔽新機房的存在以及減少兩個機房之間的專線帶寬 2.單集群因規模較大面臨穩定性及擴展性的問題，需擴展性的方案解決方案通過調研社區的最新發展以及業界的常規優化手段，小米內部比較傾向于緊跟社區的發展路徑，決定落地 Yarn Federation|擴展性-Federation落地架構簡介-資

11、源管理服務-單隊列單集群-集群內部獨立部署 Proxy Server,History Server-GPG-Router-對外統一通過域名的方式-通過作業數據血緣分析梳理孤島鏈路小米內部 Yarn 運維管理平臺 -用戶自助隊列增刪改，權限，隊列屬性修改，審批，作業歷史數據查看等功能 -隊列資源基于歷史數據縮容，治理等功能 -Federation 規則更新，審批等功能|資源管理服務擴展性-Federation資管 Federation 新增規則|擴展性-Federation落地過程中遇到問題-AM Invalid Token 異常異常-Kyuubi Tracking URL 適配-客戶端去除 h

12、istory server 與 proxy server 相關地址配置-Spark 修改 AMIpFilter 使用方式-RM 與 Router 依賴的 ZK 配置路徑拆分，修改支持多個配置指定不同 ZK 路徑-Router UI 相關 bugfix-GPG 支持 secure mode YARN-11090-Router invoke 真實異常獲取 YARN-11064-Router HTTP 接口收攏與完善-。|擴展性-FederationInvalid Token 異常原因分析 1.AMRMProxy 生成 localtoken 替換 AM 原有 token 2.集群原地升級，由于滾動部

13、署 NM 與灰度 Client 不能同時生效造成 AM 拿著 local token 與 RM 交互導致 Invalid Token解決方案-通過環境變量決定 AMRMProxy 替換 Token-先全量開啟 AMRMProxy 特性，再全量作業開啟環境變量問題描述-RM 內存壓力過大（緩存大量已結束 App）-RM 高可用切換過程耗時過長-解決不了結束時間較久作業訪問|其他優化-RM App State to mysql解決方案-結束的 APP 回寫 ZK 的時候同時寫了一份數據到 MySQL-訪問內存中不存在的 APP，RM 基于緩存策略從 MySQL 進行加載，并恢復當時的 APP 狀態

14、供外部獲取-Jstack dump 機制 -用戶自助 dump 線程堆棧，減少運維壓力-container pre executor 機制 -container 啟動前執行相關校驗，不符合要求可實時封禁(eg:log4j)-常駐作業過多，導致 NM 節點任務日志上傳延遲問題修復 -App finish 觸發節點日志上傳|其他優化點Yarn 元倉建設請04|Yarn 元倉經營數據 -占比:不同計算類型作業在不同隊列的占比，包含(數量，狀態，運行時長分布，資源消耗等)-趨勢:不同計算類型作業在不同集群隊列的增長趨勢，包含(數量，狀態，運行時長分布，資源消耗等)-成本 集群，隊列，APP 不同層面的細致的成本數據-隊列滿載率，空閑率 基于元倉洞察-提供彈性調度決策的數據支撐-通過不同占比和趨勢掌控集群的變動-通過產出的元倉數據表供外部獲取并做分析（比如成本字段）|Yarn 元倉元倉數據鏈路-支持 app event change log-T+1 產出 app 詳情數據表|Yarn 元倉應用：展示執行時間在一小時內的作業占比，資源占比，作業類型占比支撐彈性調度的-資源量預估-時間段，作業類型的選擇未來規劃請05|-離在線混部：利用在線空閑資源，提高資源利用率-動態超賣：解決當前靜態超賣帶來的若干問題-資源一盤棋：與作業調度通盤探討小米集群資源的高效利用|未來規劃