實時計算在有讚的實踐——效率提升之路

1. 概述

有贊是一個商家服務公司，提供全行業全場景的電商解決方案。在有贊，大量的業務場景依賴對實時資料的處理，作為一類基礎技術元件，服務著有贊內部幾十個業務產品，幾百個實時計算任務，其中包括交易資料大屏，商品實時統計分析，日誌平臺，呼叫鏈，風控等多個業務場景，本文將介紹有贊實時計算當前的發展歷程和當前的實時計算技術架構。

2. 實時計算在有贊發展

從技術棧的角度，我們的選擇和大多數網際網路公司一致，從早期的Storm，到JStorm， Spark Streaming 和最近興起的Flink。從發展階段來說，主要經歷了兩個階段，起步階段和平臺化階段；下面將按照下圖中的時間線，介紹實時計算在有讚的發展歷程。

2.1 起步階段

這裡的的起步階段的基本特徵是，缺少整體的實時計算規劃，缺乏平臺化任務管理，監控，報警工具，使用者提交任務直接通過登入 AG 伺服器使用命令列命令提交任務到線上叢集，很難滿足使用者對可用性的要求。 但是，在起步階段裡積累了內部大量的實時計算場景。

2.1.1 Storm 登場

2014年初，第一個 Storm 應用在有贊內部開始使用，最初的場景是把實時事件的統計從業務邏輯中解耦出來，Storm 應用通過監聽 MySQL 的 binlog 更新事件做實時計算，然後將結果更新到 MySQL 或者 Redis 快取上，供線上系統使用。類似的場景得到了業務開發的認可，逐漸開始支撐起大量的業務場景，詳見2017年整理的一篇部落格文章-《基於 Storm 的實時應用實踐》。

早期，使用者通過登入一組線上環境的AG伺服器，通過Storm的客戶端向Storm叢集做提交任務等操作， 這樣在2年多的時間裡，Storm 元件積累了近百個實時應用。 Storm也同樣暴露出很多問題，主要體現在系統吞吐上，對吞吐量巨大，但是對延遲不敏感的場景，顯得力不從心。

2.1.2 引入Spark Streaming

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

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

2.1.3 小結

這種架構在業務量少的情況下問題不大，但是隨著應用方任務數目的增加，暴露出一些運維上的問題，主要在以下幾個方面：

1. 缺少業務管理機制。大資料團隊平臺組，作為叢集管理者，很難了解當前叢集上執行著的實時任務的業務歸屬關係，也就導致在叢集出現可用性問題或者叢集要做變更升級時，無法高效通知業務方做處理，溝通成本很高
2. Storm和Spark Streaming的監控報警，是各自實現的，處於工具化的階段，很多業務方，為了可用性，會定製自己的監控報警工具，導致很多重複造輪，影響開發效率
3. 計算資源沒有隔離。資源管理粗糙，沒有做離線系統和實時系統的隔離；早期離線任務和 Spark Streaming 任務執行在同一組 Yarn 資源上，凌晨離線任務高峰時，雖然 Yarn 層有做 CapacityScheduler 的 Queue 隔離，但是 HDFS 層公用物理機，難免網路卡和磁碟 IO 層面會相互影響，導致凌晨時間段實時任務會有大量延遲
4. 缺少靈活的資源排程。使用者通過 AG 伺服器啟動實時任務，任務所使用的叢集資源，也在啟動指令碼中指定。這種方式在系統可用性上存在很大弊端，當實時計算所在的 Yarn 資源池出現故障時，很難做實時任務的叢集間切換

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

2.2 平臺化階段

2.2.1 構建實時計算平臺

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

1. 業務管理功能。主要是記錄實時應用的相關資訊，並且和業務的介面人做好關聯
2. 提供任務級別的監控，任務故障自動拉起，使用者自定義基於延遲/吞吐等指標的報警，流量趨勢大盤等功能
3. 做好叢集規劃，為實時應用構建獨立的計算Yarn叢集，避免離線任務和實時任務互相影響
4. 提供任務零花的切換計算叢集，保證在叢集故障時可以方便遷移任務到其他叢集暫避

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

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

