Spark streaming vs JStorm

最近在调研如何把阿里内部的流数据源接入Spark Streaming。也对接了几个使用JStorm的用户。目前看来大部分时候大家在选择技术方案的时候还是比较迷茫，是该选择JStorm还是Spark Streaming，一般会流于一些并不重要问题的讨论，最后做出目光非常短浅的选择，几个月之后再改变技术方案。造成严重的开发量的浪费，甚至拖延关键产品的上线，或者上线后问题层出不穷，不断和业务方妥协谈判。所以，明确这两个最主流的流计算框架的应用场景至关重要，下面我说下自己的经验之谈，避免更多的人走弯路。
Spark Streaming和JStorm的本质区别是想要解决的问题不同：Spark Streaming是批量处理的Spark向流计算多迈了一步，JStorm是真正的流式流水线计算向批量计算（trident可以有部分的批量处理）多迈出了一步。使得看似毫不相关的两个问题有了交集。这个交集让很多人困惑。其实根本的问题是真正理解流计算本质的项目负责人少之又少。流计算不是实时计算。实时计算和离线计算对应，是计算的场景，是需求。流计算和批量计算对应是计算的方式。流计算的本质是：无状态性！批量计算的本质是有状态计算，或者说没有状态性的批量计算根本就是流计算，只是把时间维度的计算变成了空间维度的计算。而有状态的流计算本质也是批量计算，只是把状态的需求藏在流式之外的闭包中。这么看了，一切了然，根本没什么交集，判断自己的项目使用哪种技术方案根本不需要问询需求方：你要多少的延迟？如果你只是需要低延迟，那你只是在挑战现在计算机的计算能力。真正你要关心的是业务计算的逻辑是不是主要是无状态的。
下面举一个使用流计算的主要场景，因为我主要在阿里负责对接不同项目使用Spark的技术方案。所以主要是阿里的不同项目如何应用流计算框架。
用户行为log的基本sum，count，distinct需求。这里的log数据量巨大，如果技术方案不对，将对公司资源造成极大浪费。这个需求中，sum，count都是无状态的计算，但是distinct确实有状态的计算，所以最好的解决方案是sum，count在JStorm中计算，distinct在Spark中计算。但是两个系统同时存在会带来很多问题，数据落地拉起的延迟，这在阿里还是很大的瓶颈。但如果不考虑数据落地拉起，那么Storm接Spark是最好的技术方案之一。
其实还有很多项目都存在大量的状态保存的需求，都是需要使用Spark Streaming来计算的。其实就算使用Spark和Storm的混合架构，数据两次进内存（进程间数据流）也是对网络带宽的浪费，所以如果在不考虑很高的实时要求的情况下，完全可以用Spark Streaming取代掉Storm，对于有状态运算的项目。对于没有状态的项目，当然可以完全用Storm了。