作者：賀飛
導讀：有贊是一個商家服務公司，提供全行業全場景的電商解決方案。在有贊，大量的業務場景依賴對實時資料的處理，作為一類基礎技術元件，服務著有贊內部幾十個業務產品，幾百個實時計算任務，其中包括交易資料大屏，商品實時統計分析，日誌平臺，呼叫鏈，風控等多個業務場景，本文將介紹有贊實時計算當前的發展歷程和當前的實時計算技術架構。
實時計算在有贊發展
從技術棧的角度，我們的選擇和大多數網際網路公司一致，從早期的 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 小結
這種架構在業務量少的情況下問題不大，但是隨著應用方任務數目的增加，暴露出一些運維上的問題，主要在以下幾個方面：
-
缺少業務管理機制。大資料團隊平臺組，作為叢集管理者，很難了解當前叢集上執行著的實時任務的業務歸屬關係，也就導致在叢集出現可用性問題或者叢集要做變更升級時，無法高效通知業務方做處理，溝通成本很高；
-
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，但是相差無幾對狀態的儲存支援[MOU1]， Flink 在這方面完勝，對於資料量較大的狀態資料，Flink 可以選擇直接儲存計算節點本地記憶體或是 RocksDB，充分利用物理資源；
-
對 SQL 的支援，對當時兩種框架的最新穩定版本的 SQL 功能做了調研，結果發現在對 SQL 的支援度上，Flink 也具有較大優勢，主要體現在支援更多的語法；
-
API 靈活性， Flink 的實時計算 API 會更加友好。
出於以上幾點原因，有贊開始在實時平臺中增加了對 Flink 引擎的支援。在完成 Flink 引擎的整合後，有贊實時計算的部署情況如下圖所示：
2.2.2 新的挑戰
以上完成之後，基本上就可以提供穩定 / 可靠的實時計算服務；隨之，業務方開發效率的問題開始顯得突出。使用者一般的接入流程包含以下幾個步驟：
-
熟悉具體實時計算框架的 SDK 使用，第一次需要半天左右；
-
申請實時任務上下游資源，如訊息佇列，Redis/MySQL/HBase 等線上資源，一般幾個小時；
-
實時任務開發，測試，視複雜程度，一般在 1~3 天左右；
-
對於複雜的實時開發任務，實時任務程式碼質量很難保證，平臺組很難為每個業務方做程式碼 review, 所以經常會有使用不當的應用在測試環境小流量測試正常後，釋出到線上，引起各種各樣的問題。
整個算下來，整個流程至少需要 2~3 天，實時應用接入效率逐漸成了眼前最棘手的問題。 對於這個問題。在做了很多調研工作後，最終確定了兩個實時計算的方向：
-
實時任務 SQL 化；
-
對於通用的實時資料分析場景，引入其他技術棧, 覆蓋簡單場景。
2.2.2.1 實時任務 SQL 化
實時任務 SQL 化可以大大簡化業務的開發成本，縮短實時任務的上線週期。 在有贊，實時任務 SQL 化 基於 Flink 引擎，目前正在構建中，我們目前的規劃是首先完成對以下功能的支援：
-
基於 Kafka流到流的實時SQL任務開發
-
基於 HBase Sink流到儲存的實時 SQL 任務開發
-
對 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]相對於對狀態儲存的支援