Spark迷思

目前在媒体上有很大的关于Apache Spark框架的声音,渐渐的它成为了大数据领域的下一个大的东西。证明这件事的最简单的方式就是看google的趋势图:

上图展示的过去两年Hadoop和Spark的趋势。Spark在终端用户之间变得越来越受欢迎,而且这些用户经常在网上找Spark相关资料。这给了Spark起了很大的宣传作用;同时围绕着它的也有误区和思维错误,而且很多人还把这些误区作为银弹,认为它可以解决他们的问题并提供比Hadoop好100倍的性能。

这篇文章将为希望在自己系统接入Spark的技术员们讲解大家对它的一些主要误区。我要说的是这些误区主要是源于市场上一些专家的谣传和过度简单化。Spark的文档也很清楚了反驳了这些专家的观点,但是需要我们去大量阅读。因此,下面我所提到的误区主要包括以下几个方面:

  1. Spark是一项基于内存的技术
  2. Spark的执行速度比Hadoop快10到100倍
  3. Spark在市场上引入了一种全新的数据处理方式

排在第一位的也是最重要的误区是Spark是一项“基于内存”的技术。不是的,从来没有任何一个Spark开发者官方的声明过这种特性。这是基于对Spark计算过程的误解。

但是这里让我们回到开始的问题。到底什么样的技术才能称之为内存技术?我认为是能够允许我们将数据存储在内存中并有效处理这些数据的技术。而我们在Spark中看到了什么?它并没有选项可以让我们将数据存放在内存中;虽然Spark有可插拔式的连接器可以连接到很多持久化存储系统HDFS、Tachyon、HBase、Cassandra等等,但是就是没有自带将数据存储到内存或者硬盘上的代码。而它所能做的只是缓存数据而不是持久化数据;缓存数据是很容易会被通过连接器连接的数据源删除或者更新的。

其次,有些人针对我们以上的观点抱怨说,Spark是在内存中处理数据的啊。当然是在内存中处理,因为你没有选择来使用其他方式来处理数据;所有在OS API上的操作都只是允许我们将数据从块设备上加载到内存中或将内存中的数据卸载至块设备上。我们不能直接使用HDD而不将HDD上的数据加载到内存中,所以现代操作系统上的所有数据处理都是在内存中进行的。

事实上,Spark对于内存缓存允许我们使用LRU(最近最少使用)回收算法。您可能仍然认为它是基于内存的技术,至少我们在处理数据时它是在内存中的。但是让我们再看看RDBMS(关系型数据库系统)市场,这里举两个例子:Oracle和PostgreSQL。你认为它们是怎么处理数据的?它们使用共享内存段来作为表page内存池,而且所有的数据读写都是有这个内存池服务的,而且这个内存池也是使用LRU规则来释放并不是脏数据的表page内存(而且如果有太多脏的page时会出发检查点来处理)。所以总的来说,现代数据库也利用基于内存的LRU算法来满足它们的需求。那么为什么我们不说Oracle和PostgreSQL为基于内存的数据库呢?还有就是关于Linux
IO,你知道所有传递给操作系统的IO操作的缓存也同样是基于LRU的缓存吗?

甚至,你知道Spark在内存中处理所有transformation吗?你可能感到很失望,Spark的核心“shuffle”会将数据写入磁盘中,如果我们在我们的Spark SQL语句中使用了group by语句或者我们刚刚讲RDD转换为PairRDD并且通过键来调用聚合操作,那么我们正在强制Spark将数据根据key的哈希值分发到各个数据节点。Shuffle处理包含两个阶段,就是通常所说的“map”和“reduce”:“map”阶段仅仅计算key的哈希值(或者是自定义的其他分割函数)并将结果输出N个单独的文件到本地磁盘上,其中N就是“reudce”端的分区数;“Reduce”端拉取“map”端的计算结果并将其合并新的分区,因此如果我们的RDD有M个分区,则我们将它转换为一对RDD时会在集群中生成M*N个文件,这些文件包含RDD中的所有数据;有一些优化手段可以减少生成的文件数量;此外还有一些工作来预排序这些文件并且在“reduce”端“合并”这些文件,但这并不能改变如果我们想要处理数据就得将数据放入HDD的事实。

所以,Spark并不是一项基于内存的技术。这是一项可以让我们有效的利用基于内存的LRU方法在内存存满时将数据卸载至硬盘中;而且它没有内置持久化功能(内存、硬盘都没有),它会在shuffle过程中将所有数据放到本地文件系统中。

下一个误区是“Spark执行速度比Hadoop快10到100倍”。这里我们引用一篇早先发表的文章:http://laser.inf.ethz.ch/2013/material/joseph/LASER-Joseph-6.pdf。这篇文章声称Spark的目标是支持迭代的任务,典型的机器学习。但是如果我们参考Apache网站上Spark的主页时就会再次发现一个让我们眼前一亮的例子:

此外,上图中这个例子是关于机器学习算法“logistic回归分析”的。那么什么是机器学习中最主要的部分呢?那就是在同一个数据集上的多次的反复迭代。而这里正是Spark的内存中缓存LRU算法的真正亮点;当我们反复的连续多次扫描同一组数据时,我们只需要在第一次使用这些数据的时候才去读取它,其后都是从内存中读取这些数据,这种做法真的很好;但不幸的是,他们用比较奇怪的方式来运行这些脚本:虽然在Hadoop上运行这些脚本但却没有使用HDFS的缓存功能(http://hadoop.apache.org/docs/r2.3.0/hadoop-project-dist/hadoop-hdfs/CentralizedCacheManagement.html)。当然他们没有义务一定要这样去做,但是我认为就是这个不同会导致性能下降3到4倍(更高效的实现方式是不将中间数据放入HDD,这样任务启动更快)。

压力测试在企业领域的悠久历史教会了我一件事:从来不要相信压力测试。对于任何两个有竞争关系的系统我们都能找到一系列例子来证明系统A比系统B快,同样也能找到很多文章来证明系统B比系统A快。我们所能相信的(当然也要保持怀疑态度)的是独立的第三方压测工具,如TCP-H;因为它们是独立的,所以会覆盖尽可能多的场景来展示真实的性能情况。

总的来说,Spark比Hadoop快主要是因为:

  1. 任务启动更快。Spark使用线程,而MR则重新启动了新的JVM。
  2. Shuffle阶段更快。Spark在shuffle期间仅仅将数据放入HDD一次;而MR做了两次。
  3. 工作流更快。传统的MR工作流是一系列MR job,每个job在迭代时都会讲数据存入HDFS;而Spark支持DGA和管道操作,这样就可以让我们执行复杂的工作流而不用将中间数据持久化(除非要进行shuffle)。
  4. 缓存。对于这点持怀疑态度,因为目前HDFS也可以使用缓存,但总的来说Spark缓存还是非常好的,尤其是它的SparkSQL部分会将数据缓存在面向列的表单中。

以上所有这些使得Spark性能比Hadoop要好,对运行时间比较短的任务来说能达到Hadoop的100倍;但在真实的生产环境中不会超过2.5到3倍。

最后的一个被很少提及的误区是:“Spark在市场上引入了一种全新的数据处理方法”。事实上,Spar没有引入任何新的改革。虽然他们在实现高效的LRU缓存和pipeline上的想法很好,但他们并不是前无古人的。如果我们打开思维去思考这个问题,我们可能会发现所实现的几乎和早先MPP数据库中所引入的概念完全一样:查询的管道式执行、没有中间数据会持久化、对表的页数据进行LRU缓存。如你所见,Spark的核心和其之前的技术并没有不同。当然,有一个很大的进步就是Spark用开源的方式实现了这些,并且通过互联网社区免费提供给了用户,而对于企业来说可以在不降低性能的前提下不用再去支付企业级的MPP技术费用。

最后,我建议大家不要相信我们从媒体上所听到的任何事情;相信相关方面的技术专家,他们通常是我们最好的提问者。

1. 本文由程序员学架构翻译

2.原文地址:http://0x0fff.com/spark-misconceptions/

2. 转载请务必注明本文出自:程序员学架构(微信号:archleaner)

3. 更多文章请扫码:

时间: 2024-10-02 18:19:53

Spark迷思的相关文章

关于数据挖掘和数据分析的一点迷思!

关于数据分析和数据挖掘学习的一点迷思 可能有些数据挖掘工程师的工作就是研究算法研究数学,不需要他们去做数据清洗,做报表展示类的工作,这类就是大牛了,不需要再读下去了 关于数据这条路大家的一致认为业务和数学是很重要的,一切的分析思路和算法都要结合业务来做,算法(数学)是内功: 但是这两点对于普通人来说都不可能速成,业务能力靠的经验积累,在一个行业里摸爬滚打多年才能对行业有个清晰完整的认识: 数学这个我不是数学专业的,但是接触过一些感觉用数学解决实际问题也不是一朝一夕或者说本科硕士一毕业就行的. 这

区块链机遇中暗含迷思,下个BAT来自区块链平台技术

(上图为Gartner研究总监季新苏) 作为下一代全球信用认证和价值互联网基础协议之一,区块链技术近年正逐渐受到国内外政府机关.国际组织和金融机构的重视和关注.放眼国际,全球有24个国家正在大力投资发展区块链技术:90多个国家中央银行已经开始讨论布局和发展区块链技术:目前全球90多个大型跨国公司加入了区块链技术联盟. 而在国内,2017年4月,乌镇智库发布的<中国区块链产业发展白皮书>显示,截至2016年底,中国共有105家区块链相关企业.2016年,中国新增区块链企业数超过美国,占全球新增企

取证分析的迷思

由于证物特性的不同,在进行digital evidence的取证分析时,第一要务便是确保电子证据在过程中不致遭受污染或破坏.且由于是和计算机科技有关,随着科技的进步也会多所变化,因此取证分析也要能跟的上变化. 大家耳熟能详的就不提了,在此想分享的是取证分析的从业工作者在取证分析上的迷思,给大家参考.以避免犯了相关病征而不自知. 1.只知操作工具,而未能了解原理或本质 只知使用工具,而未能了解何以如此,那就可能成了"取证分析匠",在不懂"为何"及"如何&qu

前端迷思与React.js

前端迷思与React.js 前端技术这几年蓬勃发展, 这是当时某几个项目需要做前端技术选型时, 相关资料整理, 部分评论引用自社区. 开始吧: 目前, Web 开发技术框架选型为两种的占 80% .这种戏剧性的变化持续了近 6 年. 自 2013 年 5 月推出以来,ReactJS 在过去三年中已成为了 Web 开发领域的中坚力量. 任何组件与框架都有它的适用场景, 我们应该冷静分析与权衡, 先来看React.js 1 从功能开发角度说,React的思路很好.2 从页面设计角度说,传统的HTML

区块链狂热大面积爆发,Gartner建议认清五大迷思

(上图为Gartner研究副总裁兼院士级分析师Ray Valdes) 国际著名市场调查机构Gartner观察到,多种迹象显示自2015年8月以来大面积爆发了区块链狂热.实际上尽管到2015年底才成立了Linux基金会赞助下的HyperLedger超级账本项目,但自此之后的该项目就从最开始的30家创始成员公司迅速扩展到55家成员,还有2300个成员申请待处理. Linux基金会HyperLedger超级账本项目执行董事Brian Behlendorf亦于今年7月到访中国,他介绍Linux社区对于区

有漏应以正见段之哲学迷思——人活着有什么意义?

有漏应以正见段之哲学迷思——人活着有什么意义? 今天再次陷入了无聊无力之中.又开始问自己这个问题:都说有多大欲望就有多大成就,可是我找不到生命的意义,搞不清楚人为什么要活着?没有什么东西是我特别热爱的? 想要解答这个问题,常规的办法当然就是微信搜索一下,看看网友们都有怎样的回答! 但其实这不过是浪费时间罢了!徒劳罢了!这种人生大问题,一般人是无法给予答案的! 还是从佛法的角度如理作意吧! 当不断思考“我为什么要活着?我活着有什么意义?” 从佛法的角度讲,首先是有我见,其次是有人见! 执着一个我,

[Win8 APP]击破联络人迷思

当你开启win 8 的时候 面对一堆的APP 你是否会茫然呢? 今天 我选了一个'联络人App' 来讲解它的功用与好处 看到联络人APP 你应该会觉得这东西不必要吧?! 毕竟 正常情况下你不会拿电脑来打电话 那要这个干嘛?? 当然Mircosoft 会内建这个APP 就一定有它的功能 让我来带领你一一了解吧 '联络人App' 如果你是用本机账户登入电脑 那你一开始进入这个使用程序的时候 他会要求你建立/登入你的Windows Live Account(Windows Live账号) 当你使用此账

深夜Python - 第1夜 - for 迷 in 迷思

深夜Python - 第1夜 - for 迷 in 迷思 在一个月黑风高的夜晚,我悄悄打开编辑器,进入程序的世界.刚刚学会Python的我,由于一段时间的过度装B,被委托优化一段程序,我信心十足地接下来,看了又看……这不挺好的程序吗?但是又觉得哪不太对,无奈,只好去找夜猫兄. “夜猫兄!速救!——”我敲门敲出了过年放烟花般的氛围.夜猫兄刚刚起床,瞅瞅我的程序,然后瞅瞅我,一脸鄙夷:“这……是你写的?” “这是……其实是β兄的原创……”我感觉不妙…… “真差!”夜猫兄只说了这2个字. “啥啥啥?”

概率论迷思

当你抛起一枚硬币,你不知道它会是正面还是反面,但你确切的知道正面与反面的概率都是50%.概率论的神奇之处在于,它居然能从不确定性中找到确定性. 本文不教科书,只是阐述我的观点和思考,如有谬误,欢迎讨论或指正. 一些有趣的观点: 一个事情有N种发生的可能性,我们不能确信哪种会发生,是因为我们不能控制结果的发生,影响结果的许多因素不在我们的支配范围之内,这些因素影响结果的机理或者我们不知道,或者太复杂以至于超出了我们大脑或电脑的运算能力.比如:我们不确定掷硬币得到正面或反面,是因为我们的能力不足以用