[[244671]]

圖片來(lái)自包圖網(wǎng)

【51CTO.com原創(chuàng)稿件】WAIC 實(shí)時(shí)流計(jì)算平臺(tái)為新浪微博提供可靠的毫秒級(jí)和秒級(jí)實(shí)時(shí)數(shù)據(jù)處理服務(wù)，通過(guò)提供統(tǒng)一的數(shù)據(jù)源和配置化接入方式，幫助提高新浪微博實(shí)時(shí)作業(yè)的開發(fā)效率，降低部門開發(fā)與運(yùn)營(yíng)的成本。

2018 年 5 月 18-19 日，由 51CTO 主辦的全球軟件與運(yùn)維技術(shù)峰會(huì)在北京召開。

在“高并發(fā)與實(shí)時(shí)處理”分會(huì)場(chǎng)，新浪微博實(shí)時(shí)流技術(shù)平臺(tái)負(fù)責(zé)人廖博帶來(lái)了《WAIC 實(shí)時(shí)流計(jì)算平臺(tái)的成長(zhǎng)和繁衍》的主題演講。

本文將按照如下四個(gè)階段分享微博實(shí)時(shí)流計(jì)算平臺(tái)的搭建歷程，以及在創(chuàng)建過(guò)程中的一些問(wèn)題和解決方案：

• 初入實(shí)時(shí)流計(jì)算
• 實(shí)時(shí)流計(jì)算平臺(tái)初建
• 實(shí)時(shí)流計(jì)算平臺(tái)發(fā)展
• 總結(jié) DQRA 設(shè)計(jì)模式

初入實(shí)時(shí)流計(jì)算

首先介紹一下我們實(shí)時(shí)流計(jì)算平臺(tái)開發(fā)歷程：

• 2015 年，我進(jìn)入新浪微博。當(dāng)年，我們利用實(shí)時(shí)流計(jì)算做出了物料池系統(tǒng)。
• 2016 年，我們進(jìn)行了用戶實(shí)時(shí)興趣反饋系統(tǒng)的開發(fā)。
• 2017 年，我們接入了一些與多媒體相關(guān)的，如人臉識(shí)別系統(tǒng)的建設(shè)。同年，我們也開始進(jìn)行實(shí)時(shí)流計(jì)算平臺(tái)的初建。
• 2018 年，我們開啟了 WAIC 實(shí)時(shí)流計(jì)算平臺(tái)。

上圖是實(shí)時(shí)流計(jì)算的技術(shù)背景，常用的計(jì)算引擎有：Spark、Streaming、Flink、Storm、Flume 和 Kafka 等一些中間件。

我們 WAIC 實(shí)時(shí)流計(jì)算平臺(tái)中，主要用到的計(jì)算引擎是：Storm、Kafka、Flume 和 Flink。

上圖是實(shí)時(shí)流計(jì)算的第一階段。這是一個(gè)經(jīng)典的架構(gòu)，它通過(guò)利用 Flume，將業(yè)務(wù)系統(tǒng)里的實(shí)時(shí)流日志數(shù)據(jù)寫入 Kafka。

然后再利用 Storm 去讀取 Kafka 里的數(shù)據(jù)，最后將數(shù)據(jù)進(jìn)行相應(yīng)的業(yè)務(wù)邏輯處理。

在該階段，我們主要完成了如下兩項(xiàng)工作：

• 讓微博“接入”實(shí)時(shí)流計(jì)算功能。
• 當(dāng)數(shù)據(jù)處理出現(xiàn)失敗時(shí)，使用 Kafka 來(lái)執(zhí)行必要的數(shù)據(jù)回滾，從而解決問(wèn)題。

上圖是第一階段相應(yīng)的數(shù)據(jù)成果。彼時(shí)的數(shù)據(jù)量和集群個(gè)數(shù)都比較少，因此主要存在的問(wèn)題包括：

• 人工工作量比較多，即：面對(duì)需求時(shí)，全靠人編碼。
• 代碼重復(fù)率比較高，異常排查的方式較為簡(jiǎn)陋，全靠登錄到服務(wù)器上，去 Grep 日志。
• 監(jiān)控的方式則全靠腳本。

上圖是第一階段所遺留的一些問(wèn)題。

實(shí)時(shí)流計(jì)算平臺(tái)初建

