两款高性能并行计算引擎Storm和Spark比较

公司的项目，既没有用到storm，也没有用到spark。但是思路的storm有点神似。

简单介绍一下项目，要从分布式消息队列订阅消息，通过rpc框架去调用。两个角色worker、monitor，都注册在zk上。monitor是leader，用来管理。worker负责订阅。monitor把消息管道负载均衡的注册在worker节点下。worker挂了monitor就会把管道给别的worker。worker不停的去订阅数据流。
http://blog.csdn.net/iefreer/article/details/32715153
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），而后者需要自己去维护这个窗口。