简介：

SparkStreaming是流式处理框架7*24小时不间断运行，延迟度一般是5s左右，是Spark API的扩展，支持可扩展、高吞吐量、容错的实时数据流处理，实时数据的来源可以是：Kafka, Flume, Twitter, ZeroMQ或者TCP sockets，并且可以使用高级功能的复杂算子来处理流数据。例如：map,reduce,join,window 。最终，处理后的数据可以存放在文件系统，数据库等，方便实时展现。

SparkStreaming&Storm：

1.SaprkStreaming是微批处理，吞吐量大，Storm是实时处理，吞吐量小

2.SparkStreaming擅长处理复杂的业务，Storm擅长处理汇总型业务

3.Storm的事务完善，SaprkStreaming相对完善

4.Storm支持动态资源调度，Spark1.2也支持，但是不建议开启

对比点

Storm

实时计算模型:纯实时，来一条数据，处理一条数据

实时计算延迟度:毫秒级

吞吐量:低

事务机制：支持完善

健壮性 / 容错性：ZooKeeper，Acker，非常强

动态调整并行度：支持

Spark Streaming

实时计算模型:准实时，对一个时间段内的数据收集起来，作为一个RDD，再处理

实时计算延迟度:秒级

吞吐量：高

支持完善：支持，但不够完善

健壮性 / 容错性：Checkpoint，WAL，一般

动态调整并行度：不支持

SparkStreaming与Storm的应用场景：

对于storm来说：

1.建议在那种需要纯实时，不能忍受1秒以上延迟的场景下使用，比如实时金融系统，要求纯实时进行金融交易和分析。

2.如果对于实时计算的功能中，要求可靠的事务机制和可靠性机制，即数据的处理完全精准，一条也不能多，一条也不能少，也可以考虑使用Storm。

3.如果还需要针对高峰低峰时间段，动态调整实时计算程序的并行度，以最大限度利用集群资源（通常在小型公司，集群资源紧张的情况），也可以考虑使用storm。

——亮点

4.如果是一个大数据应用系统，它就是纯粹的实时计算，不需要在中间执行SQL交互式查询，复杂的transformation算子等，那么用Storm是最好的选择。

对于SparkStreaming来说：

1.业务场景不要求纯实时，不要求强大可靠的事务机制，不要求动态调整并行度，那么可以考虑使用SparkStreaming。

2.考虑使用Spark Streaming 最主要的一个因素，应该是针对整个项目进行宏观的考虑，即，如果一个项目除了实时计算之外，还包括了离线批处理、交互式查询等业务，而且实时计算中，可能还会牵扯到高延迟批处理、交互式查询等功能，那么就应该首选Spark生态，用Spark Core开发离线批处理，用Spark SQL开发交互式查询，用Spark Streaming开发实时计算，三者可以无缝整合，给系统提供非常高的可扩展性。

总的来说：这两个框架在实时计算领域都很优秀，只是擅长的细分场景并不相同。Storm在实时延迟度上，比Saprk Streaming就好很多，前者是纯实时的，后者是准实时的，而且Storm的事务机子、健壮性、容错性，动态调整并行度等特性，都要比Spark Streaming更加优秀

Spark Streaming有一点是Storm 绝对比不上的，就是它位于Spark生态技术栈中，因此Spark Streaming可以和Spark Core、Spark SQL无缝整合，也就意味着，我们可以对实时处理出来的中间数据，立即在程序中无缝进行延迟批处理、交互式查询等操作。

SparkStreaming处理数据流程：

1.每隔batchInterval将接收来的数据存在一个batch中，这个batch又被封装到RDD中，RDD被封装到DStream中

2.DStream有自己的Transformation类算子，懒执行，需要DStream中的OutPutOperator类算子触发执行

3.当batchInterval时间大于集群处理一批次数据的时间，集群资源不能充分利用

4.当batchInterva时间小于集群处理一批次数据的时间，任务有堆积

5.结合WebUI调节batchInterval到一个合适的时间，batchInterval与处理一批次的数据时间相同