那么隨著實(shí)時(shí)流計(jì)算的頻繁使用、業(yè)務(wù)場(chǎng)景的增多、以及監(jiān)控需求的提升，我們意識(shí)到需要搭建一個(gè)實(shí)時(shí)流的計(jì)算平臺(tái)。

我們當(dāng)時(shí)所提出的平臺(tái)目標(biāo)主要包括：

• 研發(fā)一個(gè)工作量可以沉淀，并且可配置的開發(fā)框架。
• 統(tǒng)一所有的監(jiān)控，打造一個(gè)統(tǒng)一的監(jiān)控平臺(tái)。

這是第二階段實(shí)時(shí)流的初步架構(gòu)圖。在此，我們的接入日志方式豐富了許多。如圖，我們既通過(guò) Scribe 進(jìn)行收集、又從 Kafka 以及 Mcq 里面讀取數(shù)據(jù)。

然后通過(guò) Scribe、或者其他的數(shù)據(jù)同步服務(wù)，將它們接入到實(shí)時(shí)隊(duì)列之中，最后在不同的業(yè)務(wù)場(chǎng)景下，利用不同的實(shí)時(shí)集群進(jìn)行處理。

自研 WeiPig 框架

為了降低開發(fā)人員上手實(shí)時(shí)任務(wù)開發(fā)的門檻，我們自行研發(fā)了一個(gè) WeiPig 框架。

它具有如下四個(gè)主要特點(diǎn)：

• 配置化開發(fā)。對(duì)于一些簡(jiǎn)單的開發(fā)需求，我們只需編寫 WeiPig 開發(fā)文件，便可實(shí)現(xiàn)。
• 插件式編程。它提供一個(gè)插件式編程的編碼規(guī)范。對(duì)于初期的一些功能需求，我們按照相應(yīng)的規(guī)范進(jìn)行編碼，即我們通過(guò)編寫 WeiPig 文件，來(lái)滿足各種需求。
• 通用解決方案。因?yàn)?WeiPig 是一個(gè)針對(duì)實(shí)時(shí)流而開發(fā)的應(yīng)用框架，所以它需要滿足供應(yīng)鏈上所有不同類型的實(shí)時(shí)流需求。
• 統(tǒng)一貢獻(xiàn)機(jī)制。使不同的業(yè)務(wù)團(tuán)隊(duì)，能夠按照同一套規(guī)范來(lái)進(jìn)行相應(yīng)的插件開發(fā)，并提供相應(yīng)的插件功能。同時(shí)，他們也可以按照同樣的規(guī)范和機(jī)制，來(lái)使用其他團(tuán)隊(duì)所提供的功能插件。

同時(shí)，我們需要通過(guò)該 WeiPig 框架，讓所有開發(fā)人員的工作模式“沉淀”下去，實(shí)現(xiàn)公司內(nèi)各個(gè)部門的共享與協(xié)作。

統(tǒng)一監(jiān)控平臺(tái)

如前所述，在第一階段，我們的監(jiān)控實(shí)現(xiàn)方式基本上是：靠那些運(yùn)行在不同服務(wù)器上的腳本，進(jìn)行日志數(shù)據(jù)的采集，然后再發(fā)送報(bào)警郵件。

而進(jìn)入第二階段之后，我們利用如上圖所示的實(shí)時(shí)流統(tǒng)一計(jì)算與監(jiān)控平臺(tái)，對(duì)作業(yè)情況予以了展示與配置。

即：該系統(tǒng)既可以展示相應(yīng)的數(shù)據(jù)監(jiān)控指標(biāo)，又可以對(duì)數(shù)據(jù)監(jiān)控指標(biāo)進(jìn)行相應(yīng)的報(bào)警配置。

而這些監(jiān)控指標(biāo)數(shù)據(jù)都是通過(guò)不同的搜集工具進(jìn)行采集，然后錄入到 MySQL 數(shù)據(jù)庫(kù)之中。

上圖是第二階段相應(yīng)的成果。雖然此時(shí)已經(jīng)有了 WeiPig 開發(fā)框架，但是我們的人工工作量依然不少。

由于 WeiPig 的插件主要是由平臺(tái)方的幾名開發(fā)人員來(lái)實(shí)現(xiàn)，因此插件數(shù)量不但較少，而且他們的工作量也達(dá)到了 80%。

