隨著實(shí)時數(shù)倉與實(shí)時計(jì)算的發(fā)展，越來越多的業(yè)務(wù)利用實(shí)時計(jì)算平臺開發(fā)實(shí)時數(shù)據(jù)。與離線任務(wù)不同，實(shí)時任務(wù)需要更小的時延和更高的可靠性，如何更好地保障實(shí)時數(shù)據(jù)的質(zhì)量是每個實(shí)時數(shù)倉、實(shí)時計(jì)算平臺都需要解決的問題。本次的分享內(nèi)容為虎牙實(shí)時計(jì)算SLA實(shí)踐之路。

01平臺介紹

1. 發(fā)展歷程

虎牙業(yè)界領(lǐng)先的實(shí)時內(nèi)容創(chuàng)造與直播互動能力離不開有力的基礎(chǔ)支撐，實(shí)時計(jì)算平臺作為一個關(guān)鍵技術(shù)，發(fā)展歷程主要分為四個階段：

混沌期：在2019年之前，業(yè)務(wù)各自搭建實(shí)時計(jì)算引擎，導(dǎo)致技術(shù)棧的不統(tǒng)一和資源利用率不高。

統(tǒng)一期：2019年之后統(tǒng)一使用Flink，提供集中任務(wù)和資源的管理。主要采用jar包模式和config模式開發(fā)任務(wù)，具有基礎(chǔ)運(yùn)維保障。

完善期：引入Flinksql，實(shí)現(xiàn)了全球化能力支持海外業(yè)務(wù)的需要，任務(wù)從Yarn集群遷移到容器平臺實(shí)現(xiàn)容器化，同時增加了實(shí)時數(shù)倉支持和完善任務(wù)監(jiān)控保障。

轉(zhuǎn)型期：轉(zhuǎn)型期主要分為兩個部分：服務(wù)化的轉(zhuǎn)型和智能化的實(shí)踐。

2.?平臺架構(gòu)概覽

數(shù)據(jù)從各端采集進(jìn)入Datahub之后流向數(shù)據(jù)湖，然后分流到離線數(shù)倉和實(shí)時數(shù)倉，最后在應(yīng)用層使用。其中實(shí)時計(jì)算平臺橫跨了整個流程，應(yīng)用于每個流程中。

02核心SLA定義

轉(zhuǎn)型期關(guān)注用戶核心問題，平臺化思維向服務(wù)化思維轉(zhuǎn)型。

1. 平臺和服務(wù)思維

平臺思維主要關(guān)注平臺的可用性、任務(wù)穩(wěn)定性、信息全面性、監(jiān)控完善性。在轉(zhuǎn)型期中，虎牙實(shí)時計(jì)算平臺更加關(guān)注用戶關(guān)心的問題訴求，而減少其他問題對用戶造成的干擾。

2. 核心SLA

用戶在使用平臺時，關(guān)注的問題不是任務(wù)的穩(wěn)定性、平臺的可用性，而是數(shù)據(jù)的時效性是否符合要求。于是實(shí)時計(jì)算平臺定義了延時達(dá)標(biāo)率作為核心SLA，對于不同時延需求進(jìn)行不同的保障，從而對用戶需求進(jìn)行管理并進(jìn)行統(tǒng)計(jì)。

核心SLA代表從平臺化思維向服務(wù)化思維轉(zhuǎn)變，不再推脫由于其他系統(tǒng)出錯導(dǎo)致的責(zé)任，眼光更加開闊，真正關(guān)注用戶的需求。此外，核心SLA使得平臺的覆蓋面更廣，比如用戶的代碼導(dǎo)致的時延問題，平臺也要去幫助用戶進(jìn)行代碼的優(yōu)化。而通過關(guān)注延時達(dá)標(biāo)率SLA，平臺團(tuán)隊(duì)可以較為靈活地選擇對SLA影響最大的問題優(yōu)先解決。平臺從平臺化思維到服務(wù)化思維的轉(zhuǎn)變，使團(tuán)隊(duì)的價值更加凸顯。

平臺具有很全面的指標(biāo)數(shù)據(jù)，但用戶實(shí)際不需要了解這些東西。所以平臺應(yīng)該解決用戶最關(guān)注的問題。同時對于任務(wù)的成本，平臺應(yīng)該盡可能幫助用戶建立問題分析的能力，提升使用效率。

03核心能力建設(shè)

核心能力建設(shè)主要分為延時需求管理及監(jiān)控、任務(wù)分析能力、資源評估、擴(kuò)縮容能力等。

