作者：賀飛

導(dǎo)讀：有贊是一個商家服務(wù)公司，提供全行業(yè)全場景的電商解決方案。在有贊，大量的業(yè)務(wù)場景依賴對實時數(shù)據(jù)的處理，作為一類基礎(chǔ)技術(shù)組件，服務(wù)著有贊內(nèi)部幾十個業(yè)務(wù)產(chǎn)品，幾百個實時計算任務(wù)，其中包括交易數(shù)據(jù)大屏，商品實時統(tǒng)計分析，日志平臺，調(diào)用鏈，風(fēng)控等多個業(yè)務(wù)場景，本文將介紹有贊實時計算當(dāng)前的發(fā)展歷程和當(dāng)前的實時計算技術(shù)架構(gòu)。

實時計算在有贊發(fā)展

從技術(shù)棧的角度，我們的選擇和大多數(shù)互聯(lián)網(wǎng)公司一致，從早期的 Storm，到 JStorm， Spark Streaming 和最近興起的 Flink。從發(fā)展階段來說，主要經(jīng)歷了兩個階段，起步階段和平臺化階段；下面將按照下圖中的時間線，介紹實時計算在有贊的發(fā)展歷程。

2.1 起步階段

這里的的起步階段的基本特征是，缺少整體的實時計算規(guī)劃，缺乏平臺化任務(wù)管理，監(jiān)控，報警工具，用戶提交任務(wù)直接通過登錄 AG 服務(wù)器使用命令行命令提交任務(wù)到線上集群，很難滿足用戶對可用性的要求。但是，在起步階段里積累了內(nèi)部大量的實時計算場景。

2.1.1 Storm 登場

2014 年初，第一個 Storm 應(yīng)用在有贊內(nèi)部開始使用，最初的場景是把實時事件的統(tǒng)計從業(yè)務(wù)邏輯中解耦出來，Storm 應(yīng)用通過監(jiān)聽 MySQL 的 binlog 更新事件做實時計算，然后將結(jié)果更新到 MySQL 或者 Redis 緩存上，供在線系統(tǒng)使用。類似的場景得到了業(yè)務(wù)開發(fā)的認(rèn)可，逐漸開始支撐起大量的業(yè)務(wù)場景。

早期，用戶通過登錄一組線上環(huán)境的 AG 服務(wù)器，通過 Storm 的客戶端向 Storm 集群做提交任務(wù)等操作， 這樣兩年多的時間里，Storm 組件積累了近百個實時應(yīng)用。 Storm 也同樣暴露出很多問題，主要體現(xiàn)在系統(tǒng)吞吐上：對吞吐量巨大但是對延遲不敏感的場景，顯得力不從心。

2.1.2 引入 Spark Streaming

2016 年末，隨著 Spark 技術(shù)棧的日益成熟，又因為 Storm 引擎本身在吞吐 / 性能上跟 Spark Streaming 技術(shù)棧相比有明顯劣勢，所以從那時候開始，部分業(yè)務(wù)團隊開始嘗試新的流式計算引擎。 因為有贊離線計算有大量 Spark 任務(wù)的使用經(jīng)驗，Spark Streaming 很自然的成為了第一選擇，隨著前期業(yè)務(wù)日志系統(tǒng)和埋點日志系統(tǒng)的實時應(yīng)用的接入，大量業(yè)務(wù)方也開始逐漸接入。同Storm一樣，業(yè)務(wù)方完成實時計算應(yīng)任務(wù)開發(fā)后，通過一組 AG 服務(wù)器，使用 Spark 客戶端，向大數(shù)據(jù) Yarn 集群提交任務(wù)。

初步階段持續(xù)的時間比較長，差不多在 2017 年年末，有贊實時計算的部署情況如下圖所示：

2.1.3 小結(jié)

這種架構(gòu)在業(yè)務(wù)量少的情況下問題不大，但是隨著應(yīng)用方任務(wù)數(shù)目的增加，暴露出一些運維上的問題，主要在以下幾個方面：

缺少業(yè)務(wù)管理機制。大數(shù)據(jù)團隊平臺組，作為集群管理者，很難了解當(dāng)前集群上運行著的實時任務(wù)的業(yè)務(wù)歸屬關(guān)系，也就導(dǎo)致在集群出現(xiàn)可用性問題或者集群要做變更升級時，無法高效通知業(yè)務(wù)方做處理，溝通成本很高；

Storm 和 Spark Streaming 的監(jiān)控報警，是各自實現(xiàn)的，處于工具化的階段，很多業(yè)務(wù)方，為了可用性，會定制自己的監(jiān)控報警工具，導(dǎo)致很多重復(fù)造輪，影響開發(fā)效率；