1. 延遲， Flink 勝出，Spark Streaming 本質上還是以為微批次計算框架，處理延遲一般跟 Batch Interval一致，一般在秒級別，在有讚的重吞吐場景下，一般 batch 的大小在 15 秒左右
2. 吞吐， 經過實際測試，相同條件下，Flink 的吞吐會略低於 Spark Streaming，但是相差無幾
3. 對狀態的儲存支援， Flink在這方面完勝，對於資料量較大的狀態資料，Flink 可以選擇直接儲存計算節點本地記憶體或是 RocksDB，充分利用物理資源
4. 對 SQL 的支援，對當時兩種框架的最新穩定版本的 SQL 功能做了調研，結果發現在對 SQL 的支援度上，Flink也具有較大優勢，主要體現在支援更多的語法
5. API靈活性， Flink 的實時計算 API會更加友好

出於以上幾點原因，有贊開始在實時平臺中增加了對 Flink 引擎的支援，選擇 Flink 的更具體的原因可以參考我們另一篇部落格文章-《Flink 在有贊實時計算的實踐》

在完成 Flink 引擎的整合後，有贊實時計算的部署情況如下圖所示：

2.2.2 新的挑戰

以上完成之後，基本上就可以提供穩定/可靠的實時計算服務；隨之，業務方開發效率的問題開始顯得突出。使用者一般的接入流程包含以下幾個步驟：

1. 熟悉具體實時計算框架的SDK使用，第一次需要半天左右
2. 申請實時任務上下游資源，如訊息佇列，Redis/MySQL/HBase 等線上資源，一般幾個小時
3. 實時任務開發，測試，視複雜程度，一般在1~3天左右
4. 對於複雜的實時開發任務，實時任務程式碼質量很難保證，平臺組很難為每個業務方做程式碼 review, 所以經常會有使用不當的應用在測試環境小流量測試正常後，釋出到線上，引起各種各樣的問題

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

1. 實時任務 SQL 化
2. 對於通用的實時資料分析場景，引入其他技術棧, 覆蓋簡單場景

2.2.2.1 實時任務SQL化

實時任務 SQL 化可以大大簡化業務的開發成本，縮短實時任務的上線週期。 在有贊，實時任務 SQL化 基於 Flink 引擎，目前正在構建中，我們目前的規劃是首先完成對以下功能的支援： 1. 基於 Kafka 流的流到流的實時任務開發
\\2. 基於 HBaseSink 的流到儲存的SQL任務開發
\\3. 對 UDF 的支援

目前SQL化實時任務的支援工作正在進行中。

2.2.2.2 引入實時OLAP引擎

通過對業務的觀察，我們發現在業務的實時應用中，有大量的需求是統計在不同維度下的 uv，pv 類統計，模式相對固定，對於此類需求，我們把目光放在了支援資料實時更新，並且支援實時的Olap類查詢上的儲存引擎上。

我們主要調研了 Kudu，Druid 兩個技術棧，前者是 C++ 實現，分散式列式儲存引擎，可以高效的做 Olap 類查詢，支援明細資料查詢；後者是 Java 實現的事件類資料的預聚合 Olap 類查詢引擎~

綜合考慮了運維成本，與當前技術棧的融合，查詢效能，支援場景後，最終選擇了 Druid，關於 Druid 在有讚的實踐，可以參考我們另一篇部落格文章-《Druid在有讚的實踐》。

目前實時計算在有讚的整體技術架構如下圖

3. 未來規劃

首先要落地並的是實時任務SQL化，提高SQL化任務可以覆蓋的業務場景（目標是70%），從而通過提高業務開發效率的角度賦能業務。

在SQL化實時任務初步完成後，流資料的複用變成了提高效率上 ROI 最高的措施，初步計劃會著手開始實時數倉的建設，對於實時數倉的初步設計如下圖：

當然，完整的實時數倉絕沒有這麼簡單，不只是實時計算相關的基礎設施要達到一定的平臺化水平，還依賴實時後設資料管理，實時資料質量管理等配套的元件建設，路漫漫其修遠~

4. 總結

有贊實時計算在業務方的需求下推動前進，在不同的階段下，技術方向始終朝著當前投入產出比最高的方向在不斷調整。本文並沒有深入技術細節，而是循著時間線描述了實時計算在有讚的發展歷程，有些地方因為作者認知有限，難免紕漏，歡迎各位同行指出。

最後打個小廣告，有贊大資料團隊基礎設施團隊，主要負責有讚的資料平臺（DP), 實時計算(Storm, Spark Streaming, Flink)，離線計算(HDFS,YARN,HIVE, SPARK SQL)，線上儲存（HBase），實時 OLAP(Druid) 等數個技術產品，歡迎感興趣的小夥伴聯絡 hefei@youzan.com