大部分時候大家在選擇技術方案的時候還是比較迷茫，是該選擇JStorm還是Spark Streaming？

一般會流於一些並不重要問題的討論，最後做出目光非常短淺的選擇，幾個月之後再改變技術方案。造成嚴重的開發量的浪費，甚至拖延關鍵產品的上線，或者上線後問題層出不窮，不斷和業務方妥協談判。所以，明確這兩個最主流的流計算框架的應用場景至關重要，下面我說下經驗之談，避免更多的人走彎路。

Spark Streaming和JStorm的本質區別是想要解決的問題不同：

Spark Streaming是批量處理的Spark向流計算多邁了一步；

JStorm是真正的流式流水線計算向批量計算（trident可以有部分的批量處理）多邁出了一步。

使得看似毫不相關的兩個問題有了交集。這個交集讓很多人困惑。其實根本的問題是真正理解流計算本質的專案負責人少之又少。流計算不是實時計算。實時計算和離線計算對應，是計算的場景，是需求。流計算和批量計算對應是計算的方式。流計算的本質是：無狀態性！批量計算的本質是有狀態計算，或者說沒有狀態性的批量計算根本就是流計算，只是把時間維度的計算變成了空間維度的計算。而有狀態的流計算本質也是批量計算，只是把狀態的需求藏在流式之外的閉包中。這麼看了，一切瞭然，根本沒什麼交集，判斷自己的專案使用哪種技術方案根本不需要問詢需求方：你要多少的延遲？如果你只是需要低延遲，那你只是在挑戰現在計算機的計算能力。真正你要關心的是業務計算的邏輯是不是主要是無狀態的。

下面舉一個使用流計算的主要場景：

使用者行為log的基本sum，count，distinct需求： 這裡的log資料量巨大，如果技術方案不對，將對公司資源造成極大浪費。這個需求中，sum，count都是無狀態的計算，但是distinct確是有狀態的計算，所以最好的解決方案是sum，count在JStorm中計算，distinct在Spark中計算。但是兩個系統同時存在會帶來很多問題，資料落地拉起的延遲，這在阿里還是很大的瓶頸。但如果不考慮資料落地拉起，那麼Storm接Spark是最好的技術方案之一。

其實還有很多專案都存在大量的狀態儲存的需求，都是需要使用Spark Streaming來計算的。其實就算使用Spark和Storm的混合架構，資料兩次進記憶體（程式間資料流）也是對網路頻寬的浪費，所以如果在不考慮很高的實時要求的情況下，對於有狀態運算的專案完全可以用Spark Streaming取代掉Storm。對於沒有狀態的專案，當然可以完全用JStorm了。，