微店實時計算平臺實踐

引言

隨著微店業務的蓬勃發展，目前很多核心系統都需要使用實時數據，歸納了下微店的實時業務形態，大致分為如下幾方面：

1.        實時在線系統，比如搜索、推薦和廣告

2.        監控預警，比如用戶行為預警、app crash預警、風控

3.        實時ETL，主要是進行數據清洗，歸并，結構化

4.        實時報表，比如交易大盤，微團購大盤

5.       消息異地同步，比如binlog消息轉換成業務消息

除了上述五種常見業務，還有例如像實時push消息以及短信通知等都可以通過實時計算平臺進行統一分發。

在支撐業務的過程中，發現一些具有共性的問題，具體表現如下：

1.        技術選型多種多樣，各個團隊獨自維護，導致實時開發門檻高，主要體現在開發者需要關注很多實時底層處理細節。

2.        效率低，主要體現在調試不方便，新發布中斷時間長等。

3.        穩定性不能保障，主要體現：沒有規范的開發流程，上線隨意等。

4.        缺少統一的監控運維配套，常常線上發現故障，很長時間之后才能發現。

5.        數據共享不透明，比如業務團隊需要使用推薦團隊的用戶特征，通過統一的平臺可以避免重復開發，數據信息共享等。

為了更好的支持上述各種實時業務以及解決上述問題，提供統一高效的實時計算開發平臺顯得很有必要。實時計算平臺代號comet，comet原意彗星，我們希望微店的實時處理能力能像彗星劃過天空一樣快速而精彩。

實時計算平臺的整體架 構

整體架構描述

comet 實時計算平臺整體架構如下圖所示：

任務開發流程

通過comet平臺重新定義了實時數據開發的整個流程，下圖主要展示通過sql開發實時數據的流程：

選擇 sql 開 發實時 任 務 的考量

微店開發實時數據大概經過三個階段，初始階段每個實時業務開發都是各自為戰，這個時期的實時業務處于萌芽階段，規模相對比較小。數據開發人員使用Storm原生API開發流式作業，開發門檻高，系統調試難，存在大量重復的人肉工作，舉個例子，這個時期處理H5的日志文件，每條業務線從消息隊列kafka接收到邏輯解析處理到最后存儲，都是各自開發一套邏輯，有時候不同業務消費group設置成同一個都未曾發覺。第二個階段我們把很多重復使用的組件進行抽象封裝，比如實現了簡單過濾、聚合、窗口等等作為基礎的編程組件，這個階段很多實時任務就是基于這些基礎編程組件進行組裝，一定程度上降低了使用門檻，但是開發人員還是需要了解整套編程組件，使用起來門檻依然比較高。第三個階段就是我們引入類sql語言來開發實時任務，sql語言經過幾十年的發展，接受度比較高，同時學習門檻很低，適合群體相對更加廣泛，數據分析師、算法等也很容易上手進行開發。下面舉個簡單的采用sql開發實時任務的例子，主要邏輯是從消息隊列接受日志數據，經過實時清洗到存儲到elasticsearch，供業務方報表展示。

（看不清，請點擊放大）

底 層選擇 Jstorm 的技 術 考量

之前微店采用的storm作為底層實時處理引擎，comet實時計算平臺基于以下考量采用了Jstorm作為底層實時處理引擎：

1.       兼容之前storm任務，無需二次開發

2.        穩定性更高：相比storm，nimbus實現了HA，徹底解決雪崩問題，資源分配更加合理，減少對ZK的訪問等

3.        調度更強大：資源調度深度優化等

4.        相比heron，jstorm任務的維度為線程，heron為進程，避免了消息的傳輸全部走網絡。根據jstorm官方文檔，heron無性能優勢

在開源基 礎 上做了哪些二次開 發

SQL 解析并未進行自主研發，采用的是華為開源的streamCql，streamCql底層采用的主流的語法解析工具antlr，一方面華為在這方面做得相對比較完善，另一方面之前在這一塊有一定的技術積累。綜合考慮在開源的基礎進行二次開發顯得比較適合。針對streamCql做了大量的二次開發以滿足目前微店的業務，列舉如下：

1.        增加了ack機制，目前streamCql并未實現ack機制

2.        輸入算子開發，目前支持kafka，vdianMq，rocketMq，覆蓋微店主流的數據輸入源。

3.        輸出算子開發，目前支持mysql，elasticSearch，vdianMq，kafka，rocketMq，redis等，覆蓋主流的輸出。

4.        DataSource 開發，支持mysql，搜索引擎，redis等，主要為了支持實時數據過濾，補全等功能。

5.        UDF 開發，參考Hive目前支持的大部分功能，開發了對應的UDF。

6.        新增支持復雜結構，比如map和array等，支持轉義字符等。

7.        針對目前streamCql生成的Jstorm任務效率不高，做了算子合并，序列化等優化。

Jstorm 相對比較成熟，主要是將調試日志、業務日志以及系統日志做了分離，并且存儲到elasticsearch里，供comet做調試，追蹤bug以及報警使用。同時為了保障線上各任務之間不互相影響，采用cgroup做資源隔離，目前正在測試中，還未正式上線。

踩過的坑

1.        streamCql 生成拓撲優化

通過sql生成的bolt層級太多，導致實時任務吞吐量比較低，同時延遲比較大，通過優化拓撲圖，讓出度和入度都為1的算子進行有策略的合并，減少網絡IO，減少數據shuffle。

2.        streamCql 支持復雜類型

在微店的業務場景里，很多數據格式是json類型的，一開始采用各種嵌套UDF表達json，導致sql可讀性極差且容易出錯，后面通過支持map和array相關復雜類型，徹底解決這類問題。

3.        輸出算子流控

app 端的日志通過實時處理，寫入到elasticsearch中供數據業務方使用，初期版本并未做流控設計，當日志從5000w增長到億級別的時候，出現bolt寫入變慢，出現日志大規模處理延遲。通過實現寫入elasticsearch流控控制，解決該問題，單條寫入轉變為批量寫入，但是一定程度上犧牲了實時性。

4.        Jstorm 相關問題

比如acker數量設置為0，這時候不發送任何消息，另外比如worker數量設置為大于10，這個時候topologyMaster從線程變為進程級別，需要額外一個worker進程處理。Jstorm使用過程中遇到過一些問題，后續會有專門的Jstorm使用經驗分享。

展望 & 后 續 工作

目前comet平臺并不支持trident和batch等特性，后續會整合到streamCql中，更好的支持微店的業務，同時目前comet平臺監控報警等還不完善，后續會逐步完善，力爭提供一體化的實時數據開發平臺。目前比較火熱的spark streaming，此外google提出的新一代的數據處理引擎dataflow以及推ter提出的heron等，這些會結合微店具體業務去做一些嘗試，畢竟在實時處理領域也并沒有銀彈。

 

 

來自：http://mp.weixin.qq.com/s/Y4LZoOP_ViAbuoodahlhSw