Spark基于这样的理念,当数据庞大时,把计算过程传递给数据要比把数据传递给计算过程要更富效率。每个节点存储(或缓存)它的数据集,然后任务被提交给节点。所以这是把过程传递给数据。这和Hadoop map/reduce非常相似,除了积极使用内存来避免I/O操作,以使得迭代算法(前一步计算输出是下一步计算的输入)性能更高。Shark只是一个基于Spark的查询引擎(支持ad-hoc临时性的分析查询)而Storm的架构和Spark截然相反。Storm是一个分布式流计算引擎。每个节点实现一个基本的计算过程,而数据项在互相连接的网络节点中流进流出。和Spark相反,这个是把数据传递给过程。两个框架都用于处理大量数据的并行计算。Storm在动态处理大量生成的“小数据块”上要更好(比如在Twitter数据流上实时计算一些汇聚功能或分析)。Spark工作于现有的数据全集(如hadoop数据)已经被导入Spark集群,Spark基于in-memory管理可以进行快讯扫描,并最小化迭代算法的全局I/O操作。不过Spark流模块(Streaming Module)倒是和Storm相类似(都是流计算引擎),尽管并非完全一样。Spark流模块先汇聚批量数据然后进行数据块分发(视作不可变数据进行处理),而Storm是只要接收到数据就实时处理并分发。不确定哪种方式在数据吞吐量上要具优势,不过Storm计算时间延迟要小。总结下,Spark和Storm设计相反,而Spark Steaming才和Storm类似,前者有数据平滑窗口(sliding window),而后者需要自己去维护这个窗口。
另外,也可以从不同方面进行对比:
Spark streaming和Storm作为当今流行的实时流计算框架,已经在实时计算方案应用的非常广泛了,其中spark streaming是基于spark的一个扩展,比storm的出现要晚一些。本章节从以下几个角度对两者进行了阐述,可以作为选型方面的一个参考。
A、 数据处理方式
Spark streaming是构建在spark上的实时流计算框架,利用时间批量窗口生成spark的计算输入源RDD,后对该RDD生成Job,进行排队调度到spark计算框架中执行,底层是基于spark资源调度和任务计算框架的;Spark streaming是基于数据的批处理方式,针对数据形成任务进行计算,是移动计算而不移动数据,而Storm恰恰相反,storm在处理架构上是数据流入到计算节点,移动的是数据而不是计算,对于时间窗口的批量数据处理,需要用户自己来实现,这个在之前的storm系列的相关章节中有介绍。
B、 生态体系
Spark streaming是基于spark的,可以和spark其他的组件结合,实现交互式的查询adhoc,机器学习MLib等。Storm相对来讲,只是作为一个流式计算框架,缺乏现有的Hadoop生态体系的融合。
C、 延迟以及吞吐量
Spark streaming基于对批量数据的处理,依赖spark的调度和计算框架,在延迟方面比storm要高,一般最小的延迟在2s左右,而storm可以达到100ms以内。正因为spark streaming是批处理的方式处理数据,整体的吞吐量比较高。
D、 容错性
Spark streaming通过lineage以及在内存维护两份数据备份进行容错,通过lineage记录之前对RDD的操作,若某节点在运行时候出现故障,则可以通过备份数据在其他节点重新计算得到。
Storm通过ack组件进行数据流的跟踪,开销比sparking streaming要大。
E、 事务性
Spark streaming保证数据只被处理一次,并且是在批处理的层次级别。
Storm通过跟踪机制能保证每个记录至少被处理一次,如果需要保证状态只更新一次的话,需要由用户自己来实现。
所以对于statefull的计算,对事务性比较高的话,spark streaming要更好一些。