另外，代碼的重復(fù)率則僅占 50% 左右，這直接導(dǎo)致了異常排查的效率仍處于較低的水平。

同時(shí)，在監(jiān)控配置上，我們?nèi)孕枰謩?dòng)配置，以及通過(guò)編寫腳本，來(lái)搜集相關(guān)的指標(biāo)數(shù)據(jù)。

在第二階段之后，我們遺留下了不少問(wèn)題，包括：

• 權(quán)限機(jī)制的欠缺
• 缺乏統(tǒng)一的資源調(diào)度
• 問(wèn)題排查相對(duì)較慢
• 碎片資源相對(duì)較多(主要是因?yàn)槲覀兪褂玫亩际切┬〖?，這導(dǎo)致產(chǎn)生了大量遺留的冗余資源，閑置在系統(tǒng)中)
• 缺乏高可靠的保障
• 開發(fā)效率較低

實(shí)時(shí)流計(jì)算平臺(tái)發(fā)展

在步入實(shí)時(shí)流計(jì)算平臺(tái)的第三階段之后，我們提高了相應(yīng)的宏觀目標(biāo)，即：

• 提高公司的開發(fā)生產(chǎn)效率，節(jié)省重復(fù)建設(shè)的成本。
• 可視化各項(xiàng)操作。

上圖是當(dāng)前實(shí)時(shí)流計(jì)算平臺(tái)的架構(gòu)圖。數(shù)據(jù)流邏輯如下：

• 用戶通過(guò) UI 交互客戶端、以及 Weiclient 等交互模塊，將作業(yè)提交給控制中心。
• 控制中心進(jìn)行初步的權(quán)限校驗(yàn)和資源審核之后，將資源提交給任務(wù)調(diào)度。
• 任務(wù)調(diào)度將相應(yīng)的作業(yè)提交給對(duì)應(yīng)的集群 Weibox。
• 如果作業(yè)提交成功，Weibox 會(huì)把相應(yīng)的作業(yè)信息重新返回給控制中心。
• 控制中心將作業(yè)通過(guò)用戶交互客戶端返回給用戶結(jié)果。同時(shí)，它會(huì)將作業(yè)信息同步給管理服務(wù)后臺(tái)。
• 用戶通過(guò)管理服務(wù)后臺(tái)的客戶端，去操作自己在集群上面的功能?？刂浦行募饶軠p少已占用的資源，又能為每一個(gè)團(tuán)隊(duì)實(shí)現(xiàn)資源控制。

控制中心初現(xiàn)

由于前期各種作業(yè)(如 Storm)在向集群提交的時(shí)候，許多開發(fā)人員會(huì)自行配置一個(gè)本地環(huán)境，以實(shí)現(xiàn)直接提交，這就造成了平臺(tái)方很難對(duì)集群進(jìn)行有效的管控。

因此對(duì)于我們第三階段的控制中心而言，其主要目標(biāo)是：

• 解決作業(yè)隨意提交，治理集群上作業(yè)混亂的現(xiàn)象。
• 對(duì)集群資源進(jìn)行統(tǒng)一管理，從而避免過(guò)多的資源浪費(fèi)。

上圖是實(shí)時(shí)流計(jì)算平臺(tái)的控制中心架構(gòu)圖。其流程如下：

• “基礎(chǔ)模塊”通過(guò)權(quán)限校驗(yàn)和資源審核，將作業(yè)提交給“作業(yè)上線流程”服務(wù)。
• “作業(yè)上線流程”調(diào)用后置的檢查模塊，檢查該作業(yè)是否在集群上運(yùn)行成功，以及判斷該作業(yè)所占用的資源、是否為它在提交時(shí)指定了資源量。
• 如果“作業(yè)上線流程”服務(wù)提交作業(yè)成功，那么“資源決策服務(wù)”調(diào)用動(dòng)態(tài)資源調(diào)節(jié)模塊，在集群上定時(shí)(如：每小時(shí)或每天)檢查該作業(yè)所使用和處理的數(shù)據(jù)量，以及每條數(shù)據(jù)的處理時(shí)長(zhǎng)。籍此，該模塊運(yùn)用簡(jiǎn)單的公式，來(lái)判斷該作業(yè)是否需要占這么多資源。