1. 需求管理及監(jiān)控

對于每個任務(wù)，平臺提供用戶定義其延時需求，而平臺針對該需求進(jìn)行監(jiān)控。目前采用的是source的消費(fèi)時間減去消息隊(duì)列寫入時間，再加上checkpoint的總耗時。Flink自帶的latency tracking對于生產(chǎn)環(huán)境性能有影響，并且只反映Flink內(nèi)部的處理因素，無法反應(yīng)端到端的延時，比如消息隊(duì)列里的消息積壓。

因此，平臺層面提供一個輕量級的監(jiān)控，無需要花費(fèi)太大的成本，并且作為大范圍任務(wù)的監(jiān)控，相對準(zhǔn)確能反映出問題。

2. 任務(wù)分析能力

在豐富專業(yè)指標(biāo)的基礎(chǔ)上，平臺提供了任務(wù)分析的能力，包括異常分析、延時分析和資源分析，針對一些典型問題平臺給出判斷。當(dāng)一個任務(wù)的延時或者cpu利用率很高，之前需要用戶去查看是哪個節(jié)點(diǎn)出問題，找到節(jié)點(diǎn)后觀察線程堆棧，明確利用率占用在哪里。平臺幫助用戶完成這一過程，算子消耗了cpu或者是一直在gc等問題可以通過系統(tǒng)定位到，減小用戶分析成本。

3. 資源評估以及動態(tài)擴(kuò)縮容

資源評估主要分為兩個階段：上線前和運(yùn)行時。在上線前會對資源初始化進(jìn)行評估，根據(jù)用戶使用的topic流量相關(guān)數(shù)據(jù)計(jì)算算子的復(fù)雜度，進(jìn)行資源的初始評估。同時，平臺開發(fā)了基于調(diào)試模塊的壓測模擬評估，在任務(wù)上線之前進(jìn)行壓測的評估。

在運(yùn)行時有一個性能診斷引擎，根據(jù)指標(biāo)輸入因子，通過一些規(guī)則引擎進(jìn)行性能診斷。當(dāng)出現(xiàn)性能問題時，引擎會給出資源擴(kuò)縮容的建議。當(dāng)獲取到擴(kuò)縮容建議后，平臺會提供動態(tài)擴(kuò)縮容的能力。

（1）調(diào)試壓測

調(diào)試壓測會經(jīng)歷三個階段：

首先是調(diào)試配置。用戶設(shè)置調(diào)試的時長，當(dāng)運(yùn)行時間達(dá)到設(shè)置時間后自動停止。第二點(diǎn)是資源的配置，針對調(diào)試任務(wù)設(shè)置任意的資源配置。第三個是source的抽樣，以及放大抽樣。用戶不需要造數(shù)據(jù)而是使用真實(shí)數(shù)據(jù)進(jìn)行調(diào)試，并且可以指定某個source的數(shù)據(jù)流進(jìn)行按比例放大。壓測主要針對上線前的測試，防止高峰期資源不足。第四點(diǎn)是sink的模擬，把結(jié)果輸出到控制臺或者真實(shí)的存儲上。

第二階段是編譯任務(wù)提交。這部分包括source/sink的替換，sql驗(yàn)證編譯和資源配置的申請。在調(diào)試模式下，資源以用戶粒度申請并支持資源的緩存，保證多次執(zhí)行任務(wù)的情況下保持資源的可用。

第三階段是任務(wù)運(yùn)行期間。任務(wù)運(yùn)行期間具有控制臺的輸出，支持表格和控制流、真實(shí)存儲，和正式任務(wù)一致具有完整的監(jiān)控分析，還具有定時停止和集群預(yù)留緩存。

（2）運(yùn)行時資源評估

運(yùn)行時資源評估具有一個規(guī)則引擎，根據(jù)任務(wù)監(jiān)控的數(shù)據(jù)和相應(yīng)的規(guī)則，給出一些診斷結(jié)果。資源配置模塊通過診斷結(jié)果，產(chǎn)生一個推薦資源的配置，最終這個配置下發(fā)到具體的任務(wù)中，用戶可以自己定義是否應(yīng)用該配置。

（3）任務(wù)擴(kuò)縮容

