大数据之谜Spark基础篇，我们为什么选择Spark技术_为什么选择spark sql进行本地分析-优快云博客

本文链接：https://blog.youkuaiyun.com/wushuncheng/article/details/79890242

本文对比了Spark与MapReduce、Spark SQL与Hive、Spark Streaming与Storm，阐述Spark在计算速度、查询效率和资源利用率上的优势，解释了为何Spark在大数据领域备受青睐。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

上一节讲解了Spark是什么，这节我们来分析一下，为什么越来越多的公司选择使用Spark了。讲解将从以下几个对比中，分析Spark在现阶段的工作索求。

1、Spark与MapReduce的简易比较

MapReduce一次基本运行:

分析：MapReduce运行过程，这里简单介绍map到reduce需要经过的shuffle阶段，在map结束后会将数据落地HDFS中(如图1、2、3、4标记)，reduce端才从落地HDFS中拉取数据，中间经过复杂的shuffle阶段，到进阶篇详解。这样的计算框架每次shuffle阶段都会有落地到磁盘，也是影响效率的一方面。

Spark一次基本运行：

分析：Spark计算是基于RDD的模型，对于简单的操作，比如map、reduce或是filter之类的操作，在数据量且内存空间允许下是可以直接基于内存进行计算的，这样也就是说有些情况也会落到磁盘，所以Spark的计算速度可以比MapReduce、Hive计算速度快几倍，甚至几十倍。

2、Spark SQL 与 Hvie的简单比较

分析：从上图可以很直观的知道Spark SQL并不是直接全部替换Hive，而只是替换了Hive的查询引擎部分，通过Spark SQL的查询引擎去操作表或是HDFS上的目录文件，从而提高了查询速度。又是Spark一站式生态圈的一员，这样我们更加优选Spark。

3、Spark Streaming 与 Storm的简单比较

Storm简易计算架构：

分析：Storm的计算模型是基于对每一条记录的流式实时计算框架，如上图所示，这可以算是一种非常纯的实时计算框架。也就是这种基于来一条数据就计算处理，这将会大大的占用资源，从而降低整体的吞吐量。这里就不进行详解了，有想研究这种纯实时计算的朋友可以进一步了解，对实时计算要求高的业务是很适合。

Spark Streaming简易计算架构：

分析：这里我们设置时间间隔为1秒，也就是会把1秒里面过来的数据收集起来，然后一次性作为一个batch提交给Spark Streaming进行计算处理。这样基于batch的时间段收集数据，所以就不能是纯的实时计算框架了，只能算是一种准实时计算框架，但是这批量处理对集群资源开效率就下降了，从而也就增加了自身的吞吐量。如果公司业务对实时性要求不是很高，Spark Streaming就完全可以适合，基于原有的Spark集群既可以开发使用，不用再搭建与学习新的技术了。