計算資源沒有隔離。資源管理粗糙，沒有做離線系統(tǒng)和實時系統(tǒng)的隔離；早期離線任務(wù)和 Spark Streaming 任務(wù)運行在同一組 Yarn 資源上，凌晨離線任務(wù)高峰時，雖然 Yarn 層有做 CapacityScheduler 的 Queue 隔離，但是 HDFS 層公用物理機，難免網(wǎng)卡和磁盤 IO 層面會相互影響，導(dǎo)致凌晨時間段實時任務(wù)會有大量延遲；

缺少靈活的資源調(diào)度。用戶通過 AG 服務(wù)器啟動實時任務(wù)，任務(wù)所使用的集群資源，也在啟動腳本中指定。這種方式在系統(tǒng)可用性上存在很大弊端，當(dāng)實時計算所在的 Yarn 資源池出現(xiàn)故障時，很難做實時任務(wù)的集群間切換。

總的來說就是缺少一個統(tǒng)一的實時計算平臺，來管理實時計算的方方面面。

2.2 平臺化階段

2.2.1 構(gòu)建實時計算平臺

接上一節(jié)，面對上面提到的這四個問題，對實時計算平臺的初步需求如下：

業(yè)務(wù)管理功能。主要是記錄實時應(yīng)用的相關(guān)信息，并且和業(yè)務(wù)的接口人做好關(guān)聯(lián)；

提供任務(wù)級別的監(jiān)控，任務(wù)故障自動拉起，用戶自定義基于延遲 / 吞吐等指標(biāo)的報警，流量趨勢大盤等功能；

做好集群規(guī)劃，為實時應(yīng)用構(gòu)建獨立的計算 Yarn 集群，避免離線任務(wù)和實時任務(wù)互相影響；

提供任務(wù)靈活的切換計算集群，保證在集群故障時可以方便遷移任務(wù)到其他集群暫避。

所以在 18 年初，我們立項開始做實時平臺第一期，作為嘗試起初我們僅僅完成對 Spark Streaming 實時計算任務(wù)的支持， 并在較短時間內(nèi)完成了所有 Spark Streaming 任務(wù)的遷移。 試運行 2 個月后，明顯感覺到對業(yè)務(wù)的掌控力變強。隨后便開始了對 Storm 任務(wù)的支持，并遷移了所有的 Storm 實時計算任務(wù). AG 服務(wù)器全部下線，業(yè)務(wù)方再也不需要登錄服務(wù)器做任務(wù)提交。

2018 年中，有贊線上運行著 Storm，Spark Streaming 兩種計算引擎的實時任務(wù)，可以滿足大部分業(yè)務(wù)需求，但是，兩種引擎本身也各自存在著問題。 Storm 本身存在著吞吐能力的限制。和 Spark Streaming 對比，選擇似乎更難一些。我們主要從以下幾個角度考慮：

延遲， Flink 勝出，Spark Streaming 本質(zhì)上還是以為微批次計算框架，處理延遲一般跟 Batch Interval 一致，一般在秒級別，在有贊的重吞吐場景下，一般 batch 的大小在 15 秒左右；

吞吐， 經(jīng)過實際測試，相同條件下，Flink 的吞吐會略低于 Spark Streaming，但是相差無幾對狀態(tài)的存儲支持[MOU1]， Flink 在這方面完勝，對于數(shù)據(jù)量較大的狀態(tài)數(shù)據(jù)，Flink 可以選擇直接存儲計算節(jié)點本地內(nèi)存或是 RocksDB，充分利用物理資源；

對 SQL 的支持，對當(dāng)時兩種框架的最新穩(wěn)定版本的 SQL 功能做了調(diào)研，結(jié)果發(fā)現(xiàn)在對 SQL 的支持度上，Flink 也具有較大優(yōu)勢，主要體現(xiàn)在支持更多的語法；

API 靈活性， Flink 的實時計算 API 會更加友好。

出于以上幾點原因，有贊開始在實時平臺中增加了對 Flink 引擎的支持。在完成 Flink 引擎的集成后，有贊實時計算的部署情況如下圖所示：

2.2.2 新的挑戰(zhàn)

以上完成之后，基本上就可以提供穩(wěn)定 / 可靠的實時計算服務(wù)；隨之，業(yè)務(wù)方開發(fā)效率的問題開始顯得突出。用戶一般的接入流程包含以下幾個步驟：

熟悉具體實時計算框架的 SDK 使用，第一次需要半天左右；

申請實時任務(wù)上下游資源，如消息隊列，Redis/MySQL/HBase 等在線資源，一般幾個小時；

實時任務(wù)開發(fā)，測試，視復(fù)雜程度，一般在 1~3 天左右；

