Spark streaming & storm流式计算框架对比

原文链接：http://blog.csdn.net/yangbutao/article/details/44538637，致谢

Spark streaming和Storm作为当今流行的实时流式计算框架，已经在实时计算方案应用的非常广泛了，其中spark streaming是基于spark的一个扩展，比storm的出现要晚一些。本章节从以下几个角度对两者进行了阐述，可以作为选型方面的一个参考。

1、 数据处理方式

Spark streaming是构建在spark上的实时流计算框架，利用时间批量窗口生成spark的计算输入源RDD，后对该RDD生成Job，进行排队调度到spark计算框架中执行，底层是基于spark资源调度和任务计算框架的；Spark streaming是基于数据的批处理方式，针对数据形成任务进行计算，是移动计算而不移动数据，而Storm恰恰相反，storm在处理架构上是数据流入到计算节点，移动的是数据而不是计算，对于时间窗口的批量数据处理，需要用户自己来实现，这个在之前的storm系列的相关章节中有介绍。

2、 生态体系

Spark streaming是基于spark的，可以和spark其他的组件结合，实现交互式的查询adhoc，机器学习MLib等。Storm相对来讲，只是作为一个流式计算框架，缺乏现有的Hadoop生态体系的融合。

3、 延迟以及吞吐量

Spark streaming基于对批量数据的处理，依赖spark的调度和计算框架，在延迟方面比storm要高，一般最小的延迟可能在几秒钟左右，而storm可以达到100ms以内。正因为spark streaming是批处理的方式处理数据，整体的吞吐量比较高。

4、 容错性

Spark streaming通过lineage以及在内存维护两份数据备份进行容错，通过lineage记录之前对RDD的操作，若某节点在运行时候出现故障，则可以通过备份数据在其他节点重新计算得到。

Storm通过ack组件进行数据流的跟踪，开销比sparking streaming要大。

5、 事务性

Spark streaming保证数据只被处理一次，并且是在批处理的层次级别。

Storm通过跟踪机制能保证每个记录至少被处理一次。实际上，Storm借助其内置的Trident机制也实现了Exactly Once功能，但其实现依赖于事务更新机制，这会导致处理比较耗时，且通常由用户自行实现，适用于一些对数据冗余零容忍的场景。

所以对于statefull的计算，对事务性比较高的话，spark streaming要更好一些。