導讀：随着實時計算的發展，越來越多的業務利用實時計算平台開發實時資料。與離線任務不同，實時任務需要更小的時延和更高的可靠性，如何更好地保障實時資料的品質是每個實時計算平台都需要解決的問題。本次的分享題目為虎牙實時計算SLA實踐之路，主要分為以下幾個部分：
- 平台介紹
- 核心SLA定義
- 核心能力建設
- 未來展望
--
01 平台介紹
1. 發展曆程
虎牙業界領先的實時内容創造與直播互動能力離不開有力的基礎支撐，實時計算平台作為一個關鍵技術，發展曆程主要分為四個階段：
- 混沌期：在2019年之前，業務各自搭建實時計算引擎，導緻技術棧的不統一和資源使用率不高。
- 統一期：2019年之後統一使用Flink，提供集中任務和資源的管理。主要采用jar包模式和config模式開發任務，具有基礎運維保障。
- 完善期：引入Flinksql，實作了全球化能力支援海外業務的需要，任務從Yarn叢集遷移到容器平台實作容器化，同時增加了實時數倉支援和完善任務監控保障。
- 轉型期：轉型期主要分為兩個部分：服務化的轉型和智能化的實踐。
2. 平台架構概覽
資料從各端采集進入Datahub之後流向資料湖，然後分流到離線數倉和實時數倉，最後在應用層使用。其中實時計算平台橫跨了整個流程，應用于每個流程中。
--
02 核心SLA定義
轉型期關注使用者核心問題，平台化思維向服務化思維轉型。
1. 平台和服務思維
平台思維主要關注平台的可用性、任務穩定性、資訊全面性、監控完善性。在轉型期中，虎牙實時計算平台更加關注使用者關心的問題訴求，而減少其他問題對使用者造成的幹擾。
2. 核心SLA
使用者在使用平台時，關注的問題不是任務的穩定性、平台的可用性，而是資料的時效性是否符合要求。于是實時計算平台定義了延時達标率作為核心SLA，對于不同時延需求進行不同的保障，進而對使用者需求進行管理并進行統計。
核心SLA代表從平台化思維向服務化思維轉變，不再推脫由于其他系統出錯導緻的責任，眼光更加開闊，真正關注使用者的需求。此外，核心SLA使得平台的覆寫面更廣，比如使用者的代碼導緻的時延問題，平台也要去幫助使用者進行代碼的優化。而通過關注延時達标率SLA，平台團隊可以較為靈活地選擇對SLA影響最大的問題優先解決。平台從平台化思維到服務化思維的轉變，使團隊的價值更加凸顯。
平台具有很全面的名額資料，但使用者實際不需要了解這些東西。是以平台應該解決使用者最關注的問題。同時對于任務的成本，平台應該盡可能幫助使用者建立問題分析的能力，提升使用效率。
--
03 核心能力建設
核心能力建設主要分為延時需求管理及監控、任務分析能力、資源評估、擴縮容能力等。
1. 需求管理及監控
對于每個任務，平台提供使用者定義其延時需求，而平台針對該需求進行監控。目前采用的是source的消費時間減去消息隊列寫入時間，再加上checkpoint的總耗時。Flink自帶的latency tracking對于生産環境性能有影響，并且隻反映Flink内部的處理因素，無法反應端到端的延時，比如消息隊列裡的消息積壓。
是以，平台層面提供一個輕量級的監控，無需要花費太大的成本，并且作為大範圍任務的監控，相對準确能反映出問題。
2. 任務分析能力
在豐富專業名額的基礎上，平台提供了任務分析的能力，包括異常分析、延時分析和資源分析，針對一些典型問題平台給出判斷。當一個任務的延時或者cpu使用率很高，之前需要使用者去檢視是哪個節點出問題，找到節點後觀察線程堆棧，明确使用率占用在哪裡。平台幫助使用者完成這一過程，算子消耗了cpu或者是一直在gc等問題可以通過系統定位到，減小使用者分析成本。
3. 資源評估以及動态擴縮容
資源評估主要分為兩個階段：上線前和運作時。在上線前會對資源初始化進行評估，根據使用者使用的topic流量相關資料計算算子的複雜度，進行資源的初始評估。同時，平台開發了基于調試子產品的壓測模拟評估，在任務上線之前進行壓測的評估。
在運作時有一個性能診斷引擎，根據名額輸入因子，通過一些規則引擎進行性能診斷。當出現性能問題時，引擎會給出資源擴縮容的建議。當擷取到擴縮容建議後，平台會提供動态擴縮容的能力。
（1）調試壓測
調試壓測會經曆三個階段：
首先是調試配置。使用者設定調試的時長，當運作時間達到設定時間後自動停止。第二點是資源的配置，針對調試任務設定任意的資源配置。第三個是source的抽樣，以及放大抽樣。使用者不需要造資料而是使用真實資料進行調試，并且可以指定某個source的資料流進行按比例放大。壓測主要針對上線前的測試，防止高峰期資源不足。第四點是sink的模拟，把結果輸出到控制台或者真實的存儲上。
第二階段是編譯任務送出。這部分包括source/sink的替換，sql驗證編譯和資源配置的申請。在調試模式下，資源以使用者粒度申請并支援資源的緩存，保證多次執行任務的情況下保持資源的可用。
第三階段是任務運作期間。任務運作期間具有控制台的輸出，支援表格和控制流、真實存儲，和正式任務一緻具有完整的監控分析，還具有定時停止和叢集預留緩存。
（2）運作時資源評估
運作時資源評估具有一個規則引擎，根據任務監控的資料和相應的規則，給出一些診斷結果。資源配置子產品通過診斷結果，産生一個推薦資源的配置，最終這個配置下發到具體的任務中，使用者可以自己定義是否應用該配置。
（3）任務擴縮容
任務擴容面臨兩個問題，一個是耗時過長導緻影響SLA，另一個是資源的不足。當容器平台處于高峰期時，可能存在資源被搶占的情況。基于這個問題，平台在擴容時，确定資源使用量之後，先確定資源申請到再進行任務的切換。對于一般的任務該方法能夠将影響控制在分鐘之内。除此以外，當機房資源完全不足時還支援跨機房的一鍵切換。
上面的圖是資源推薦的曲線圖，紅框内的資源推薦數與高峰期的資料基本一緻。
下圖是資源的利用情況，紅框代表應用了動态擴縮容之後的任務狀态，在應用動态擴縮容之前任務之間有許多空隙，導緻使用率較低。在應用之後空隙被填補了很多，整體效果較好。
（4）任務容災
任務容災抽象為三個層面：輸入、計算和輸出。
輸入和輸出主要針對消息隊列的情況下，遇到叢集雪崩、流量暴漲或者線路異常等情況。在計算層面，可能會出現任務的異常導緻任務需要重新開機，還有資源不足如何高效遷移。
在計算層面的容災主要是任務的恢複。平台将其分為任務層和平台層。在任務層會有一個預設的重新開機政策以及使用者自定義的政策。
另外，平台基于ZooKeeper的高可用政策，ZooKeeper 單節點的故障可能導緻任務的批量失敗。原因是平台采用任務的故障率判斷任務是否失敗，而ZooKeeper單節點的異常導緻任務同時接收到很多異常資訊而導緻任務的批量失敗。針對ZooKeeper的異常，平台使其對于任務的敏感度降低而避免。
在平台層要做到高效遷移，一鍵跨機房的遷移。其核心問題在于同步底層狀态，目前平台基于混合雲存儲來實作，在資料儲存之後最終會同步到不用的機房。還有資源的預申請避免資源不足的情況。
還有一點是基于公司的容器平台去做的，容器平台對于某些節點的主控端負載非常高時，會執行一個驅逐政策導緻任務的失敗。是以平台通過優先級保障，比如按任務冷卻等政策來避免該問題。
對于輸入輸出層，最終展現的是資料排程的能力。當一個topic出現問題的時候，需要快速地将資料排程到另一個機房或是叢集。
針對這一需求，平台做了兩個層面的抽象：
- 對消息隊列進行了抽象：平台會配置設定一個邏輯的topic，使用者隻需要關注邏輯的topic，不用關心topic在哪個叢集上。平台在配置設定時，會考慮使用者實際資料的位置。有了這層抽象後，平台可以高效地完成資料切換叢集或是跨機房的遷移。
- 對Flink的庫表層進行了抽象：具體的每個表會關聯一個topic，這個topic同樣可以動态切換，并且在切換過程中對上層無感覺。
實際的效果如上圖所示，其中虛線的部分表示可以基本做到動态切換，不需要使用者去做應用上的改動。中間會依賴雲存儲進行狀态的同步。
（5）算力均衡
Flink的TaskManager中，slot基于記憶體均分而cpu共享無法隔離。
于是，考慮到一種情況：有abc三種節點，其中并行度分别為2，4，2。
在進行配置設定時，首先将其分為四個group，可能會出現上圖的情況。假設a任務的負載非常高的話，會導緻TaskManager1的負載非常高。TaskManager2的負載比較低，就會出現算力不均衡的問題。主要原因有兩點：
一是Flink在配置設定group時，TaskManager1已經注冊完成但TaskManager2未注冊完，導緻前面兩個group都注冊到TaskManager1上。
二是SharingGroup在選擇group時是無序的，意味着配置設定不可控。
針對以上兩點，平台做了兩點優化。
第一個是延緩任務的排程，比如任務包含的task數較多而且負載較高，平台會等到TaskManager1和TaskManager2都建立完成後再去配置設定。
第二是在配置設定slot之前，對group先做一個排序，確定負載高的group配置設定完成。
改造之前節點會配置設定到相同的伺服器上，并且節點又是負載相對高的任務，導緻算力非常不均衡。經過優化之後，最終的結果是SLA從年初的70%提升到年末的99%，均值資源使用率從12%提到了21%。綠色條形代表使用的core數，曲線代表使用率，從20年10月份随着資源相關的功能釋出，使用的資源明顯下降，使用率明顯的上升。
--
04 未來展望
未來展望分為四個方向：
- 一是易用性，平台本身功能需要強化的地方還很多，比如sql、上下遊連通性、希望結合業務進行端到端的産品探索，做一些端到端的産品。
- 二是穩定性，平台的智能化方面還遠不足，保障承諾仍需要更高，做到99.9%甚至99.99%的SLA保障。
- 三是開放性，希望能和社群有更多的互動，一起學習一起分享。
- 四是統一性，主要是流批一體化，需要在存儲層、計算層和中繼資料層統一。
--
05 精彩問答
Q：資源使用率是怎麼計算的？
A：資源使用率依托容器平台，容器平台層面會針對每一個任務涉及到的具體節點，統計出每一個節點的使用率情況。我們根據使用率向上劃分到不同的任務上，再分到不同的業務中。
Q：易用性的上下遊連通是指什麼？
A：使用者在使用我們平台時，會有一些庫表的支援，這種庫表對應不同的存儲，就會有一個上下遊的關系。易用性是指往上再抽象一層，針對一些具體的業務場景做一些端到端的産品。比如實時分析平台，資料的實時性是由計算平台承擔的，使用者隻需要知道使用哪些資料做分析，不需要關注上下遊細節的東西。
Q：什麼情況下會動态驅逐？
A：容器平台會根據主機的使用率情況決定，是否需要驅逐一些容器。我們會考慮到容器平台把我們的任務驅逐，導緻任務失敗率過高。是以我們會在上面做一些政策，避免容器平台把重要任務驅逐。
Q：能介紹一下性能診斷引擎嗎？
A：我們建立了一個規則引擎，根據過往的經驗做了規則的配置，然後根據這些名額判斷我們的算力夠不夠，算不算高負載，還要根據資料的延遲來判斷。一般的擴縮容方案，更多的是通過容器的cpu使用率或者是其他資源層面的去判斷。這種方式有一個核心問題，可能出現在資源層面的資料沒有問題，但是業務側資料延遲非常高的情況。是以我們的性能診斷引擎會根據業務側的資料延遲判斷，使得擴縮容機制更加精确，效果更好。
Q：擴縮容是橫向擴還是縱向擴？
A：我們目前主要是橫向擴。
今天的分享就到這裡，謝謝大家。
閱讀更多技術幹貨文章，請關注微信公衆号“DataFunTalk”
關于我們：
DataFun：專注于大資料、人工智能技術應用的分享與交流。發起于2017年，在北京、上海、深圳、杭州等城市舉辦超過100+線下和100+線上沙龍、論壇及峰會，已邀請近1000位專家和學者參與分享。其公衆号 DataFunTalk 累計生産原創文章500+，百萬+閱讀，13萬+精準粉絲。
注：歡迎轉載，轉載請留言或私信。