YARN 在快手的應用實踐與技術演進之路

過往記憶大數據?今天

編者薦語：

本文來自8月24日的云+社區技術沙龍“大數據技術實踐與應用”，議題來自房孝敬老師主題為“yarn在快手應用實踐與技術演進之路”的分享整理，內容包含yarn系統在快手的應用實踐，遇到的問題以及相應的技術演進過程。

以下文章來源于云加社區?，作者房孝敬

本文是房孝敬老師主題為“yarn在快手應用實踐與技術演進之路”的分享整理，內容包含yarn系統在快手的應用實踐，遇到的問題以及相應的技術演進過程。

?

講師介紹：房孝敬，快手大數據架構團隊調度方向負責人，目前負責快手公司Hadoop生態中調度、AI架構等子系統內核與周邊子系統的研發，并推動在公司內的應用。

?

---

?

本文主要分為三部分：yarn的背景、yarn技術改進、yarn未來規劃。

yarn的背景

?

yarn大家都比較熟悉了，是從Hadoop1.0分離到2.0的比較重要的特性，把原來的jobtracker集中式調度變成yarn的二級調度，解決集群擴展性的問題。yarn主要是分成了三個模塊，ResourceManager來管理整個集群的資源，NodeManager管理整個機器資源情況，ApplicationMaster管理整個APP的資源信息。MR/SPARK/Flink實現了自己的AM邏輯在yarn上運行。

接下來介紹一下yarn的RM模塊。yarn的RM模塊按照功能可以分成兩部分：集群狀態管理和資源分配。RM內部通過ResourceTrackerService和ApplicationMasterService 負責NM和APP的通信交互。服務內部會生成相應的事件交給內部的事件處理器處理。驅動NM和APP狀態機的運行，確保APP和NM處于合適的狀態。調度通俗的講就是把節點的空閑資源分配給需要的APP。社區早期版本的yarn是在心跳邏輯里面觸發整個調度邏輯的，這里面有一個問題，調度過程會跟整個事件處理的競爭資源，導致兩方相互影響，性能不高，后來yarn社區做了優化，把整個調度邏輯拆離，放到單獨線程來做。

?

?

yarn在快手的應用特點

yarn在快手是非常典型的大數據的應用棧，yarn上面服務了一些經典的離線計算，像HiveSQL，最終會變成一個MR／SPARK作業或者PESTO查詢在yarn上運行。對于流式的實時數據處理需求，我們上層有一個青藤平臺來托管FLINK在YARN上運行。對于模型訓練的場景，我們是用XLearning作為調度器，調度TensorFlow，XGBoost，MPI等訓練學習引擎?；赟park和XLearning，我們打造了亞瑟機器學習平臺，可以把數據處理流程和一些模型的訓練、預測流程做一個打通，方便用戶使用。

?

yarn技術改進

１.yarn技術實踐和演進

對yarn的一些改動，主要分成四個方面：（1）集群穩定性方面的優化。（2）對yarn的搶占機制做了優化。（3）yarn的調度性能提升。（4）計算集群小IO優化。

?

2.整個集群變大以后，對yarn調度系統來說面臨什么問題?

直觀的感覺來說，整個集群變大，節點就變多了，running 的 APP 也會增多。節點和APP增多會導致RM對外服務壓力變大，事件處理邏輯增多，事件處理壓力會比較大，并且對增加整個調度的壓力。因為你有很多的APP需要請求資源，你整個資源池又非常大，所以整個調度壓力是非常大的，怎么解決這個壓力的問題。還有整個狀態變化會非常多，這時候會有一些事件處理，在yarn原生的框架里面，事件處理是單線程的，會有各種各樣的問題，整個事件處理壓力非常大。針對這些問題我們做了一些針對性的優化。在大集群里面，機器故障會變得越來越頻繁，怎么應對機器故障對整個作業穩定性造成的影響，這也是比較重要的方面。

?

3.在RM方面做的一些優化

