Spark生态圈
Spark之于Hadoop
个人理解偏向于Spark是一个计算框架，而Hadoop包含计算框架MR与文件系统HDFS，当然Hadoop广泛说法是一个生态，例如包含HBase、Hive等。
Spark是MR的替换方案，兼容HDFS、Hive等生态系统，与MR互补。
Spark相比MR有以下优势：
中间结果输出
基于MR的计算通过将中间结果输出到磁盘，进行存储和容错。基于任务管道的承接考虑，MR任务会生成多个Stage，而串联的Stage依赖于底层文件系统HDFS存储每一个Stage的中间数据。
Spark将执行模型抽象为通用的DAG（有向无环图），将多个stage串联或者并行执行，而无需将Stage的中间结果输出到HDFS。
数据格式和内存布局
由于MR Schema on Read的方式会引起较大的处理开销。Spark抽象出来的分布式内存存储结构，弹性分布式数据集RDD，进行数据的存储。RDD支持粗粒度的写操作，对于读操作，RDD可以精确到每条记录，所以RDD可以用来作为分布式索引。Spark的特性是内容控制数据在不同节点上的分区，用户可以自定义分区策略，例如Hash。
补充说明：目前Hive存储的表格元数据和HDFS存储的表格数据之间在schema上没有一致性保证，也就是得靠管理员来保证。目前Hive对列的改变只会修改 Hive 的元数据，而不会改变实际数据。比如你要添加一个column，那么你用Hive命令行只是修改了了Hive元数据，没有修改HDFS上存储的格式。还得通过修改导入HDFS的程序来改变HDFS上存储的文件的格式。Hadoop系统目前对表的处理是’schema on read’
RDD模型适合粗粒度的全局数据并行计算。不适合细粒度的、需要异步更新的计算。同时有些特殊的计算需求，有些专用的系统会比Spark更适合，例如Storm实时性能比Spark Steaming更高。
Spark Streaming之于Storm
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），而后者需要自己去维护这个窗口。
