實時計算在有讚的實踐 - 效率提高之路

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

相關連接

1. Druid在有讚的實踐
2. Flink 在有贊實時計算的實踐
3. 基於Storm的實時計算應用實踐