简介
hadoop
- 是一个文件系统，外加一个离线处理框架（map-reduce执行框架），主要用于海量数据文件的保存、非实时的海量数据的计算。
- 提供的上层api不太友好，且mapreduce处理框架比较慢，现在基本上只拿它来作为文件系统使用。
spark
- 是一个执行引擎，本身不保存数据，需要外部的文件系统来保存数据，很多时候会基于hadoop来保存数据。
- spark计算时尽可能把数据放到内存中（基于内存），还提供了很好的上层用户使用的接口，包括spl语句（spark sql），处理数据十分方便。它比map-reduce处理框架（基于磁盘）要快很多倍。现在基本上用它来做离线数据处理。
storm
- 是一个实时数据处理框架，只提供最基本的数据流传输框架元素和基本的数据流接口，用户需要自己编写处理过程和处理逻辑。
flink
- 是实时数据处理系统，自己有一套完整的生态。上层提供了很多数据处理算子（接口函数）供用户使用，对用户更加友好，方便使用。现在很多公司都用它来进行实时数据处理。
Hadoop、Spark、Flink
其他网址
1、数据处理对比
Hadoop专为批处理而生，一次将大量数据集输入到输入中，进行处理并产生结果。
Spark：定义是一个批处理系统，但也支持流处理。
Flink：支持批处理和流处理。两者可以单独运行，也可以流批一体地运行。
2、流引擎对比
Hadoop：Hadoop默认的MapReduce，仅面向于批处理。
Spark：Spark Streaming以微批处理数据流，实现准实时的批处理和流处理。
Flink：Flink是真正的实时流引擎，使用流来处理工作负载，包括流，SQL，微批处理和批处理。
3、数据流对比
Hadoop：MapReduce计算数据流没有任何循环，每个阶段使用上一阶段的输出，并为下一阶段产生输入。
Spark：尽管机器学习算法是循环数据流，但Spark将其表示为（DAG）直接非循环图或有向无环图。
Flink：Flink在运行时支持受控循环依赖图，支持机器学习算法非常有效。
4、计算模型对比
Hadoop：MapReduce采用了面向批处理的模型，批处理静态数据。
Spark：Spark采用了微批处理。微批处理本质上是一种“先收集再处理”的计算模型。
Flink：Flink采用连续流式流传输模型，实时对数据进行处理，而不会在收集数据或处理数据时出现任何延迟。
5、性能对比
Hadoop：Hadoop仅支持批处理，不支持处理流数据，与Spark和Flink相比，性能会降低。
Spark：支持微批处理，但流处理效率不如Apache Flink。
Flink： 性能很强。Flink使用本机闭环迭代运算符，尤其在支持机器学习和图形处理方面，表现优异。
6、内存管理对比
Hadoop：提供可配置的内存管理，可以动态或静态地执行此操作。
Spark：提供可配置的内存管理，从Spark 1.6开始已朝着自动进行内存管理的方向发展。
Flink：有自己的内存管理系统，提供自动内存管理。
Spark VS Storm
其他网址
| 对比点 |
Spark Streaming |
Storm |
| 实时计算模型 |
准实时，对一个时间段内的数据收集起来，作为一个RDD，再处理 |
纯实时，来一条数据，处理一条数据 |
| 实时计算延迟度 |
秒级 |
毫秒级 |
| 吞吐量 |
高 |
低 |
| 事务机制 |
支持，但不够完善 |
支持完善 |
| 健壮性 / 容错性 |
Checkpoint，WAL，一般 |
ZooKeeper，Acker，非常强 |
| 动态调整并行度 |
不支持 |
支持 |
Storm使用场景
1、建议在那种需要纯实时，不能忍受1秒以上延迟的场景下使用，比如实时金融系统，要求纯实时进行金融交易和分析
2、此外，如果对于实时计算的功能中，要求可靠的事务机制和可靠性机制，即数据的处理完全精准，一条也不能多，一条也不能少，也可以考虑使用Storm
3、如果还需要针对高峰低峰时间段，动态调整实时计算程序的并行度，以最大限度利用集群资源（通常是在小型公司，集群资源紧张的情况），也可以考虑用Storm
4、如果一个大数据应用系统，它就是纯粹的实时计算，不需要在中间执行SQL交互式查询、复杂的transformation算子等，那么用Storm是比较好的选择
Spark Streaming使用场景
1、如果对上述适用于Storm的三点，一条都不满足的实时场景，即，不要求纯实时，不要求强大可靠的事务机制，不要求动态调整并行度，那么可以考虑使用Spark Streaming
2、考虑使用Spark Streaming最主要的一个因素，应该是针对整个项目进行宏观的考虑，即，如果一个项目除了实时计算之外，还包括了离线批处理、交互式查询等业务功能，而且实时计算中，可能还会牵扯到高延迟批处理、交互式查询等功能，那么就应该首选Spark生态，用Spark Core开发离线批处理，用Spark SQL开发交互式查询，用Spark Streaming开发实时计算，三者可以无缝整合，给系统提供非常高的可扩展性
Spark Streaming与Storm的优劣分析
Spark Streaming绝对谈不上比Storm优秀。这两个框架在实时计算领域中，都很优秀，只是擅长的细分场景并不相同。
Spark Streaming仅仅在吞吐量上比Storm要优秀，而吞吐量这一点，也是历来挺Spark Streaming，贬Storm的人着重强调的。但是问题是，是不是在所有的实时计算场景下，都那么注重吞吐量？不尽然。因此，通过吞吐量说Spark Streaming强于Storm，不靠谱。
Storm在实时延迟度上，比Spark Streaming就好多了，前者是纯实时，后者是准实时。而且，Storm的事务机制、健壮性 / 容错性、动态调整并行度等特性，都要比Spark Streaming更加优秀。
Spark Streaming，有一点是Storm绝对比不上的，就是：它位于Spark生态技术栈中，因此Spark Streaming可以和Spark Core、Spark SQL无缝整合，也就意味着，我们可以对实时处理出来的中间数据，立即在程序中无缝进行延迟批处理、交互式查询等操作。这个特点大大增强了Spark Streaming的优势和功能。
Spark VS Flink
其他网址
| 项 | Spark | Flink |
| 成熟度 | 高（因为起步早） | 低 |
| 侧重点 | 批处理 | 流处理 |
| 实时性 | 准实时 | 真正实时 |
| 流行度 | 使用的公司较多。 | 较少（因为起步晚） |
| 性能 | 弱于Flink | 强于Spark |
| 发展趋势 | 发展趋势不如Flink | 发展趋势好于Spark |
| 好用的地方 | 批处理 | 时间机制、状态管理、流批一体 |