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 小結
這種架構在業務量少的情況下問題不大，但是隨着應用方任務數目的增加，暴露出一些運維上的問題，主要在以下幾個方面：
- 缺少業務管理機制。大數據團隊平臺組，作爲集羣管理者，很難了解當前集羣上運行着的實時任務的業務歸屬關係，也就導致在集羣出現可用性問題或者集羣要做變更升級時，無法高效通知業務方做處理，溝通成本很高
- Storm和Spark Streaming的監控報警，是各自實現的，處於工具化的階段，很多業務方，爲了可用性，會定製自己的監控報警工具，導致很多重複造輪，影響開發效率
- 計算資源沒有隔離。資源管理粗糙，沒有做離線系統和實時系統的隔離；早期離線任務和 Spark Streaming 任務運行在同一組 Yarn 資源上，凌晨離線任務高峯時，雖然 Yarn 層有做 CapacityScheduler 的 Queue 隔離，但是 HDFS 層公用物理機，難免網卡和磁盤 IO 層面會相互影響，導致凌晨時間段實時任務會有大量延遲
- 缺少靈活的資源調度。用戶通過 AG 服務器啓動實時任務，任務所使用的集羣資源，也在啓動腳本中指定。這種方式在系統可用性上存在很大弊端，當實時計算所在的 Yarn 資源池出現故障時，很難做實時任務的集羣間切換
總的來說就是缺少一個統一的實時計算平臺，來管理實時計算的方方面面。
2.2 平臺化階段
2.2.1 構建實時計算平臺
接上一節，面對上面提到的這四個問題，對實時計算平臺的初步需求如下：
- 業務管理功能。主要是記錄實時應用的相關信息，並且和業務的接口人做好關聯
- 提供任務級別的監控，任務故障自動拉起，用戶自定義基於延遲/吞吐等指標的報警，流量趨勢大盤等功能
- 做好集羣規劃，爲實時應用構建獨立的計算Yarn集羣，避免離線任務和實時任務互相影響
- 提供任務零花的切換計算集羣，保證在集羣故障時可以方便遷移任務到其他集羣暫避
所以在18年初，我們立項開始做實時平臺第一期，作爲嘗試起初我們僅僅完成對 Spark Streaming 實時計算任務的支持， 並在較短時間內完成了所有 Spark Streaming 任務的遷移。 試運行2個月後，明顯感覺到對業務的掌控力變強。隨後便開始了對 Storm 任務的支持，並遷移了所有的 Storm 實時計算任務. AG 服務器全部下線，業務方再也不需要登錄服務器做任務提交。
2018 年中，有贊線上運行着 Storm，Spark Streaming 兩種計算引擎的實時任務，可以滿足大部分業務需求，但是，兩種引擎本身也各自存在着問題。 Storm本身存在着吞吐能力的限制。和 Spark Streaming 對比，選擇似乎更難一些。我們主要從以下幾個角度考慮：
- 延遲， Flink 勝出，Spark Streaming 本質上還是以爲微批次計算框架，處理延遲一般跟 Batch Interval一致，一般在秒級別，在有讚的重吞吐場景下，一般 batch 的大小在 15 秒左右
- 吞吐， 經過實際測試，相同條件下，Flink 的吞吐會略低於 Spark Streaming，但是相差無幾
- 對狀態的存儲支持， Flink在這方面完勝，對於數據量較大的狀態數據，Flink 可以選擇直接存儲計算節點本地內存或是 RocksDB，充分利用物理資源
- 對 SQL 的支持，對當時兩種框架的最新穩定版本的 SQL 功能做了調研，結果發現在對 SQL 的支持度上，Flink也具有較大優勢，主要體現在支持更多的語法
- API靈活性， Flink 的實時計算 API會更加友好
出於以上幾點原因，有贊開始在實時平臺中增加了對 Flink 引擎的支持，選擇 Flink 的更具體的原因可以參考我們另一篇博客文章-《Flink 在有贊實時計算的實踐》
在完成 Flink 引擎的集成後，有贊實時計算的部署情況如下圖所示：
2.2.2 新的挑戰
以上完成之後，基本上就可以提供穩定/可靠的實時計算服務；隨之，業務方開發效率的問題開始顯得突出。用戶一般的接入流程包含以下幾個步驟：
- 熟悉具體實時計算框架的SDK使用，第一次需要半天左右
- 申請實時任務上下游資源，如消息隊列，Redis/MySQL/HBase 等在線資源，一般幾個小時
- 實時任務開發，測試，視複雜程度，一般在1~3天左右
- 對於複雜的實時開發任務，實時任務代碼質量很難保證，平臺組很難爲每個業務方做代碼 review, 所以經常會有使用不當的應用在測試環境小流量測試正常後，發佈到線上，引起各種各樣的問題
整個算下來，整個流程至少需要2~3天，實時應用接入效率逐漸成了眼前最棘手的問題。 對於這個問題。在做了很多調研工作後，最終確定了兩個實時計算的方向：
- 實時任務 SQL 化
- 對於通用的實時數據分析場景，引入其他技術棧, 覆蓋簡單場景
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) 等數個技術產品，歡迎感興趣的小夥伴聯繫 [email protected]