[[244671]]

圖片來自包圖網

【51CTO.com原創稿件】WAIC 實時流計算平臺為新浪微博提供可靠的毫秒級和秒級實時數據處理服務，通過提供統一的數據源和配置化接入方式，幫助提高新浪微博實時作業的開發效率，降低部門開發與運營的成本。

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

在“高并發與實時處理”分會場，新浪微博實時流技術平臺負責人廖博帶來了《WAIC 實時流計算平臺的成長和繁衍》的主題演講。

本文將按照如下四個階段分享微博實時流計算平臺的搭建歷程，以及在創建過程中的一些問題和解決方案：

• 初入實時流計算
• 實時流計算平臺初建
• 實時流計算平臺發展
• 總結 DQRA 設計模式

初入實時流計算

首先介紹一下我們實時流計算平臺開發歷程：

• 2015 年，我進入新浪微博。當年，我們利用實時流計算做出了物料池系統。
• 2016 年，我們進行了用戶實時興趣反饋系統的開發。
• 2017 年，我們接入了一些與多媒體相關的，如人臉識別系統的建設。同年，我們也開始進行實時流計算平臺的初建。
• 2018 年，我們開啟了 WAIC 實時流計算平臺。

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

 

我們 WAIC 實時流計算平臺中，主要用到的計算引擎是：Storm、Kafka、Flume 和 Flink。

上圖是實時流計算的第一階段。這是一個經典的架構，它通過利用 Flume，將業務系統里的實時流日志數據寫入 Kafka。

然后再利用 Storm 去讀取 Kafka 里的數據，最后將數據進行相應的業務邏輯處理。

在該階段，我們主要完成了如下兩項工作：

• 讓微博“接入”實時流計算功能。
• 當數據處理出現失敗時，使用 Kafka 來執行必要的數據回滾，從而解決問題。

上圖是第一階段相應的數據成果。彼時的數據量和集群個數都比較少，因此主要存在的問題包括：

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

上圖是第一階段所遺留的一些問題。

實時流計算平臺初建

那么隨著實時流計算的頻繁使用、業務場景的增多、以及監控需求的提升，我們意識到需要搭建一個實時流的計算平臺。

我們當時所提出的平臺目標主要包括：

• 研發一個工作量可以沉淀，并且可配置的開發框架。
• 統一所有的監控，打造一個統一的監控平臺。

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

然后通過 Scribe、或者其他的數據同步服務，將它們接入到實時隊列之中，最后在不同的業務場景下，利用不同的實時集群進行處理。

自研 WeiPig 框架

為了降低開發人員上手實時任務開發的門檻，我們自行研發了一個 WeiPig 框架。

它具有如下四個主要特點：

• 配置化開發。對于一些簡單的開發需求，我們只需編寫 WeiPig 開發文件，便可實現。
• 插件式編程。它提供一個插件式編程的編碼規范。對于初期的一些功能需求，我們按照相應的規范進行編碼，即我們通過編寫 WeiPig 文件，來滿足各種需求。
• 通用解決方案。因為 WeiPig 是一個針對實時流而開發的應用框架，所以它需要滿足供應鏈上所有不同類型的實時流需求。
• 統一貢獻機制。使不同的業務團隊，能夠按照同一套規范來進行相應的插件開發，并提供相應的插件功能。同時，他們也可以按照同樣的規范和機制，來使用其他團隊所提供的功能插件。

同時，我們需要通過該 WeiPig 框架，讓所有開發人員的工作模式“沉淀”下去，實現公司內各個部門的共享與協作。

統一監控平臺

如前所述，在第一階段，我們的監控實現方式基本上是：靠那些運行在不同服務器上的腳本，進行日志數據的采集，然后再發送報警郵件。

而進入第二階段之后，我們利用如上圖所示的實時流統一計算與監控平臺，對作業情況予以了展示與配置。

即：該系統既可以展示相應的數據監控指標，又可以對數據監控指標進行相應的報警配置。

而這些監控指標數據都是通過不同的搜集工具進行采集，然后錄入到 MySQL 數據庫之中。

上圖是第二階段相應的成果。雖然此時已經有了 WeiPig 開發框架，但是我們的人工工作量依然不少。

由于 WeiPig 的插件主要是由平臺方的幾名開發人員來實現，因此插件數量不但較少，而且他們的工作量也達到了 80%。

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

同時，在監控配置上，我們仍需要手動配置，以及通過編寫腳本，來搜集相關的指標數據。

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

