應用案例 | 從Storm到Flink，有贊五年實時計算效率提升實踐

作者 | 賀飛

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

1.實時計算在有贊發展

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

cdn.xitu.io/2019/7/4/16bbcbc639be0c43?w=800&h=427&f=png&s=70205">

1.1 起步階段

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

1.1.1 Storm 登場

2014 年初，第一個 Storm 應用在有贊內部開始使用，最初的場景是把實時事件的統計從業務邏輯中解耦出來，Storm 應用通過監聽 MySQL 的 binlog 更新事件做實時計算，然后將結果更新到 MySQL 或者 Redis 緩存上，供在線系統使用。類似的場景得到了業務開發的認可，逐漸開始支撐起大量的業務場景。
早期，用戶通過登錄一組線上環境的 AG 服務器，通過 Storm 的客戶端向 Storm 集群做提交任務等操作， 這樣在 2 年多的時間里，Storm 組件積累了近百個實時應用。Storm 也同樣暴露出很多問題，主要體現在系統吞吐上，對吞吐量巨大，但是對延遲不敏感的場景，顯得力不從心。

1.1.2 引入 Spark Streaming

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

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

1.1.3 小結

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

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

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

1.2 平臺化階段

1.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 引擎的集成后，有贊實時計算的部署情況如下圖所示：

1.2.2 新的挑戰

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

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

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

• 實時任務 SQL 化；
• 對于通用的實時數據分析場景，引入其他技術棧, 覆蓋簡單場景。

1.2.2.1 實時任務 SQL 化

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

• 基于 Kafka 流的流到流的實時任務開發
• 基于 HBaseSink 的流到存儲的 SQL 任務開發
• 對 UDF 的支持

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

1.2.2.2 引入實時 OLAP 引擎

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

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

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

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

2.未來規劃

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

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

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

3.總結

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

4.作者介紹

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