作者观察到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的实现也许在这里更有效，但是如今还没有实现。
原文链接：http://www.jdon.com/46098
