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