上述提到過(guò)，一些開發(fā)人員可能會(huì)通過(guò)在自己的本機(jī)上配置相應(yīng)的作業(yè)提交環(huán)境，以實(shí)現(xiàn)將作業(yè)提交到集群之中。

那么為了管控對(duì)應(yīng)的業(yè)務(wù)組在集群上占用的資源量，我們?cè)?ldquo;資源決策服務(wù)”里，調(diào)用到了作業(yè)識(shí)別模塊。

資源配置策略

為了提高公司的生產(chǎn)開發(fā)效率，我們?cè)诘谌A段實(shí)施了資源配置策略。同時(shí)，我們的核心目標(biāo)點(diǎn)是：通過(guò)第二階段的 WeiPig 開發(fā)框架，來(lái)鼓勵(lì)各個(gè)業(yè)務(wù)團(tuán)隊(duì)貢獻(xiàn)相應(yīng)的插件。

其實(shí) WeiPig 是一套規(guī)范協(xié)議，大家在貢獻(xiàn)插件之前需要增加學(xué)習(xí)上的投入。因此，對(duì)于一些已經(jīng)實(shí)施了計(jì)算能力的業(yè)務(wù)方來(lái)說(shuō)，雖然有利于將舊平臺(tái)遷移過(guò)來(lái)，但是他們不太愿意投入此類學(xué)習(xí)的成本。

所以我們想出了用資源去換取 WeiPig 前向發(fā)展的方法。我們將所有的平臺(tái)資源按照基礎(chǔ)資源、彈性資源、獎(jiǎng)勵(lì)資源和平臺(tái)資源，四個(gè)方向進(jìn)行劃分。

其中基礎(chǔ)資源僅占 1%，基本上只有一、兩臺(tái)機(jī)器。彈性資源有 20%，各個(gè)公司根據(jù)業(yè)務(wù)量和業(yè)務(wù)等級(jí)進(jìn)行劃分，當(dāng)業(yè)務(wù)量多的時(shí)候，每一個(gè)業(yè)務(wù)都可以有自己的重要程度和優(yōu)先級(jí)。

值得一提的是：獎(jiǎng)勵(lì)資源為 30%。它通過(guò)兩方面標(biāo)準(zhǔn)：WeiPig 里貢獻(xiàn)的 Function 數(shù)量，和這些通用 Function 會(huì)被多少業(yè)務(wù)方所使用到，來(lái)進(jìn)行公式算法上的衡量。

如果你貢獻(xiàn)的多，而且被其他業(yè)務(wù)方使用的也比較多，那么我們就會(huì)從所有平臺(tái)資源的 30% 中，給你劃分出更多的資源。

實(shí)時(shí)對(duì)賬系統(tǒng)

為了滿足某些高成功率場(chǎng)景的需求，我們?cè)诘谌A段自行設(shè)計(jì)了一個(gè)實(shí)時(shí)對(duì)賬系統(tǒng)。

該系統(tǒng)的主要成績(jī)是：滿足實(shí)時(shí)計(jì)算平臺(tái)完成 6 個(gè) 9 的數(shù)據(jù)成功率需求。

上圖是實(shí)時(shí)對(duì)賬系統(tǒng)的一個(gè)簡(jiǎn)單架構(gòu)圖。在數(shù)據(jù)處理開始時(shí)，我們會(huì)將數(shù)據(jù)寫入實(shí)時(shí)對(duì)賬系統(tǒng)，并打上開始標(biāo)志。

同時(shí)，實(shí)時(shí)對(duì)賬系統(tǒng)會(huì)將該數(shù)據(jù)的開始處理、和結(jié)束處理的標(biāo)志，存放到存儲(chǔ)服務(wù)上。

而圖中下方的離線定時(shí)服務(wù)，會(huì)定時(shí)查詢實(shí)時(shí)對(duì)賬系統(tǒng)，并進(jìn)行如下判斷：

