從Storm到Flink，有贊五年實時計算效率提高實踐

做者：賀飛

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

實時計算在有贊發展

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

2.1 起步階段

這裏的的起步階段的基本特徵是，缺乏總體的實時計算規劃，缺少平臺化任務管理，監控，報警工具，用戶提交任務直接經過登陸 AG 服務器使用命令行命令提交任務到線上集羣，很難知足用戶對可用性的要求。可是，在起步階段裏積累了內部大量的實時計算場景。

2.1.1 Storm 登場

2014 年初，第一個 Storm 應用在有贊內部開始使用，最初的場景是把實時事件的統計從業務邏輯中解耦出來，Storm 應用經過監聽 MySQL 的 binlog 更新事件作實時計算，而後將結果更新到 MySQL 或者 Redis 緩存上，供在線系統使用。相似的場景獲得了業務開發的承認，逐漸開始支撐起大量的業務場景。

早期，用戶經過登陸一組線上環境的 AG 服務器，經過 Storm 的客戶端向 Storm 集羣作提交任務等操做， 這樣兩年多的時間裏，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，可是相差無幾對狀態的存儲支持[MOU1]， Flink 在這方面完勝，對於數據量較大的狀態數據，Flink 能夠選擇直接存儲計算節點本地內存或是 RocksDB，充分利用物理資源；

3. 對 SQL 的支持，對當時兩種框架的最新穩定版本的 SQL 功能作了調研，結果發如今對 SQL 的支持度上，Flink 也具備較大優點，主要體如今支持更多的語法；

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

出於以上幾點緣由，有贊開始在實時平臺中增長了對 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流到流的實時SQL任務開發

2. 基於 HBase Sink流到存儲的實時 SQL 任務開發

3. 對 UDF 的支持

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

2.2.2.2 引入實時 OLAP引擎

經過對業務的觀察，咱們發如今業務的實時應用中，有大量的需求是統計在不一樣維度下的 uv，pv 類統計，模式相對固定，對於此類需求，咱們把目光放在了支持數據實時更新，而且支持實時的 OLAP類查詢上的存儲引擎上。

咱們主要調研了 Kudu，Druid 兩個技術棧，前者是 C++ 實現，分佈式列式存儲引擎，能夠高效的作 OLAP類查詢，支持明細數據查詢；後者是 Java 實現的事件類數據的預聚合 OLAP類查詢引擎~

綜合考慮了運維成本，與當前技術棧的融合，查詢性能，支持場景後，最終選擇了 Druid。

目前實時計算在有讚的總體技術架構以下圖：

將來規劃

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

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

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

總 結

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

做者介紹

賀飛，2017 年 7 月加入有贊大數據團隊 - 基礎平臺組，前後負責有贊 HBase 存儲的落地和數據基礎各個組件的平臺化工做。 有贊大數據團隊是有贊共享技術核心技術團隊之一，該團隊主要由算法，數據產品，數據倉庫和底層基礎平臺四個團隊構成，目前共有 50 位優秀的工程師組成。

---

[MOU1]相對於對狀態存儲的支持

更多資訊請訪問 Apache Flink 中文社區網站