從幾個比較經典的Case來說一下。有一次我們升級整個集群的時候，導致整個集群掛掉，一次升級幾百個機器，直接導致RM事件雪崩，最終OOM掉。我們發現是RM和NM交互有一些冗余事件的，我們對冗余事件進行了一些優化。對于NM，我們設計了一個慢啟動的策略，如果NM剛啟動沒有必要維持每秒匯報一次，開始可以20秒匯報一次，下次10秒，下次5秒，最終恢復到正常，這樣會把整個RM的事件處理壓力降下來，最終升級集群對RM基本沒什么影響。最終升級瓶頸變成了我們的運維系統，不能并發升級太多機器。

?

HDFS是yarn非常底層的基礎設施，ResourceManager事件處理邏輯中有一些HDFS操作，HDFS卡一下，會造成整個事件處理邏輯卡住，最終整個集群卡住。分析發現RM對HDFS的操作主要集中在失敗APP的處理，不是非常核心的邏輯，解決方案也比較簡單粗暴，把HDFS的操作從同步改成異步。我們還對整個yarn事件處理邏輯進行排查，發現有一些像DNS的操作，在某些情況下也會比較卡，我們就把這種比較重IO的操作進行相應的優化，確保事件處理邏輯中都是快速的CPU操作，保證事件處理的高效和穩定。

?

經過優化之后，我們發現在集群規模比較大的時候，事件處理過程還是要消耗非常多的CPU，我們profile發現，大部分的CPU的消耗是處理NM節點信息的匯報，RM事件處理主要分幾個部分，有一些是節點級別的，有一些是APP級別的，有一些調度級別的。NM級別跟其他的是沒有太必要放在同一個線程處理，我們把它抽離出來，放在一個額外的線程上，這樣把大部分處理遷出去了，讓整個事件處理邏輯變得比較輕量。

?

2.6之后yarn支持狀態恢復，RM重啟理論上對APP是沒有影響的，可以把APP恢復出來，但是還是有一些比較小的缺陷，會造成APP的失敗，比如沒有把一些異常cover住，拋到AM，導致AM掛掉，token恢復在一些場景下也有問題。我們的RM升級是非常頻繁的，基本上2天左右就會升級新版本，集群上有一些非常重要的作業，所以失敗，對他們造成的影響會比較大。

?

4.在從節點上面怎么避免單點問題

yarn社區本身是有一個磁盤的故障監測機制的，基本的思路也會定期在磁盤上創建目錄，如果能創建成功說明這個磁盤是OK的，如果失敗就認為你這個磁盤有問題，這個比較簡單有效。但是在某些特定場景下，會有一些奇怪的磁盤問題，比如整個磁盤是好的，但是某個目錄是壞的，可能會導致某些特定的作業失敗。我們擴展了NM磁盤的黑名單功能，通過container的失敗信息做一些規則匹配，這樣可以定向發現一些磁盤問題，把疑似有問題的磁盤放在黑名單里面，不再向這個磁盤調度作業。

?

yarn有一個比較大的問題，如果你有一臺機器有問題，造成一些container調度失敗，并且系統沒有捕獲的話，會造成雪崩效應，比如一批container啟動失敗了，這臺機器資源看起來非常空閑，然后RM發現機器空閑，就調動更多container上來，然后越來越多的container失敗，最后導致很多APP運行失敗。社區提出了AM的黑名單機制，主要來解決AM的失敗問題，如果AM大量失敗，不往這臺機器上調度AM，APP內部依賴自己的黑名單機制，發現這些問題機器。我們覺得這樣可能會造成很多無效的container失敗，所以我們的解決思路是建立整個集群的黑名單，而不單獨是AM的黑名單。當我們通過一些規則發現有大量的container在某一臺機器失敗，或者這臺機器的container調度速度非常異常，我們會把這臺機器放到我們集群的黑名單里面，不再向這臺機器調度資源。

?

資源隔離方面，現在社區主要是用cgroup做一些內存和CPU的隔離，其他方面的隔離非常弱的，我們當時碰到一些場景比如磁盤打滿了，FD泄露、線程泄露的問題。曾經在上一家公司的時候寫過一個程序，有線程泄露的問題，泄露之后把整個機器的線程全用光了，這樣導致這個機器所有服務異常，計算框架計算不斷把這個問題task調度到其他機器上，最終把整個集群都打掛了。解決方案就是對container的線程數目，磁盤大小定期檢查，如果超過闕值，直接kill掉。