任務(wù)擴(kuò)容面臨兩個問題，一個是耗時過長導(dǎo)致影響SLA，另一個是資源的不足。當(dāng)容器平臺處于高峰期時，可能存在資源被搶占的情況。基于這個問題，平臺在擴(kuò)容時，確定資源使用量之后，先確保資源申請到再進(jìn)行任務(wù)的切換。對于一般的任務(wù)該方法能夠?qū)⒂绊懣刂圃诜昼娭畠?nèi)。除此以外，當(dāng)機(jī)房資源完全不足時還支持跨機(jī)房的一鍵切換。

上面的圖是資源推薦的曲線圖，紅框內(nèi)的資源推薦數(shù)與高峰期的數(shù)據(jù)基本一致。

下圖是資源的利用情況，紅框代表應(yīng)用了動態(tài)擴(kuò)縮容之后的任務(wù)狀態(tài)，在應(yīng)用動態(tài)擴(kuò)縮容之前任務(wù)之間有許多空隙，導(dǎo)致利用率較低。在應(yīng)用之后空隙被填補(bǔ)了很多，整體效果較好。

（4）任務(wù)容災(zāi)

任務(wù)容災(zāi)抽象為三個層面：輸入、計(jì)算和輸出。

輸入和輸出主要針對消息隊(duì)列的情況下，遇到集群雪崩、流量暴漲或者線路異常等情況。在計(jì)算層面，可能會出現(xiàn)任務(wù)的異常導(dǎo)致任務(wù)需要重啟，還有資源不足如何高效遷移。

在計(jì)算層面的容災(zāi)主要是任務(wù)的恢復(fù)。平臺將其分為任務(wù)層和平臺層。在任務(wù)層會有一個默認(rèn)的重啟策略以及用戶自定義的策略。

另外，平臺基于ZooKeeper的高可用策略，ZooKeeper 單節(jié)點(diǎn)的故障可能導(dǎo)致任務(wù)的批量失敗。原因是平臺采用任務(wù)的故障率判斷任務(wù)是否失敗，而ZooKeeper單節(jié)點(diǎn)的異常導(dǎo)致任務(wù)同時接收到很多異常信息而導(dǎo)致任務(wù)的批量失敗。針對ZooKeeper的異常，平臺使其對于任務(wù)的敏感度降低而避免。

在平臺層要做到高效遷移，一鍵跨機(jī)房的遷移。其核心問題在于同步底層狀態(tài)，當(dāng)前平臺基于混合云存儲來實(shí)現(xiàn)，在數(shù)據(jù)儲存之后最終會同步到不用的機(jī)房。還有資源的預(yù)申請避免資源不足的情況。

還有一點(diǎn)是基于公司的容器平臺去做的，容器平臺對于某些節(jié)點(diǎn)的宿主機(jī)負(fù)載非常高時，會執(zhí)行一個驅(qū)逐策略導(dǎo)致任務(wù)的失敗。因此平臺通過優(yōu)先級保障，比如按任務(wù)冷卻等策略來避免該問題。

對于輸入輸出層，最終體現(xiàn)的是數(shù)據(jù)調(diào)度的能力。當(dāng)一個topic出現(xiàn)問題的時候，需要快速地將數(shù)據(jù)調(diào)度到另一個機(jī)房或是集群。

針對這一需求，平臺做了兩個層面的抽象：

對消息隊(duì)列進(jìn)行了抽象：平臺會分配一個邏輯的topic，用戶只需要關(guān)注邏輯的topic，不用關(guān)心topic在哪個集群上。平臺在分配時，會考慮用戶實(shí)際數(shù)據(jù)的位置。有了這層抽象后，平臺可以高效地完成數(shù)據(jù)切換集群或是跨機(jī)房的遷移。

對Flink的庫表層進(jìn)行了抽象：具體的每個表會關(guān)聯(lián)一個topic，這個topic同樣可以動態(tài)切換，并且在切換過程中對上層無感知。

實(shí)際的效果如上圖所示，其中虛線的部分表示可以基本做到動態(tài)切換，不需要用戶去做應(yīng)用上的改動。中間會依賴云存儲進(jìn)行狀態(tài)的同步。

（5）算力均衡

Flink的TaskManager中，slot基于內(nèi)存均分而cpu共享無法隔離。

于是，考慮到一種情況：有abc三種節(jié)點(diǎn)，其中并行度分別為2，4，2。

在進(jìn)行分配時，首先將其分為四個group，可能會出現(xiàn)上圖的情況。假設(shè)a任務(wù)的負(fù)載非常高的話，會導(dǎo)致TaskManager1的負(fù)載非常高。TaskManager2的負(fù)載比較低，就會出現(xiàn)算力不均衡的問題。主要原因有兩點(diǎn)：

