Spark streaming vs JStorm

大部分时候你们在选择技术方案的时候仍是比较迷茫，是该选择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了。，