分享嘉賓：陳劍 虎牙 大數(shù)據(jù)架構(gòu)師

編輯整理：謝宇 北京郵電大學(xué)

出品平臺(tái)：DataFunTalk

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

平臺(tái)介紹

核心SLA定義

核心能力建設(shè)

未來展望

01平臺(tái)介紹

1. 發(fā)展歷程

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

混沌期：在2019年之前，業(yè)務(wù)各自搭建實(shí)時(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集群遷移到容器平臺(tái)實(shí)現(xiàn)容器化，同時(shí)增加了實(shí)時(shí)數(shù)倉支持和完善任務(wù)監(jiān)控保障。

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

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

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

02核心SLA定義

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

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

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

2. 核心SLA

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

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

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

03核心能力建設(shè)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（2）運(yùn)行時(shí)資源評(píng)估

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

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

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

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

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

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

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

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

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

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

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

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

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

針對(duì)這一需求，平臺(tái)做了兩個(gè)層面的抽象：

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

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

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

（5）算力均衡

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

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

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

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

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

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

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

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

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

04未來展望

未來展望分為四個(gè)方向：

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

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

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

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

05精彩問答

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

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

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

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

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

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

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

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

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

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