一是Flink在分配group時，TaskManager1已經(jīng)注冊完成但TaskManager2未注冊完，導(dǎo)致前面兩個group都注冊到TaskManager1上。

二是SharingGroup在選擇group時是無序的，意味著分配不可控。

針對以上兩點(diǎn)，平臺做了兩點(diǎn)優(yōu)化。

第一個是延緩任務(wù)的調(diào)度，比如任務(wù)包含的task數(shù)較多而且負(fù)載較高，平臺會等到TaskManager1和TaskManager2都創(chuàng)建完成后再去分配。

第二是在分配slot之前，對group先做一個排序，確保負(fù)載高的group分配完成。

改造之前節(jié)點(diǎn)會分配到相同的服務(wù)器上，并且節(jié)點(diǎn)又是負(fù)載相對高的任務(wù)，導(dǎo)致算力非常不均衡。經(jīng)過優(yōu)化之后，最終的結(jié)果是SLA從年初的70%提升到年末的99%，均值資源利用率從12%提到了21%。綠色條形代表使用的core數(shù)，曲線代表利用率，從20年10月份隨著資源相關(guān)的功能發(fā)布，使用的資源明顯下降，利用率明顯的上升。

04未來展望

未來展望分為四個方向：

一是易用性，平臺本身功能需要強(qiáng)化的地方還很多，比如sql、上下游連通性、希望結(jié)合業(yè)務(wù)進(jìn)行端到端的產(chǎn)品探索，做一些端到端的產(chǎn)品。

二是穩(wěn)定性，平臺的智能化方面還遠(yuǎn)不足，保障承諾仍需要更高，做到99.9%甚至99.99%的SLA保障。

三是開放性，希望能和社區(qū)有更多的互動，一起學(xué)習(xí)一起分享。

四是統(tǒng)一性，主要是流批一體化，需要在存儲層、計(jì)算層和元數(shù)據(jù)層統(tǒng)一。

05精彩問答

Q：資源利用率是怎么計(jì)算的？

A：資源利用率依托容器平臺，容器平臺層面會針對每一個任務(wù)涉及到的具體節(jié)點(diǎn)，統(tǒng)計(jì)出每一個節(jié)點(diǎn)的利用率情況。我們根據(jù)利用率向上劃分到不同的任務(wù)上，再分到不同的業(yè)務(wù)中。

Q：易用性的上下游連通是指什么？

A：用戶在使用我們平臺時，會有一些庫表的支持，這種庫表對應(yīng)不同的存儲，就會有一個上下游的關(guān)系。易用性是指往上再抽象一層，針對一些具體的業(yè)務(wù)場景做一些端到端的產(chǎn)品。比如實(shí)時分析平臺，數(shù)據(jù)的實(shí)時性是由計(jì)算平臺承擔(dān)的，用戶只需要知道使用哪些數(shù)據(jù)做分析，不需要關(guān)注上下游細(xì)節(jié)的東西。

Q：什么情況下會動態(tài)驅(qū)逐？

A：容器平臺會根據(jù)主機(jī)的利用率情況決定，是否需要驅(qū)逐一些容器。我們會考慮到容器平臺把我們的任務(wù)驅(qū)逐，導(dǎo)致任務(wù)失敗率過高。因此我們會在上面做一些策略，避免容器平臺把重要任務(wù)驅(qū)逐。

Q：能介紹一下性能診斷引擎嗎？

A：我們建立了一個規(guī)則引擎，根據(jù)過往的經(jīng)驗(yàn)做了規(guī)則的配置，然后根據(jù)這些指標(biāo)判斷我們的算力夠不夠，算不算高負(fù)載，還要根據(jù)數(shù)據(jù)的延遲來判斷。一般的擴(kuò)縮容方案，更多的是通過容器的cpu利用率或者是其他資源層面的去判斷。這種方式有一個核心問題，可能出現(xiàn)在資源層面的數(shù)據(jù)沒有問題，但是業(yè)務(wù)側(cè)數(shù)據(jù)延遲非常高的情況。因此我們的性能診斷引擎會根據(jù)業(yè)務(wù)側(cè)的數(shù)據(jù)延遲判斷，使得擴(kuò)縮容機(jī)制更加精確，效果更好。

Q：擴(kuò)縮容是橫向擴(kuò)還是縱向擴(kuò)？

A：我們目前主要是橫向擴(kuò)。