首页
学习
活动
专区
工具
TVP
发布

大数据之谜Spark基础篇,我们为什么选择Spark技术

上一节讲解了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集群既可以开发使用,不用再搭建与学习新的技术了。

通过上述几个简易的比较,我们选择Spark的优势也就很明显得知了,后面我们将一起探索Spark之谜。基于这几年工作中使用到的Spark技术来分析讲解,追求干货,通过实战方式来分享。

希望对你我他有用

有不足之处请多多指教

欢迎留言评论!!!

欢迎关注大数据之谜

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180406A0Y5Q500?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券