• 權限機制的欠缺
• 缺乏統一的資源調度
• 問題排查相對較慢
• 碎片資源相對較多(主要是因為我們使用的都是些小集群，這導致產生了大量遺留的冗余資源，閑置在系統中)
• 缺乏高可靠的保障
• 開發效率較低

實時流計算平臺發展

在步入實時流計算平臺的第三階段之后，我們提高了相應的宏觀目標，即：

• 提高公司的開發生產效率，節省重復建設的成本。
• 可視化各項操作。

上圖是當前實時流計算平臺的架構圖。數據流邏輯如下：

• 用戶通過 UI 交互客戶端、以及 Weiclient 等交互模塊，將作業提交給控制中心。
• 控制中心進行初步的權限校驗和資源審核之后，將資源提交給任務調度。
• 任務調度將相應的作業提交給對應的集群 Weibox。
• 如果作業提交成功，Weibox 會把相應的作業信息重新返回給控制中心。
• 控制中心將作業通過用戶交互客戶端返回給用戶結果。同時，它會將作業信息同步給管理服務后臺。
• 用戶通過管理服務后臺的客戶端，去操作自己在集群上面的功能。控制中心既能減少已占用的資源，又能為每一個團隊實現資源控制。

控制中心初現

由于前期各種作業(如 Storm)在向集群提交的時候，許多開發人員會自行配置一個本地環境，以實現直接提交，這就造成了平臺方很難對集群進行有效的管控。

因此對于我們第三階段的控制中心而言，其主要目標是：

• 解決作業隨意提交，治理集群上作業混亂的現象。
• 對集群資源進行統一管理，從而避免過多的資源浪費。

上圖是實時流計算平臺的控制中心架構圖。其流程如下：

• “基礎模塊”通過權限校驗和資源審核，將作業提交給“作業上線流程”服務。
• “作業上線流程”調用后置的檢查模塊，檢查該作業是否在集群上運行成功，以及判斷該作業所占用的資源、是否為它在提交時指定了資源量。
• 如果“作業上線流程”服務提交作業成功，那么“資源決策服務”調用動態資源調節模塊，在集群上定時(如：每小時或每天)檢查該作業所使用和處理的數據量，以及每條數據的處理時長。籍此，該模塊運用簡單的公式，來判斷該作業是否需要占這么多資源。

上述提到過，一些開發人員可能會通過在自己的本機上配置相應的作業提交環境，以實現將作業提交到集群之中。

那么為了管控對應的業務組在集群上占用的資源量，我們在“資源決策服務”里，調用到了作業識別模塊。

資源配置策略

為了提高公司的生產開發效率，我們在第三階段實施了資源配置策略。同時，我們的核心目標點是：通過第二階段的 WeiPig 開發框架，來鼓勵各個業務團隊貢獻相應的插件。

其實 WeiPig 是一套規范協議，大家在貢獻插件之前需要增加學習上的投入。因此，對于一些已經實施了計算能力的業務方來說，雖然有利于將舊平臺遷移過來，但是他們不太愿意投入此類學習的成本。

所以我們想出了用資源去換取 WeiPig 前向發展的方法。我們將所有的平臺資源按照基礎資源、彈性資源、獎勵資源和平臺資源，四個方向進行劃分。

其中基礎資源僅占 1%，基本上只有一、兩臺機器。彈性資源有 20%，各個公司根據業務量和業務等級進行劃分，當業務量多的時候，每一個業務都可以有自己的重要程度和優先級。

值得一提的是：獎勵資源為 30%。它通過兩方面標準：WeiPig 里貢獻的 Function 數量，和這些通用 Function 會被多少業務方所使用到，來進行公式算法上的衡量。

如果你貢獻的多，而且被其他業務方使用的也比較多，那么我們就會從所有平臺資源的 30% 中，給你劃分出更多的資源。

實時對賬系統

為了滿足某些高成功率場景的需求，我們在第三階段自行設計了一個實時對賬系統。

該系統的主要成績是：滿足實時計算平臺完成 6 個 9 的數據成功率需求。

上圖是實時對賬系統的一個簡單架構圖。在數據處理開始時，我們會將數據寫入實時對賬系統，并打上開始標志。

同時，實時對賬系統會將該數據的開始處理、和結束處理的標志，存放到存儲服務上。

而圖中下方的離線定時服務，會定時查詢實時對賬系統，并進行如下判斷：

