设为首页 收藏本站
查看: 1445|回复: 0

[经验分享] intsmaze-刘洋

[复制链接]

尚未签到

发表于 2017-12-16 20:00:04 | 显示全部楼层 |阅读模式
  市面上有一些初学者的误解,他们拿spark和hadoop比较时就会说,Spark是内存计算,内存计算是spark的特性。请问在计算机领域,mysql,redis,ssh框架等等他们不是内存计算吗?依据冯诺依曼体系结构,有什么技术的程序不是在内存中运行,需要数据从硬盘中拉取,然后供cpu进行执行?所有说sprk的特点是内存计算相当于什么都没有说。那么spark的真正特点是什么?抛开spark的执行模型的方式,它的特点无非就是多个任务之间数据通信不需要借助硬盘而是通过内存,大大提高了程序的执行效率。而hadoop由于本身的模型特点,多个任务之间数据通信是必须借助硬盘落地的。那么spark的特点就是数据交互不会走硬盘。只能说多个任务的数据交互不走硬盘,但是sprk的shuffle过程和hadoop一样仍然必须走硬盘的。
本文是翻译的出处 https://0x0fff.com/spark-misconceptions/。
  原文和作者一起讨论:http://www.cnblogs.com/intsmaze/p/7197420.html
  微信:intsmaze
  避免微信回复重复咨询问题,技术咨询请博客留言。
DSC0000.png

误解一:Spark是一种内存技术
  大家对Spark最大的误解就是spark一种内存技术。其实没有一个Spark开发者正式说明这个,这是对Spark计算过程的误解。Spark是内存计算没有错误,但是这并不是它的特性,只是很多专家在介绍spark的特性时,简化后就成了spark是内存计算。
  什么样是内存技术?就是允许你将数据持久化在RAM中并有效处理的技术。然而Spark并不具备将数据数据存储在RAM的选项,虽然我们都知道可以将数据存储在HDFS, HBase等系统中,但是不管是将数据存储在磁盘还是内存,都没有内置的持久化代码。它所能做的事就是缓存数据,而这个并不是数据持久化。已经缓存的数据可以很容易地被删除,并且在后期需要时重新计算。
  但是有人还是会认为Spark就是一种基于内存的技术,因为Spark是在内存中处理数据的。这当然是对的,因为我们无法使用其他方式来处理数据。操作系统中的API都只能让你把数据从块设备加载到内存,然后计算完的结果再存储到块设备中。我们无法直接在HDD设备上计算;所以现代系统中的所有处理基本上都是在内存中进行的。
  虽然Spark允许我们使用内存缓存以及LRU替换规则,但是你想想现在的RDBMS系统,比如Oracle ,你认为它们是如何处理数据的?它们使用共享内存段作为table pages的存储池,所有的数据读取以及写入都是通过这个池的,这个存储池同样支持LRU替换规则;所有现代的数据库同样可以通过LRU策略来满足大多数需求。但是为什么我们并没有把Oracle 称作是基于内存的解决方案呢?再想想操作系统IO,你知道吗?所有的IO操作也是会用到LRU缓存技术的。
  Spark在内存中处理所有的操作吗?Spark的核心:shuffle,其就是将数据写入到磁盘的。shuffle的处理包括两个阶段:map 和 reduce。Map操作仅仅根据key计算其哈希值,并将数据存放到本地文件系统的不同文件中,文件的个数通常是reduce端分区的个数;Reduce端会从 Map端拉取数据,并将这些数据合并到新的分区中。所有如果你的RDD有M个分区,然后你将其转换成N个分区的PairRDD,那么在shuffle阶段将会创建 M*N 个文件!虽然目前有些优化策略可以减少创建文件的个数,但这仍然无法改变每次进行shuffle操作的时候你需要将数据先写入到磁盘的事实!
DSC0001.png

  所以结论是:Spark并不是基于内存的技术!它其实是一种可以有效地使用内存LRU策略的技术。
误解二:Spark要比Hadoop快 10x-100x
  大家在Spark的官网肯定看到了如下所示的图片
DSC0002.png

  这个图片是分别使用 Spark 和 Hadoop 运行逻辑回归(Logistic Regression)机器学习算法的运行时间比较,从上图可以看出Spark的运行速度明显比Hadoop快上百倍!但是实际上是这样的吗?大多数机器学习算法的核心部分是什么?其实就是对同一份数据集进行相同的迭代计算,而这个地方正是Spark的LRU算法所骄傲的地方。当你多次扫描相同的数据集时,你只需要在首次访问时加载它到内存,后面的访问直接从内存中获取即可。这个功能非常的棒!但是很遗憾的是,官方在使用Hadoop运行逻辑回归的时候很大可能没有使用到HDFS的缓存功能,而是采用极端的情况。如果在Hadoop中运行逻辑回归的时候采用到HDFS缓存功能,其表现很可能只会比Spark差3x-4x,而不是上图所展示的一样。
  根据经验,企业所做出的基准测试报告一般都是不可信的!一般独立的第三方基准测试报告是比较可信的,比如:TPC-H。他们的基准测试报告一般会覆盖绝大部分场景,以便真实地展示结果。
  一般来说,Spark比MapReduce运行速度快的原因主要有以下几点:

  • task启动时间比较快,Spark是fork出线程;而MR是启动一个新的进程;
  • 更快的shuffles,Spark只有在shuffle的时候才会将数据放在磁盘,而MR却不是。
  • 更快的工作流:典型的MR工作流是由很多MR作业组成的,他们之间的数据交互需要把数据持久化到磁盘才可以;而Spark支持DAG以及pipelining,在没有遇到shuffle完全可以不把数据缓存到磁盘。
  • 缓存:虽然目前HDFS也支持缓存,但是一般来说,Spark的缓存功能更加高效,特别是在SparkSQL中,我们可以将数据以列式的形式储存在内存中。
  所有的这些原因才使得Spark相比Hadoop拥有更好的性能表现;在比较短的作业确实能快上100倍,但是在真实的生产环境下,一般只会快 2.5x ~ 3x!
  吹一波水,最近太忙了,不仅要克服竞争对手给的数据中埋的雷,还要不断和比利时的合作伙伴通邮件去核对项目的进度与解决方案。但是不妨碍我每月更新一篇文章,-_-。
  老铁,点赞,关注

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-424808-1-1.html 上篇帖子: hadoop 2.7.3本地环境运行官方wordcount 下篇帖子: 从零自学Hadoop(22):HBase协处理器
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表