• 如果一條數(shù)據(jù)既有入賬，又有根據(jù)處理結(jié)束值所求的出賬，則認(rèn)為該條數(shù)據(jù)已處理完成，即對(duì)賬成功。
• 如果一條數(shù)據(jù)只有數(shù)據(jù)處理的開始，卻沒有處理結(jié)束的標(biāo)志，則該條數(shù)據(jù)可能出現(xiàn)被丟掉的情況，我們需要重試。
• 如果一條數(shù)據(jù)只有數(shù)據(jù)處理結(jié)束，卻沒有數(shù)據(jù)處理成功的標(biāo)志，則會(huì)發(fā)出相應(yīng)的報(bào)警，我們需要查找相應(yīng)的問(wèn)題。

穩(wěn)定性服務(wù)平臺(tái)

另外，在第三階段，我們將第二階段的“統(tǒng)一監(jiān)控平臺(tái)”升級(jí)成了“穩(wěn)定性服務(wù)平臺(tái)”。

其目標(biāo)有如下三點(diǎn)：

• 通用監(jiān)控指標(biāo)的數(shù)據(jù)統(tǒng)一生成。前面在第二階段的監(jiān)控統(tǒng)一平臺(tái)中，我們必須在界面上去配置要監(jiān)控的指標(biāo)項(xiàng)目，通過(guò)編寫相應(yīng)的采集代碼，然后把腳本部署到服務(wù)器上，以方便監(jiān)控的采集。

但是在第三階段的穩(wěn)定性服務(wù)平臺(tái)上，一個(gè)作業(yè)被提交到集群上之后，穩(wěn)定性服務(wù)平臺(tái)會(huì)對(duì)集群上處理的數(shù)據(jù)量、處理延遲、錯(cuò)誤量等通用指標(biāo)進(jìn)行統(tǒng)一生成。

• 集群資源負(fù)載均衡的監(jiān)控。其實(shí) Storm 不像 Hadoop、Flink、Yum，它并沒有資源調(diào)度的管理系統(tǒng)。

因此，它在自己做管理資源時(shí)，會(huì)出現(xiàn)在一個(gè)集群中，某個(gè)服務(wù)器的 CPU 利用率已達(dá) 90%，而其他服務(wù)器的 CPU 利用率只占有 50%～60% 的情況。所以我們自行研發(fā)了對(duì)集群資源負(fù)載均衡的監(jiān)控。

• 監(jiān)控指標(biāo)采集平臺(tái)，統(tǒng)一所有監(jiān)控?cái)?shù)據(jù)的采集。

這里展示的是實(shí)時(shí)流計(jì)算平臺(tái)穩(wěn)定性服務(wù)的架構(gòu)圖。左側(cè)的數(shù)據(jù)采集平臺(tái)包括：Storm 指標(biāo)項(xiàng)目數(shù)據(jù)收集、Kafka 數(shù)據(jù)堆積量的數(shù)據(jù)收集、日志收集平臺(tái)、監(jiān)控腳本運(yùn)行平臺(tái)、和服務(wù)器硬件資源的收集。

這是一個(gè)比較簡(jiǎn)易的、便捷的資源負(fù)載均衡的監(jiān)控服務(wù)。完成統(tǒng)一采集之后，系統(tǒng)調(diào)用數(shù)據(jù)存儲(chǔ)服務(wù)，經(jīng)由服務(wù)平臺(tái)的管理服務(wù)平臺(tái)、運(yùn)維服務(wù)平臺(tái)、和第三方服務(wù)平臺(tái)，對(duì)外面開發(fā)人員提供相應(yīng)的服務(wù)。

上圖是第三階段相應(yīng)的成果。目前，我們的平臺(tái)每天能處理大約一千多億的數(shù)據(jù)量，TPS 大約有百萬(wàn)每秒，作業(yè)個(gè)數(shù)則每天約有 150～200 個(gè)。

如今無(wú)論是多媒體相關(guān)的數(shù)字計(jì)算需求，還是微博相關(guān)的處理需求，我們的人工工作量已相對(duì)較少了，主要的工作量集中在編寫 WeiPig 相應(yīng)的配置文件上。相應(yīng)的代碼重復(fù)率也比較低，同樣主要集中在 WeiPig 文件上。

另外，由于我們主要是到 HDFS 上去搜集和管控相應(yīng)的日志，因此異常排查的效率適中。

而對(duì)于監(jiān)控方式而言，我們大部分采用的是自動(dòng)生成的方式，所以只對(duì)一些特殊要求才進(jìn)行監(jiān)控配置。