?

單臺機器的故障率比較低，但集群規模變大之后，整體故障率變得非常高。怎么發現這些機器是個問題。我們借助container失敗率做一個基本的判斷。如果是一臺機器失敗率高于正常值，可能是非常有問題的，需要人工檢查一下。還可以借助一些物理指標的異常檢測，因為在離線系統里面，CPU打得比較高的，load也比較高，所以當前這些指標可能不容易發現，用syscpu作為異常檢測指標，集群中經常有些機器task跑的比較慢，重啟機器就好了。一臺機器有問題會導致Task失敗，Task失敗會導致作業的失敗，我們做了一個失敗APP的歸因系統，可以從歸因系統里面發現一些問題機器。單純從作業失敗還不夠，我們正在做一個基于失敗TASK的歸因系統，因為TASK有容災重試機制，可能會掩蓋潛在問題。

?

5.yarn調度方面做的優化

yarn一個主要的功能，就是要調度整個集群的資源，它的視角是整個集群的節點信息，還有APP的資源請求信息，還有一些隊列信息。yarn的調度模型里面，邏輯是比較復雜的， 簡單說，先來一個節點，如果這個節點有一定資源的話，會對集群中的一級隊列做排序，然后選出最應該調度的隊列。選擇這個隊列之后找這個隊列下面的二級隊列進行排序，逐漸遞歸找到APP，選一個合適的APP進行調度，如果資源調度不上，再找下一個APP。調度邏輯是要耗費很大資源的，主要是各種排序。但整個排序真的有這么大必要嗎？

?

我們早期思路就是怎么減少整個排序的時間，減少排序時間從三方面著手，減少排序規模，減少單次排序時間，優化排序算法。如何減少排序規模？集群里有幾千個隊列，幾千個隊列是不是都需要資源？APP是不是都需要資源，是否都需要排序？實際場景中大部分是不需要資源和參與排序的，這樣把整個排序規模減小了。在調度單詞排序時，使用了java collection.sort()函數排序的，每次排序涉及到兩個元素的compare，怎么來減少compare的開銷？在yarn里面每一次compare的時候有很多可以可以優化的地方，比如計算一個隊列使用的資源量，有一些臨時對象可以cache住，最終縮小整個單次排序的時間。Collection.sort底層使用歸并排序，我們改成堆排序，經過這些優化后，差不多能夠支撐5000臺機器的規模。

?

優化之后還是存在一個很明顯的問題，調度的擴展性是不足的，因為整個排序過程都是在一個CPU里面，如果想利用更多CPU，會涉及到整個排序怎么切分，節點怎么切分、作業怎么切分，怎么讓資源分配達到均衡，怎么保證公平性，涉及到非常復雜的策略，非常難拆分。yarn調度是先選一個節點，然后再選APP，調度過程只看到一個節點的信息，而看不到整體的集群信息，整個調度策略是非常受限，很難加一些策略在里面。比如yarn本地化一個非常簡單的功能實現上比較復雜，在整個調度框架層面。如何來解決這個問題？

?

最終決定我們重寫調度邏輯，開發了Kwaischeduler。我們覺得在整個集群里面有一個上帝視角的，你可以拿到整個集群的資源使用情況和資源配置情況和每一個隊列、每個APP的資源需求量和資源的配置?；谶@些信息，我們能夠計算出來，應該給每一個APP來分配多少資源。然后App資源的分配過程我們完全可以并發起來，借助多線程的能力，去整個資源池里面搶這些資源。因為我們是先調度APP的，所以搶這些資源的時候，借鑒K8S的調度思路，先對節點進行過濾，然后按照不同的調度策略，給每個節點打分，每個策略可以有一個權重，從理論上來說每個APP都可以有自己的策略。Kwai scheduler上線后調度性能和調度策略擴展性不是問題，現在單集群的調度性能可以達到每秒鐘4萬多container，對比國內其他廠商和社區，我們的調度性能和擴展性上表現還不錯。

