你好,游客 登录 注册 发布搜索
背景:
阅读新闻

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

[日期:2014-03-28] 来源:51COT  作者: [字体: ]

  

Hadoop

  作者观察到Apache Spark 最近发出一些不同寻常的事件,Databricks将提供$14M美金支持Spark,Cloudera决定支持Spark,Spark被认为是大数据领域的大事情。

  美好的第一印象

  作者认为自己已经与Scala的API(Spark使用Scala编写)打交道了一段时间,说实话,起初是相当深刻的印象,因为Spark是看上去这么小而好。基本的抽象是有弹性分布式数据集(RDD),以及基本上分布的不可改变集合,可以基于本地文件定义后通过HDFS存储在Hadoop中,并提供诸如Scala风格的map foreach等函数操作。

  给人的第一反应是“等等,这是基本的分布式集合吗?”Hadoop可比这多得多,分布式文件系统,特别是Map Reduce,支持各种数据格式,数据来源,单元测试,集群变种的支持等等。

  当然Spark也支持更复杂的操作如joins, group-by, 或reduce-by 操作,可以建模复杂的数据流。

  随着时间的推移,开始明白了Spark的简约是针对Hadoop的Java API。在Hadoop中即使最简单你的案例也有不少代码。但是从概念上说,Hadoop是很简单的,因为它仅提供了两个基本的操作,并行的mao和一个reduce操作。如果在对一些类似的分布式集合以同样的方式表达,其实只有一个更小的接口(如Scalding的一些项目实际构建这样的事情,代码看起来与SPark非常相似)。

  为了说服自己,作者继续研究,发现Spark实际提供了一个不平凡的操作集 ,RDD是Spark的基本构建块,类似分布的不可变集合。象map湖泊foreach等操作很容易并行操作,而且实现两个RDD和集合的基于一个共同Key的Join操作。也能基于一个Key使用用户定义的功能实现聚合reduce操作。

  在字数统计的例子,你能map一段文本的所有文字,然后通过单词reduce他们,最后总结出单词的个数。RDD能够从磁盘读取然后保持在内存中,提高了性能,这和Hadoop大部分基于磁盘的速度要快多。

  有趣的是Spark容错方式。取代持久或检查点中间结果,Spark记住导致某个数据集的操作顺序(banq注:类似EventSourcing,记住导致状态的系列事件)。因此,当一个节点出现故障时,Spark会重建基于存储的数据集。他们认为,这其实并不坏,因为其他节点将帮助重建。因此,在本质上,相对于基本原始的Hadoop,Spark具有更小的接口(其中仍可能成为未来同样臃肿),但也有很多项目在Hadoop之上(比如 Twitter的Scalding,),它实现了一个类似的水平表现力。其它主要区别在于,Spark是默认情况下在内存,这自然导致了性能改善,并且甚至允许运行的迭代算法。Spark没有内置的迭代支持,不过,这只是他们声称它是如此之快,你可以运行迭代,如果你想

  Spark还带有一个数据流处理模式,这是一个文件,该文件概述了设计是相当不错。Spark因此与 Twitter的Storm框架不同之处。Storm基本上是一个管道,你推入独立的事件,然后得到以分布式方式的处理结果。相反,Spark那里事件是收集的,然后在很短的时间间隔内(假设每5秒)以批处理方式处理。所收集的数据成为自己一个RDD,然后使用通常的一套Spark应用进行处理。

  这种模式是对慢节点和容错更健壮,同时又有5秒的时间间隔通常是足够快于大多数应用。我不是很确定这一点,因为分布式计算总是非常复杂的,这种方法使用非实时流部分很好地统一了实时流处理,这当然是正确的。

  由于RDD的不可变性,如果你需要对一些数据项目进行少量改变,你得自己做一个整个数据集的拷贝,这可以使用并行完成,但是当然也是有成本的,基于Copy-on-write的实现也许在这里更有效,但是如今还没有实现。

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