隨著實時數倉與實時計算的發展，越來越多的業務利用實時計算平臺開發實時數據。與離線任務不同，實時任務需要更小的時延和更高的可靠性，如何更好地保障實時數據的質量是每個實時數倉、實時計算平臺都需要解決的問題。本次的分享內容為虎牙實時計算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：我們目前主要是橫向擴。