導讀：
大家下午好，我叫張佳煌，來自於虎牙大資料平臺，主要負責大資料的儲存和計算。虎牙公司作為國內知名的直播平臺，在直播遊戲化技術、虛實融合、虛實互動內容生產領域持續創新，這也得益於離線上混部計算資源的支援。
今天給大家分享的是大規模離線上混部在虎牙的落地實踐，主要分為幾個部分：
背景
架構以及落地效果
關鍵技術實現
未來展望
01
背景
1. 資源側存在的問題
① 資源利益率低
第一張圖是線上業務的資源使用情況，在凌晨以及白天線上業務的資源利用率低，晚上的資源利用率慢慢提高，全天的平均利用率只有17%。離線業務大部分業務主要都集中在凌晨，所以凌晨的CPU利用率很高，全天平均利用率55%。另外是我們目前AI訓練在用的GPU訓練機器，這部分機器的使用時間不太可控，CPU利用率全天都比較波動，全天平均利用率15%。
以上主要是資源利用率低的一個問題。
② 資源交付不及時
除了資源利用率低的問題，當前還存在資源交付不及時的問題。
對於線上業務的場景，比如比賽場景，在比賽時間段是資源使用的一個高發期，需要大量的資源，或者某個主播需要入住虎牙，這時的流量突增需要大量資源的擴容，如果線上業務無法獲得大量的資源擴容，各種故障就會頻發。有比賽時會用到很多的資源，沒有比賽時資源很富餘，這樣全天的CPU利用率會更低。
離線業務也是同樣的問題，比如老闆突然需要資料，或者今天的一些營收資料需要重新跑，就需要快速增加資源把資料跑出來，到週末沒有adhoc查詢時，就會有很多資源富餘。
以上主要是資源互動的一個問題。
2. 我們的解法思路
針對資源利用率低，以及資源互動的問題，有什麼解法？
針對資源利用率低問題，我們的解法思路是透過分時複用將資源的利用率全部填滿。我們引入了多種不同的業務場景，透過時間差異的方式打平全天的資源利用率。
針對資源互動的問題，我們需要對現有的資源做改造，完成資源的彈性排程，並解決彈性面臨的儲存計算分離的問題。
線上業務與離線業務資源打平，並結合彈性資源，我們稱這兩種結合為離線上混部。離線上混部有一個重要的問題，就是穩定性的保障。對於離線業務小波動的影響可能不大，對於線上業務稍微有一點波動，影響面就會很廣，可能會出現各種延遲，各種請求超時。
——
02
架構以及落地效果
針對穩定性保障問題，我們虎牙現在的整體架構是怎樣的？首先看一下整體架構，以及我們針對整體架構的落地效果。
1. 容器化技術方案選擇
在容器方案的選型上，行業一般會採用宣告式的方式，即申請多少資源，就在容器啟動多少資源的pod，這種方式會存在碎片資源太多的問題，最終會同線上業務一樣搶宿主機的資源，導致整體利用率不高。
虎牙的解法是，不論線上業務在容器的宿主機上用了多少資源，剩餘的真實資源給離線業務用。這樣可以保證離線業務時刻都能拿到最大資源而不浪費。這種做法的資源是動態變更的，要一直去保證資源的調整。
行業的選型相對固定，基本上固定可利用空間很小，因為資源申請多少就時多少，所以看一下我們在架構層面上的實現是怎樣的。
2. 架構實現-資源層
資源層上層的容器化主要由容器化團隊負責，我們負責容器化後怎樣使用全部資源，並把資源使用好。我們將大資料的儲存與計算節點全部做了容器化，在資源層面上，容器會定時從neo秒級監控系統獲取資源資訊，然後將資源的可利用空間透過動態的方式返回給大資料平臺，最後根據資源資訊去動態地調整yarn叢集資源，以保證資源的動態。
在做容器化改造時，很多老的大資料機型都沒有磁碟空間，所以在資源層面上，我們將磁碟做了複用，保障了hdfs與yarn容器化之後，計算操作依然有磁碟空間使用，解決了老機型改造問題。
以上是我們在資源層面上，資源調整的實現方式。
3. 架構實現-隔離
大家都知道離線上混部會面臨網路的問題，而且我們為了消化多個機房的資源問題，需要架構設計能解決網路上相互影響的問題，來保證業務的穩定。
機房實現層面上，我們在機房與機房之間做了QOS限速
，離線業務會放在低優先順序的佇列跑，如果線上業務的頻寬突增，QOS就會將離線業務頻寬限制下來，保障線上業務的網路穩定。
另外就是要解決多機房的問題。除了idc與idc的問題，還要解決idc與雲上機房的問題。因為雲上機房的交換機由雲廠商控制，所以idc與雲上機房通訊的網路方式無法透過QOS限速。
我們採用了離線專用vpc閘道器，讓離線業務與雲上資源的頻寬透過vpc閘道器傳輸
，這樣就保障了離線業務與線上業務的隔離，使用網路時就不會發生衝突。
在hdfs與yarn容器化時，如果hdfs儲存節點資源受影響，將會變成慢節點並較大的影響穩定性。
我們在宿主機層面上做了網絡卡頻寬共享
，如果hdfs頻寬用得少，yarn的頻寬就可以用得多，相當於兩者之間有一個共享頻寬包，可以將最大的資源使用完。另外一個問題是容器化之後，從原有模式變成儲存計算分離的模式，頻寬消耗會更高。我們在hdfs與yarn的層面做了優先本地讀取，也會去適配hdfs與yarn之間機架的問題以及就近問題，這樣頻寬消耗就不會那麼高。
以上主要是我們資源層面上的架構，以及網路隔離上面的架構。
4. 落地效果
讓我們看一下透過我們虎牙的架構，最終落地下來的效果怎樣。
黃線是線上業務的資源使用情況，上面是混部後的資源使用情況，混部後CPU平均利用率達到51%，相比於線上業務原本的17%，提升200%。將實際剩餘資源動態的供應給大資料容器，相當於將線上業務原本用不上的資源使用上。目前我們65%的資源來自於離線上混部，並且支撐了當年的S10賽事，離線線上業務成本節省40%多。離線的資源消耗情況是很大的，40%多的成本已經是很龐大的成本節省。
——
03
關鍵技術實現
接下來看一下關鍵技術的實現，以及我們遇到了哪些問題，解決了哪些問題。
1. 混部改造挑戰
第一個難點是
線上業務的資源分佈廣，線上業務以兩地三中心的方式部署，多中心的機房用來保障資源的穩定性，這意味著使用線上業務的資源，還需要解決多機房使用的問題。
第二個難點是資源複雜
。虎牙除了大資料線上業務，還有云遊戲和AI的一些GPU機器，雲遊戲、AI都是window系統。AI的GPU機器磁碟空間很低主要做訓練，所以整體的資源表現很複雜。
第三個難點是網路隔離
。離線上混部從原本單一業務的部署，變成線上業務與離線業務混合部署，本地讀寫模式變成儲存計算分離的模式，線上業務與離線業務共用網絡卡，還要解決網路隔離，保障線上業務不受影響。
最後一個難點是穩定性保障
。因為hdfs的穩定性比yarn的穩定性要求更高，它的每個節點基本上都是有狀態的模式，所以這種模式下要保障hdfs不受影響，因為它的等級已經與線上業務的等級一樣高。
2. 多機房部署
接下來看一下多機房資源問題的解決。
我們的多機房有多idc和多雲廠商的模式，如果按照hdfs原有的使用模式，很難將雲上的資源利用起來，如果要利用起來意味著線上業務的機房沒有儲存。如果要將資源用起來，還可以將頻寬透過專線傳輸，但是在計算的節點沒有儲存，全部是傳輸的模式，專線頻寬承受不住，對離線業務也有影響。因為在雲上的機房計算，然後時刻把資料寫回idc的中心機房，效能會比就近寫資料慢特別多。
我們引進了自己改造的一個遮蔽底層儲存的hyfs協議，上層全部訪問sys協議，包括原資料全部都儲存在虎牙hyfs裡面，訪問協議時就可以實現就近讀寫的方式，比如在雲上計算，儲存時就可以利用雲廠商的物件儲存功能，將資料就近的儲存在雲廠商的物件儲存
。多機房部署的雲資料是我們自己管理的，意味著我們要能保證資料使用的就近問題。
對於使用方也很方便，hive只需要改location就可以，其他地方不需要變更，使用方式簡單，還能解決多機房的儲存問題。
3. 異構資源利用
針對cpu記憶體的比例差異，我們採用的是捆綁的方式拉伸，如果給的CPU配比較少，但記憶體比較多，我們會實時的檢測資源使用情況，然後對資源進行超賣，儘量將短板資源的資源量全部用完，這樣資源使用就更充足。
另外一個磁碟問題，我們將一些線上業務以及雲遊戲機器複用時，有些機器原本沒有磁碟。對於需要shuffer的任務，我們會在任務提交時，對任務做畫像的歸類排程，執行任務時判斷小範圍內有沒有shuffer，然後將磁碟消耗小的任務排程到無磁碟的機器上面，這就是混合標籤的排程。為了保證資源的使用，我們會讓任務既能排程到無磁碟的標籤佇列裡，又能排程到有磁碟的標籤佇列裡，這樣就不存在某個標籤使用完後，剩下的資源其他任務不能使用的情況。
彈性排程可能會讓計算節點資源不穩定，而ApplicationMaster是有狀態的，如果ApplicationMaster被Kill，整個任務又需要重新執行，那麼我們在標籤排程時將AM排程到穩定的資源佇列裡，就保障容器彈性伸縮的同時，保證任務不受影響。
我們的k8s會不斷地做cgroup 的update調整資源。我們在每個pod裡都會感知資源多少的變化，然後針對資源去做更新，把它的最大資源上報，不斷去調整資源量。pod也會對資源做健康檢測，檢視資源的實際使用情況，然後不斷地對資源進行超賣，儘量將資源跑到真實的物理最大值。
4. 穩定性保障
以下是穩定性保障實現時遇到的問題：
機器負載高
。hdfs和yarn一起啟動後，整臺宿主機的負載高。主要原因是hdfs使用的group的cpu分片模式，在使用過程中頻繁的切換分片導致負載發生溢位。解決辦法是將hdfs與固定的cpu繫結實現效能和負載的保障。
網絡卡頻寬不夠
。線上業務與離線業務放在一起，整臺宿主機的網絡卡資源基本上被佔用滿，線上業務會出現各種丟包等問題。針對網絡卡頻寬的問題，我們做了QOS限速，並引入共享頻寬包來隔離頻寬。
機房內部頻寬滿
。將宿主機容器化之後，識別hdfs與yarn時ip是不一樣的，資料讀寫由本地讀寫變成儲存計算分離的模式，機房整體頻寬被拉高。為了避免跨平面傳輸導致的頻寬問題，我們也是使用QOS的方式進行限速。
因為我們做了資源超賣的邏輯，而且pod資源是動態調整的模式，意味著pod資源如果超賣或者調整過度，可能會導致整個pod直接發生OOMKilled，所以也做了穩定性的保障，保證pod在資源調整的情況下，也不會發生OOMKilled的驅逐。
以下是做資源超賣以及資源伸縮時實現的一些保障。
如果資源用得比較高，必須要kill程序時，我們會秒級地對pod資源做使用檢查，然後透過container程序的記憶體、cpu、load以及執行時間去計算一個分數，選擇一個得分最高的程序並kill程序，來保證執行在pod上面的其他程序不受影響，從而保障整體資源的穩定性。
可以看到我們當前控制的比較穩定，在每天上億個container執行的情況下，任務觸發的kill程序只有100多個，並沒有因為資源超賣和彈性伸縮，導致每天大量的container一直在發生kill的操作。
——
04
未來展望
最後講一下離線上混步我們還有哪些事情可以做。
在資源混部的情況下，我們的資源利用率還不夠平穩，由於超賣時不知道container級別的資源使用細節，所以我們用的是邊使用邊調整的模式，因此資源的利用率會比較波動。我們希望未來將資源利用率做得更平穩。
虎牙現在有很多機房落地在二三線城市，在未來我們也希望將邊緣機房做混部，將機房的資源利用起來，複用到我們自制的分析計算或者實時的分析計算裡。
今天就分享就到這裡，謝謝大家。
閱讀更多技術乾貨文章、下載講師PPT，請關注
微信公眾號“DataFunSummit”。
分享嘉賓：張佳煌 虎牙 大資料架構師
編輯整理：劉兆磊 棗莊學院
出品平臺：DataFunTalk
01/分享嘉賓
02/報名看直播 免費領PPT
03/關於我們
DataFun：
專注於大資料、人工智慧技術應用的分享與交流。發起於2017年，在北京、上海、深圳、杭州等城市舉辦超過100+線下和100+線上沙龍、論壇及峰會，已邀請超過2000位專家和學者參與分享。其公眾號 DataFunTalk 累計生產原創文章700+，百萬+閱讀，14萬+精準粉絲。