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

对比Hadoop 分析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的研究项目，有类似的目标，然而却通过更为复杂的操作(如迭代)来发展，不仅是为了容错能力存储一系列操作，而且要将它们用于全局调度优化和平行化。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。