大部分時候大家在選擇技術方案的時候還是比較迷茫，是該選擇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了。，

本文轉自里沖51CTO博客，原文鏈接：http://blog.51cto.com/coollast/1901331 ，如需轉載請自行聯系原作者

總結

以上是生活随笔為你收集整理的Spark streaming vs JStorm的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。