實時計算的技術難點

曾經天真的認爲只要把 Storm 安裝好以後，簡單學習一下 Storm 的編程概念就能夠把實時統計的工做完成了。畢竟實時統計無非就是加減乘除，並不牽涉到什麼高深的機器學習算法。而後在實踐中發現 Storm 根本沒有提供實時統計所必需的不少基礎設施和編程抽象，更不要說進行更復雜的通用實時計算了（好比關聯兩個事件流進行登錄時長統計之類的）。其實坑很是多：

一、如何實現按窗口統計。實時統計本質上就是micro batch，把 batch 計算的窗口從一天縮小到分鐘級別甚至秒級。因此實時計算的核心是窗口。而 Storm 的編程模型裏沒有窗口，如何在上層實現滾動窗口，滑動窗口，累積窗口，甚至是更復雜的基於業務邏輯的時間窗口模型。如何用遠小於數據量（5w/s級別）的內存（700多m）實現實時計算。

二、大數據量的處理，合併多partition的數據爲統一的彙總結果。統計不可是時間維度的聚合，還包括空間維度的。不一樣機器的數據，一級級彙總到最後的一行結果。如何處理單機沒法統計的數據量？傳統的作法是按業務維度分片，分片聚合。新興的作法是一些hyperloglog之類的機率統計數據結構來作到無需業務邏輯支撐的數據分片。

三、Storm的性能問題：來自於兩個方面。逐條處理的模型致使消息處理的overhead 在總消耗中佔比很是高，並且逐條處理很是不便於與外部系統作批量讀取和存儲。spout/bolt 同是承擔物理上的分佈模型又是編程的邏輯抽象，因爲不瞭解 spout/bolt 的真實開銷開發者很容易引入無謂的cpu消耗和網絡消耗。如何在Storm上構建高效率的執行框架同時又保持簡單的逐條處理模型？

四、高可用的實時計算：Storm內建的ack機制用在實時統計上就是一個笑話。不管是百度的實時計算平臺，仍是惟品會，拉卡拉的Storm集羣，沒有一家是把ack機制打開了的。爲何ack不適用於實時統計？如何基於 kafka low-level api實現基於消息重放的高可用機制？（特別是 Spark 1.3 的高可用設計和這個實現不謀而合）

五、Batch 計算和實時計算共享代碼，甚至直接用 Storm 進行數據補錄之類的 Batch 計算會引入哪些問題。特別是如何處理多 partition 數據處理同步問題？這個方向有不少公司都在嘗試，不過敢直接拿實時計算平臺算batch做業的，還真沒有據說過。

六、不少實時計算平臺都限於處理單流數據。如何在流式計算中實現多個數據流的 join？這種 join 的場景是計費。好比 Google 的廣告平臺 join 了 impression 流 和 click 流實現了對廣告上的計費。