?

?

簡單介紹一下底層實現。首先主要分成兩部分，一部分是集群資源的預分配過程，把一些資源分配到每個APP，第二部分是APP怎么去每臺機器上競爭資源。有一個單獨線程定期會對集群情況做snapshot，基于snapshot來做一個上帝視角的資源分配。我們為每個APP分配出資源之后，就可以把APP丟到線程池里面并發搶資源，對相應的節點排序，選出分數最高的節點，最終你會有一個commit的過程，真正拿到資源。整個調度分配結束后，會把整個分配結果寫回到整個原生的yarn框架。

?

?

在計算集群里面有一個大的問題，就很多的小IO。在我們業務場景里面，快手的數據規模比較大比較大，經常是幾十萬個map，幾千reduce。一個map也沒有多少數據，可能就是250M，reduce單次shuffle取的數據非常小的，可能只有幾K幾十K，所以有很多的小IO，導致整個集群磁盤util非常高，但是磁盤讀寫速度非常慢。針對這個問題，我們對MR的shuffle過程做一個Cache。在shuffle過程中，當一個請求來的時候，我們分析一下這次shuffle過程有沒有可能產生比較多小IO，可以按需把shuffle數據放到cache里，只需要一次大的IO把數據搬到Cache里面，后面的shuffle請求可以直接從cache里面讀，消滅了后面多次小IO，通過這個我們優化，提升了整個的集群IO性能。

?

yarn為什么有搶占的問題，為什么K8S這些在線系統不會有搶占問題。yarn主要是離線調度系統，資源使用不像在線系統比較恒定，有一些突增，這意味著如果完全資源配額限制資源，會導致整個集群的資源利用率降低或者job的運行時間拉長。所以yarn允許你的資源使用超過配額。這帶來另一個問題，使用超過配額后，當另一個隊列需要資源的時候，能不能及時把這些資源釋放出來。在大部分情況下是可以的，因為離線系統的作業一般會比較快的結束。但是在特殊場景下，有可能是一個spark作業一直占著資源不釋放，可能會導致一些比較核心的作業拿不到資源。搶占主要是解決這個問題。但是在大部分的公司，搶占是沒有打開的，原因主要因為社區版本的搶占不太可控。會基于隊列的資源使用量來決定是否搶占，如果核心隊列資源使用超過配額太多， 可能會被非核心隊列搶占，存在比較大的風險。我們解讀這個問題的思路是基于一些核心隊列來觸發的搶占，搶占只能從核心的隊列觸發，被搶占的只是非核心隊列，這樣就解決低優先級作業搶占核心的作業問題。但是這個方案還是有些問題，如果使用資源超過配額的都是一些核心的作業，這時候怎么處理？我們主要思路是，希望構建整個集群的作業優先級體系，把作業重要性系統做一個全局拉起，這樣我們可以做一些隊列內部的搶占和跨核心隊列之間的搶占。

?

yarn的未來規劃

構建作業分級保障，現在我們yarn的集群規模比較大，大家使用的資源都非常多，但是這些資源有沒有用到真正比較重要的業務上，其實我們是有些疑問的，有多少無效的計算在里面，當然這個涉及到業務層的優化。為作業打一些作業的標簽，基于這些任務的標簽，以及優先級的特性，刻劃整個集群資源的使用情況，為預算或者其他的技術方案提供一些技術的底層支持。

?

我們現在單個yarn集群規模在國內是top級的，但是單集群畢竟是容量有限，我們后面會考慮多集群建設的方案，社區的federation方案在跨IDC方面有些問題，如何在業務透明的前提下，建設跨IDC集群有非常多問題需要解決。

?

yarn現在主要托管的是一些離線計算的資源，公司還有很多空閑資源沒有使用，怎么來使用這些空閑資源，怎么做到把一些合適的任務調入到一些比較空閑的機器上，當這個機器需要的時候，及時把任務遷移走，怎么減少業務相互的影響，底層這方面需要做什么支撐，這都需要探索。

總結

以上是生活随笔為你收集整理的YARN 在快手的应用实践与技术演进之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。