當(dāng)然，目前的實(shí)時(shí)流計(jì)算平臺(tái)仍有兩個(gè)遺留問(wèn)題：

• 缺乏系統(tǒng)性的資源調(diào)度。我們需要有一個(gè)資源調(diào)度系統(tǒng)，來(lái)實(shí)時(shí)獲知集群上的作業(yè)到底應(yīng)該運(yùn)行在哪一臺(tái)服務(wù)器上。

目前我們采用的一種簡(jiǎn)易方式是：搜集各臺(tái)服務(wù)器上的資源情況，然后用自己的程序進(jìn)行判斷和處理。如果某一臺(tái)機(jī)器利用率高于其他服務(wù)器20%的話，那么我們認(rèn)為其負(fù)載是不均衡的。

• 日志收集方案不統(tǒng)一。

總結(jié) DQRA 設(shè)計(jì)模式

我們?cè)趯?shí)時(shí)流計(jì)算開發(fā)的過(guò)程中，一邊搭建業(yè)務(wù)平臺(tái)，一邊解決了不少問(wèn)題。因此我們總結(jié)出了一套 DQRA 的設(shè)計(jì)模式。

DQRA 詳解

它們分別是：

• Difficulty(邏輯復(fù)雜度)
• Quantity(數(shù)據(jù)量)
• Reliability(可靠性)
• Asynchronous(異步時(shí)序性)

因此，我們認(rèn)為：面對(duì)大多數(shù)的需求，我們可以把問(wèn)題的實(shí)現(xiàn)拆解為上述四個(gè)屬性中的某種。

例如：邏輯復(fù)雜度有難、中、易;數(shù)據(jù)量有大、中、小;可靠性是高、中、弱;等方面。

上述便是 DQRA 可能出現(xiàn)的不同組合，以及所對(duì)應(yīng)的不同解決方法。

DQRA 案例分析

下面我們會(huì)介紹一個(gè)簡(jiǎn)單案例，它包含如下特性：

• D 難，表示實(shí)現(xiàn)的復(fù)雜度，即實(shí)時(shí)流作業(yè)中需要處理的邏輯比較難。
• Q 中，表示數(shù)據(jù)量可能一般，可能是從幾千萬(wàn)到十億之間。
• R 高，表示可靠性高，即成功率要求高，如前面提到的 6 個(gè) 9 的數(shù)據(jù)處理成功率。

具體來(lái)說(shuō)，它是一個(gè)圖像分析與處理類系統(tǒng)，需要具有持續(xù)穩(wěn)定的服務(wù)保證。因此，系統(tǒng)穩(wěn)定是第一位的。

其次，它要求數(shù)據(jù)處理的成功率大于 6 個(gè) 9，從而能應(yīng)對(duì)單日 5000 萬(wàn)的數(shù)據(jù)量。

因此，我們通過(guò)上述三個(gè)方面來(lái)實(shí)現(xiàn)該系統(tǒng)的需求：

• 首先，針對(duì)系統(tǒng)的穩(wěn)定性，我們采用的是內(nèi)網(wǎng)和阿里云的“雙保險(xiǎn)”網(wǎng)絡(luò)部署方式。
• 其次，由于涉及到圖片的下載，而我們?cè)谧龇治鰰r(shí)，調(diào)用的是在線模型預(yù)測(cè)方式。

因此，為了避免可能出現(xiàn)的圖片分析失敗，我們采用了實(shí)時(shí)對(duì)賬系統(tǒng)，實(shí)現(xiàn)了必要的重試處理。

[[244673]]

廖博，新浪微博實(shí)時(shí)流技術(shù)平臺(tái)負(fù)責(zé)人，曾就職于搜狐、雅虎研究院、支付寶等公司參與 Data Highway、大數(shù)據(jù)系統(tǒng)、數(shù)據(jù)倉(cāng)庫(kù)、UUS(User Understanding Service)等第一代大數(shù)據(jù)生態(tài)系統(tǒng)的搭建工作;現(xiàn)就職于新浪微博，主導(dǎo)和開發(fā)實(shí)時(shí)流計(jì)算平臺(tái)，基于該平臺(tái)之上完成多媒體分析平臺(tái)、物料池系統(tǒng)、樣本生成平臺(tái)等多個(gè)子系統(tǒng)的開發(fā)和建設(shè)。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】