spark 与storm的对比及适用场景

     学习大数据有一段时间了,学完spark 和storm 后,就希望这两个实时处理系统做个对比,以便于在以后的技术选型方面有很好的把握。

转载如下:

http://www.cnblogs.com/yaohaitao/p/5703288.html



对比点

Storm

Spark Streaming

实时计算模型

纯实时,来一条数据,处理一条数据

准实时,对一个时间段内的数据收集起来,作为一个RDD,再处理

实时计算延迟度

毫秒级

秒级

吞吐量

事务机制

支持完善

支持,但不够完善

健壮性 / 容错性

ZooKeeper,Acker,非常强

Checkpoint,WAL,一般

动态调整并行度

支持

不支持

 Spark Streaming与Storm的应用场景

 

对于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的优势和功能。


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计算时间延迟要小。

总结下,SparkStorm设计相反,而Spark Steaming才和Storm类似,前者有数据平滑窗口(sliding window),而后者需要自己去维护这个窗口。















  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: Flink、StormSpark是三种常见的大数据处理框架。下面我将针对这三种框架进行对比分析。 首先,Flink是一种流式处理引擎,可以提供低延迟和高吞吐量的流式数据处理。Flink提供了复杂事件处理、窗口操作和状态管理等功能,适用于需要实时处理和分析大规模数据的场景。相比之下,Storm是另一种流处理框架,它提供了类似的功能,但在低延迟方面表现更佳。Storm采用了可扩展的分布式架构,可以在分布式环境下处理海量的流式数据。Spark则是一种批处理和流处理框架的结合体,它不仅支持实时处理,还能处理离线批量数据。Spark提供了强大的查询和计算能力,适用于各种复杂的数据处理任务。 其次,Flink和Spark都支持内存计算,可以将数据存储在内存中进行快速计算,提高了处理效率。相比之下,Storm主要侧重于低延迟,因此在处理大规模数据时可能会受到性能瓶颈的限制。此外,Flink和Spark都提供了对常见数据源的支持,如Hadoop、Kafka等,可以方便地与其他系统集成。而Storm虽然也支持多种数据源,但通常需要自定义开发来实现集成。 最后,Flink和Spark都提供了比Storm更强大的容错机制。它们都可以通过将数据进行分区和复制来确保数据的安全性和可靠性。而Storm在容错方面相对较弱,需要用户自行实现。 综上所述,Flink适用于需要实时处理和分析大规模数据的场景Spark适用于对大规模数据进行离线和实时处理的场景,而Storm则更适合对低延迟有强需求的场景。选择合适的框架应根据具体需求和场景来决定。 ### 回答2: flink、stormspark 都是流式计算框架,但它们在设计理念、架构和应用场景上有所差异。 flink 的设计目标是提供一种高性能、高吞吐、低延迟和容错性强的流处理框架,可以进行流式和批处理计算。flink使用了基于事件驱动的分布式流处理模型,并提供了丰富的操作符和状态管理机制。flink还支持迭代计算和图计算,使其在迭代、图计算等复杂应用场景下具有优势。 storm 是一个开源的分布式实时计算框架,它提供了可靠性强、高性能的实时数据处理能力。storm使用了层次化的拓扑结构,能够处理实时和流式数据流,适用于需要低延迟、高吞吐的实时计算场景storm具有较高的可伸缩性和容错性,但其执行模型相对简单。 spark 是一个通用的大数据处理框架,可以进行批处理、流处理和机器学习等各种计算任务。spark 提供了基于内存的计算引擎,具有更快的数据处理速度。spark适用于灵活的数据分析和复杂的数据处理,拥有丰富的API和优化机制。但因为spark不是专为流处理设计,所以在低延迟和流式计算方面的性能可能不如flink和storm。 综上所述,flink、stormspark 在设计目标和应用场景上有所差异。flink适用于复杂的流处理、迭代和图计算,storm适用于实时和流式数据的低延迟处理,spark适用于灵活的数据分析和复杂的批处理。选择合适的框架应考虑具体的业务需求和计算场景

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值