• 如果一條數據既有入賬，又有根據處理結束值所求的出賬，則認為該條數據已處理完成，即對賬成功。
• 如果一條數據只有數據處理的開始，卻沒有處理結束的標志，則該條數據可能出現被丟掉的情況，我們需要重試。
• 如果一條數據只有數據處理結束，卻沒有數據處理成功的標志，則會發出相應的報警，我們需要查找相應的問題。

穩定性服務平臺

另外，在第三階段，我們將第二階段的“統一監控平臺”升級成了“穩定性服務平臺”。

其目標有如下三點：

• 通用監控指標的數據統一生成。前面在第二階段的監控統一平臺中，我們必須在界面上去配置要監控的指標項目，通過編寫相應的采集代碼，然后把腳本部署到服務器上，以方便監控的采集。

但是在第三階段的穩定性服務平臺上，一個作業被提交到集群上之后，穩定性服務平臺會對集群上處理的數據量、處理延遲、錯誤量等通用指標進行統一生成。

• 集群資源負載均衡的監控。其實 Storm 不像 Hadoop、Flink、Yum，它并沒有資源調度的管理系統。

因此，它在自己做管理資源時，會出現在一個集群中，某個服務器的 CPU 利用率已達 90%，而其他服務器的 CPU 利用率只占有 50%～60% 的情況。所以我們自行研發了對集群資源負載均衡的監控。

• 監控指標采集平臺，統一所有監控數據的采集。

這里展示的是實時流計算平臺穩定性服務的架構圖。左側的數據采集平臺包括：Storm 指標項目數據收集、Kafka 數據堆積量的數據收集、日志收集平臺、監控腳本運行平臺、和服務器硬件資源的收集。

這是一個比較簡易的、便捷的資源負載均衡的監控服務。完成統一采集之后，系統調用數據存儲服務，經由服務平臺的管理服務平臺、運維服務平臺、和第三方服務平臺，對外面開發人員提供相應的服務。

上圖是第三階段相應的成果。目前，我們的平臺每天能處理大約一千多億的數據量，TPS 大約有百萬每秒，作業個數則每天約有 150～200 個。

如今無論是多媒體相關的數字計算需求，還是微博相關的處理需求，我們的人工工作量已相對較少了，主要的工作量集中在編寫 WeiPig 相應的配置文件上。相應的代碼重復率也比較低，同樣主要集中在 WeiPig 文件上。

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

而對于監控方式而言，我們大部分采用的是自動生成的方式，所以只對一些特殊要求才進行監控配置。

當然，目前的實時流計算平臺仍有兩個遺留問題：

• 缺乏系統性的資源調度。我們需要有一個資源調度系統，來實時獲知集群上的作業到底應該運行在哪一臺服務器上。

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

• 日志收集方案不統一。

總結 DQRA 設計模式

我們在實時流計算開發的過程中，一邊搭建業務平臺，一邊解決了不少問題。因此我們總結出了一套 DQRA 的設計模式。

DQRA 詳解

它們分別是：

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

因此，我們認為：面對大多數的需求，我們可以把問題的實現拆解為上述四個屬性中的某種。

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

 

上述便是 DQRA 可能出現的不同組合，以及所對應的不同解決方法。

DQRA 案例分析

 

下面我們會介紹一個簡單案例，它包含如下特性：

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

具體來說，它是一個圖像分析與處理類系統，需要具有持續穩定的服務保證。因此，系統穩定是第一位的。

其次，它要求數據處理的成功率大于 6 個 9，從而能應對單日 5000 萬的數據量。

因此，我們通過上述三個方面來實現該系統的需求：

• 首先，針對系統的穩定性，我們采用的是內網和阿里云的“雙保險”網絡部署方式。
• 其次，由于涉及到圖片的下載，而我們在做分析時，調用的是在線模型預測方式。

因此，為了避免可能出現的圖片分析失敗，我們采用了實時對賬系統，實現了必要的重試處理。

[[244673]]

廖博，新浪微博實時流技術平臺負責人，曾就職于搜狐、雅虎研究院、支付寶等公司參與 Data Highway、大數據系統、數據倉庫、UUS(User Understanding Service)等第一代大數據生態系統的搭建工作;現就職于新浪微博，主導和開發實時流計算平臺，基于該平臺之上完成多媒體分析平臺、物料池系統、樣本生成平臺等多個子系統的開發和建設。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】