你了解實 時計算嗎？

實時計算是什麼？

請看下面的圖：

我們以熱賣產品的統計為例，看下傳統的計算手段：

將用戶行為、log等信息清洗後保存在資料庫中.

將訂單信息保存在資料庫中.

利用觸發器或者協程等方式建立本地索引，或者遠程的獨立索引.

join訂單信息、訂單明細、用戶信息、商品信息等等表，聚合統計20分鐘內熱賣產品，並返回top-10.

web或app展示.

這是一個假想的場景，但假設你具有處理類似場景的經驗，應該會體會到這樣一些問題和難處：

水平擴展問題（scale-out）

顯然，如果是一個具有一定規模的電子商務網站，數據量都是很大的。而交易信息因為涉及事務，所以很難直接捨棄關係型資料庫的事務能力，遷移到具有更好的scale-out能力的NoSQL資料庫中。那麼，一般都會做sharding。歷史數據還好說，我們可以按日期來歸檔，並可以通過批處理式的離線計算，將結果緩存起來。

但是，這裡的要求是20分鐘內，這很難。

性能問題

這個問題，和scale-out是一致的，假設我們做了sharding，因為表分散在各個節點中，所以我們需要多次入庫，並在業務層做聚合計算。問題是，20分鐘的時間要求，我們需要入庫多少次呢？

10分鐘呢？

5分鐘呢？

實時呢？

而且，業務層也同樣面臨著單點計算能力的局限，需要水平擴展，那麼還需要考慮一致性的問題。

所以，到這裡一切都顯得很複雜。

業務擴展問題

假設我們不僅僅要處理熱賣商品的統計，還要統計廣告點擊、或者迅速根據用戶的訪問行為判斷用戶特徵以調整其所見的信息，更加符合用戶的潛在需求等，那麼業務層將會更加複雜。

也許你有更好的辦法，但實際上，我們需要的是一種新的認知：

這個世界發生的事，是實時的。

所以我們需要一種實時計算的模型，而不是批處理模型。

我們需要的這種模型，必須能夠處理很大的數據，所以要有很好的scale-out能力，最好是，我們都不需要考慮太多一致性、複製的問題。

那麼，這種計算模型就是實時計算模型，也可以認為是流式計算模型。

現在假設我們有了這樣的模型，我們就可以愉快地設計新的業務場景：

轉發最多的微博是什麼？

最熱賣的商品有哪些？

大家都在搜索的熱點是什麼？

我們哪個廣告，在哪個位置，被點擊最多？

或者說，我們可以問：

這個世界，在發生什麼？

最熱的微博話題是什麼？

我們以一個簡單的滑動窗口計數的問題，來揭開所謂實時計算的神秘面紗。

假設，我們的業務要求是：

統計20分鐘內最熱的10個微博話題。

解決這個問題，我們需要考慮：

數據源

這裡，假設我們的數據，來自微博長連接推送的話題。

問題建模

我們認為的話題是

#

號擴起來的話題，最熱的話題是此話題出現的次數比其它話題都要多。

比如：@foreach_break : 你好,#世界#,我愛你，#微博#。

「世界」和「微博」就是話題。

計算引擎

我們採用storm。

定義時間

如何定義時間？

時間的定義是一件很難的事情，取決於所需的精度是多少。

根據實際，我們一般採用tick來表示時刻這一概念。

在storm的基礎設施中，executor啟動階段，採用了定時器來觸發「過了一段時間」這個事件。

如下所示：

之前的博文中，已經詳細分析了這些基礎設施的關係，不理解的童鞋可以翻看前面的文章。

每隔一段時間，就會觸發這樣一個事件，當流的下游的bolt收到一個這樣的事件時，就可以選擇是增量計數還是將結果聚合并發送到流中。

bolt如何判斷收到的tuple表示的是「tick」呢？

負責管理bolt的executor線程，從其訂閱的消息隊列消費消息時，會調用到bolt的execute方法，那麼，可以在execute中這樣判斷：

結合上面的setup-tick!的clojure代碼，我們可以知道SYSTEM_TICK_STREAM_ID在定時事件的回調中就以構造函數的參數傳遞給了tuple，那麼SYSTEM_COMPONENT_ID是如何來的呢？

可以看到，下面的代碼中，SYSTEM_TASK_ID同樣傳給了tuple：

然後利用下面的代碼，就可以得到SYSTEM_COMPONENT_ID：

滑動窗口

有了上面的基礎設施，我們還需要一些手段來完成「工程化」，將設想變為現實。

這裡，我們看看Michael G. Noll的滑動窗口設計。

註：圖片來自網頁鏈接

Topology

上面的topology設計如下：

註：圖片來自網頁鏈接

將聚合計算與時間結合起來

前文，我們敘述了tick事件，回調中會觸發bolt的execute方法，那可以這麼做：

RollingCountBolt:

上面的代碼可能有點抽象，看下這個圖就明白了，tick一到，窗口就滾動：

註：圖片來自網頁鏈接

IntermediateRankingsBolt & TotalRankingsBolt：

其中，IntermediateRankingsBolt和TotalRankingsBolt的聚合排序方法略有不同：

IntermediateRankingsBolt的聚合排序方法：

TotalRankingsBolt的聚合排序方法：

而重排序方法比較簡單粗暴，因為只求前N個，N不會很大：

結語

下圖可能就是我們想要的結果，我們完成了t0 – t1時刻之間的熱點話題統計，其中的foreach_break僅僅是為了防盜版 : ].

文中對滑動窗口計數的概念和關鍵代碼做了較為詳細解釋，如果還有不理解，請參考網頁鏈接的設計以及storm的源碼.

希望你了解了什麼是實時計算 ：]

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！