你好,游客 登录
背景:
阅读新闻

对比Hadoop,Spark受多方追捧的原因

[日期:2014-01-26] 来源:DZone  作者: [字体: ]

  当下,Spark已得到了多方追捧,基于Map Reduce的分布式计算方法使Spark类似于hadoop,却又比Hadoop的通用性更好,迭代运算效率更高,容错能力更强,未来的Spark将会是非常成功的并行计算框架。

  【编者按】作者Mikio Braun是柏林工业大学机器学习专业的博士后,他通过描述了自己对Spark逐步认识的过程,为我们剖析了Spark的原理和应用。作为通用的并行处理框架,Spark具有类似Hadoop的一些优点,而且Spark采用了更好的内存管理,在迭代计算上具有比Hadoop更高的效率,Spark还提供了更为广泛的数据集操作类型,大大方便了用户的开发,checkpoint的应用使Spark具有很强容错能力,众多优越的性能和比Hadoop更广泛的适用面让Spark的进一步发展值得期待。

  以下是译文:

  Apache Spark现在名声大噪。为支持Spark项目成立的Databricks公司从Andereessen Horowittz那里募集了1400万美元,Cloudera也已决定全力支持Spark,还有众多其它公司也积极地加入这件大事。所以我觉得这正是我应该认真了解一下这场躁动的时候。

  我研究了一段时间的Scala API(用Scala写的Spark),老实说一开始我很失望,因为Spark看起来真的太不起眼了。基本的抽象是Resilient Distributed Datasets(RDDs)和基本分布式不可变集,可以基于本地文件或通过HDFS存储在Hadoop上的文件定义,提供常用的Scala-style集合操作(如映射,foreach等)。

  我的第一反应是"没搞错吧,这真是基本分布式集合吗?"。相比之下Hadoop就显得丰富多了:分布式文件系统,众所周知的Map Reduce,支持所有类型的数据格式、 数据源、单元测试、聚类变量等。

  其他人很快就指出还有更多,事实上Spark也提供更复杂的操作(如join、依据操作分组或规约),这样你就可以为相当复杂的数据流建模(虽然没有迭代)。

  随着时间的推移我恍然大悟,原来Spark所谓的简单其实说的大多是关于Hadoop中的Java API而不是Spark本身。即使是简单的例子在Hadoop中通常也会有大量的样板代码。但从概念上讲,Hadoop非常简单,它只提供了两种基本操作:并行的映射(Map)和规约(Reduce)操作。如果用相同的方式,对表示相似分布式集合,事实上将有更小的接口(有些项目像Scalding就是处理类似的事情,并且代码看起来很类似Spark)。

  Spark实际上提供了一组重要的操作,在这一点让我信服以后,我通过这个论文进行了更深入的研究,它描述了通用的架构。RDDs 是Spark的基本构造模块,实际上真的很像分布式不可变集。这些定义的操作(如map或foreach),容易地进行并行处理;还有join运算,需要两个RDDs和收集基于一个共同键的条目;以及依据操作规约,通过用户指定基于键的函数来聚合条目。在单词计数示例中,计数一次就将文本映射到所有的单词,然后用键对他们进行规约,以此来实现字数统计。RDDs可以从磁盘中读取,然后为提高速度而保留在内存中,他们也可以被缓存,那样你就不需要每次都重读他们。仅那样就比Hadoop快了很多,这大部分是基于磁盘的速度。

  容错机制也是Spark的亮点之一。取代给中间结果进行持久化或建立检查点,Spark会记住产生某些数据集的操作序列。因此,当一个节点出现故障时,Spark会根据存储信息重新构造数据集。他们认为这样也不错,因为其他节点将会帮助重建。

  所以本质上,Spark相比纯粹的Hadoop,有更小的接口(可能在将来也会变得臃肿),但有许多基于之上的项目(例如像Twitter的Scalding)达到了类似水平的表现。其他的主要区别是Spark默认情况下是在内存中,这自然带来性能上很大的改善,甚至允许运行的迭代算法。虽然Spark已也没有内置对迭代的支持,不过,就像他们宣称的那样:只要你想要,它就可以快到让你可以进行迭代。

  Spark流——微批处理的回归

  Spark还配有一个流数据处理模型,这当然让我很感兴趣。还有一篇对设计总结得很漂亮的论文。与Twitter的Storm框架相比,Spark采用了一种有趣而且独特的办法。Storm基本上是像是放入独立事务的管道,在其中事务会得到分布式的处理。相反,Spark采用一个模型收集事务,然后在短时间内(我们假设是5秒)以批处理的方式处理事件。所收集的数据成为他们自己的RDD,然后使用Spark应用程序中常用的一组进行处理。

  作者声称这种模式是在缓慢节点和故障情况下会更加稳健,而且5秒的时间间隔通常对于大多数应用已经足够快了。对于这一点,我不太确定,因为分布式计算总是很复杂,我不相信你能随意说有些东西是就比其他人的好。这种方法也很好地统一了流式处理与非流式处理部分,这一点是千真万确的。

  结束语

  Spark在我看来还是很有前途的,加上Spark被给予的支持和获得的关注,我坚信它将成熟起来并将在这个领域扮演更加重要的角色。当然,它不可能适用于所有场景,正如作者承认的那样,基于RDD稳定性只更改很少条目的操作就不适合。原则上,你必须对整个数据集备份,即使你只是想要更改一个条目。这可以很好地并行处理,但成本很高。copy-on-write在这里可能更有效,但是还未被实现。

  最上层是在TU Berlin的研究项目,有类似的目标,然而却通过更为复杂的操作(如迭代)来发展,不仅是为了容错能力存储一系列操作,而且要将它们用于全局调度优化和平行化。





收藏 推荐 打印 | 录入: | 阅读:
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款