對于復(fù)雜的實時開發(fā)任務(wù)，實時任務(wù)代碼質(zhì)量很難保證，平臺組很難為每個業(yè)務(wù)方做代碼 review, 所以經(jīng)常會有使用不當(dāng)?shù)膽?yīng)用在測試環(huán)境小流量測試正常后，發(fā)布到線上，引起各種各樣的問題。

整個算下來，整個流程至少需要 2~3 天，實時應(yīng)用接入效率逐漸成了眼前最棘手的問題。 對于這個問題。在做了很多調(diào)研工作后，最終確定了兩個實時計算的方向：

實時任務(wù) SQL 化；

對于通用的實時數(shù)據(jù)分析場景，引入其他技術(shù)棧, 覆蓋簡單場景。

2.2.2.1 實時任務(wù) SQL 化

實時任務(wù) SQL 化可以大大簡化業(yè)務(wù)的開發(fā)成本，縮短實時任務(wù)的上線周期。 在有贊，實時任務(wù) SQL 化 基于 Flink 引擎，目前正在構(gòu)建中，我們目前的規(guī)劃是首先完成對以下功能的支持：

基于 Kafka流到流的實時SQL任務(wù)開發(fā)

基于 HBase Sink流到存儲的實時 SQL 任務(wù)開發(fā)

對 UDF 的支持

目前 SQL 化實時任務(wù)的支持工作正在進(jìn)行中。

2.2.2.2 引入實時 OLAP引擎

通過對業(yè)務(wù)的觀察，我們發(fā)現(xiàn)在業(yè)務(wù)的實時應(yīng)用中，有大量的需求是統(tǒng)計在不同維度下的 uv，pv 類統(tǒng)計，模式相對固定，對于此類需求，我們把目光放在了支持?jǐn)?shù)據(jù)實時更新，并且支持實時的 OLAP類查詢上的存儲引擎上。

我們主要調(diào)研了 Kudu，Druid 兩個技術(shù)棧，前者是 C++ 實現(xiàn)，分布式列式存儲引擎，可以高效的做 OLAP類查詢，支持明細(xì)數(shù)據(jù)查詢；后者是 Java 實現(xiàn)的事件類數(shù)據(jù)的預(yù)聚合 OLAP類查詢引擎~

綜合考慮了運維成本，與當(dāng)前技術(shù)棧的融合，查詢性能，支持場景后，最終選擇了 Druid。

目前實時計算在有贊的整體技術(shù)架構(gòu)如下圖：

未來規(guī)劃

首先要落地并的是實時任務(wù) SQL 化，提高 SQL 化任務(wù)可以覆蓋的業(yè)務(wù)場景（目標(biāo)是 70%），從而通過提高業(yè)務(wù)開發(fā)效率的角度賦能業(yè)務(wù)。

在 SQL 化實時任務(wù)初步完成后，流數(shù)據(jù)的復(fù)用變成了提高效率上 ROI 最高的措施，初步計劃會著手開始實時數(shù)倉的建設(shè)，對于實時數(shù)倉的初步設(shè)計如下圖：

當(dāng)然，完整的實時數(shù)倉絕沒有這么簡單，不只是實時計算相關(guān)的基礎(chǔ)設(shè)施要達(dá)到一定的平臺化水平，還依賴實時元數(shù)據(jù)管理，實時數(shù)據(jù)質(zhì)量管理等配套的組件建設(shè)，路漫漫其修遠(yuǎn)~

總 結(jié)

有贊實時計算在業(yè)務(wù)方的需求下推動前進(jìn)，在不同的階段下，技術(shù)方向始終朝著當(dāng)前投入產(chǎn)出比最高的方向在不斷調(diào)整。本文并沒有深入技術(shù)細(xì)節(jié)，而是循著時間線描述了實時計算在有贊的發(fā)展歷程，有些地方因為作者認(rèn)知有限，難免紕漏，歡迎各位同行指出。

作者介紹

賀飛，2017 年 7 月加入有贊大數(shù)據(jù)團隊 - 基礎(chǔ)平臺組，先后負(fù)責(zé)有贊 HBase 存儲的落地和數(shù)據(jù)基礎(chǔ)各個組件的平臺化工作。 有贊大數(shù)據(jù)團隊是有贊共享技術(shù)核心技術(shù)團隊之一，該團隊主要由算法，數(shù)據(jù)產(chǎn)品，數(shù)據(jù)倉庫和底層基礎(chǔ)平臺四個團隊構(gòu)成，目前共有 50 位優(yōu)秀的工程師組成。

---

[MOU1]相對于對狀態(tài)存儲的支持

更多資訊請訪問 Apache Flink 中文社區(qū)網(wǎng)站

總結(jié)

以上是生活随笔為你收集整理的从Storm到Flink，有赞五年实时计算效率提升实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。