笔者观察到ApacheSpark最近发布了一些异常事件。Databricks将提供1400万来支持Spark。Cloudera已决定支持Spark。Spark被认为是大数据领域的一件大事。不错的第一印象作者认为自己已经使用Scala的API（Spark是用Scala编写的）有一段时间了，老实说，一开始印象非常深刻，因为Spark看起来很小很漂亮。基本抽象是弹性分布式数据集（RDD），基本是分布式不可变集合，可以基于本地文件定义，通过HDFS存储在Hadoop中，提供Scala风格的mapforeach等功能操作。第一反应是“等等，这是一个基本的分布式集合吗？”Hadoop远不止于此，分布式文件系统，尤其是MapReduce，支持各种数据格式、数据源、单元测试、对集群变体的支持等等。当然，Spark还支持更复杂的操作，例如join、group-by或reduce-by操作，这些操作可以对复杂的数据流进行建模。随着时间的推移，很明显Spark的简单性是Hadoop的JavaAPI。即使是最简单的案例也是Hadoop中的大量代码。但从概念上讲，Hadoop非常简单，因为它只提供两个基本操作，并行MAO和一个reduce操作。如果对一些类似的分布式集合用同样的方式表达的话，其实只有一个更小的接口（有些项目比如Scalding其实就是构建这样的东西，代码看起来很像Spark）。为了说服自己，笔者继续研究，发现Spark其实提供了一套非平凡的操作。RDD是Spark的基本构建块，Spark是一个类似于分布的不可变集合。maplakeforeach等操作易于并行操作，实现两个RDD和集合基于公共Key的Join操作。也可以使用用户定义的函数基于键实现聚合归约操作。在字数统计的例子中，可以将一段文本中所有的词进行映射，然后逐字归约，最后对词数求和。RDD可以从磁盘读取，然后保存在内存中，提高性能，这比大多数基于磁盘的Hadoop快得多。有趣的是Spark的容错方式。Spark不会记住导致特定数据集的操作序列，而不是持久性或检查点中间结果（注：类似于EventSourcing，记住导致状态的事件序列）。因此，当一个节点发生故障时，Spark会重建基于存储的数据集。他们认为，这实际上还不错，因为其他节点将有助于重建。所以，本质上，与基本的原始Hadoop相比，Spark具有更小的接口（未来可能仍然会变得同样臃肿），但也有许多在Hadoop之上的项目（例如Twitter的Scalding），它们实现了类似级别的表现力。另一个主要区别是Spark默认情况下在内存中，这自然会提高性能，甚至允许运行迭代算法。Spark没有内置的迭代支持，不过，这正是他们声称的如此之快，你可以运行迭代，如果你希望Spark也带有数据流处理模式，这里有一个概述设计的文档非常好。因此，Spark不同于Twitter的Storm框架。Storm基本上是一个管道，您可以在其中推送单个事件并以分布式方式获取处理结果。相反，Spark收集事件，然后以非常短的时间间隔（假设每5秒一次）批量处理。收集的数据本身成为一个RDD，然后使用一组常用的Spark应用程序对其进行处理。这种模式对慢速节点和容错更稳健，而5秒间隔对于大多数应用程序通常足够快。我对此不太确定，因为分布式计算总是非常复杂，并且这种方法将实时流处理与非实时流部分很好地统一起来，这当然是正确的。由于RDD的不可变性，如果你需要对某些数据项进行微小的更改，你必须自己复制整个数据集。这可以并行完成，但当然是有代价的。基于写时复制的实现可能在这里更有效，但现在还没有实现。原文链接：http://www.jdon.com/46098
