作为通用的并行处理框架，Spark具有与Hadoop相似的一些优势，Spark采用了更好的内存管理，在迭代计算上比Hadoop更高效。Spark还提供了更广泛的数据集操作类型，极大地方便了用户的开发。Checkpoint的应用使得Spark具有很强的容错能力。许多比Hadoop更优越的性能和更广泛的应用使得Spark的进一步发展值得期待。 ApacheSpark现在很有名了。为支持Spark项目而成立的公司Databricks从AndereessenHorowitz筹集了1400万美元，Cloudera已决定全力支持Spark，还有许多其他公司正在积极加入该活动。所以我想这是我应该认真审视这种不安的时候了。 学习了一段时间的ScalaAPI（Scala写的Spark），说实话，一开始我很失望，因为Spark看起来真的很不起眼。基本抽象是弹性分布式数据集（ResilientDistributedDatasets，RDD）和基本的分布式不可变集，可以基于本地文件或通过HDFS存储在Hadoop上的文件来定义，提供常见的Scala风格的集合操作（??如mapping、foreach等）。 我的***反应是“没错，这真的是一个基本的分布式集合吗？”。相比之下，Hadoop就丰富多了：分布式文件系统，著名的MapReduce，支持所有类型的数据格式，数据源，单元测试，集群变量等等。 ，事实上Spark还提供了更复杂的操作（例如join、groupbyoperation或reduce），以便您可以对相当复杂的数据流进行建模（尽管无需迭代）。 久而久之我才明白，Spark所谓的简单主要是Hadoop中的JavaAPI，而不是Spark本身。即使是简单的示例在Hadoop中也经常有很多样板代码。但从概念上讲，Hadoop非常简单，它只提供两种基本操作：并行映射（Map）和缩减（Reduce）操作。如果你用同样的方式来表示类似的分布式集合，你实际上会有一个更小的接口（一些项目像Scalding处理类似的事情，代码看起来很像Spark）。 Spark实际上提供了一组重要的操作，在说服我这一点之后，我深入研究了这篇描述一般架构的论文。RDD是Spark的基本构建块，实际上很像分布式不可变集。这些定义操作（例如map或foreach），很容易并行处理；还有连接操作，它采用两个RDD并根据公共键收集条目；并根据操作规范，按用户指定的函数，根据键聚合条目。在字数统计的例子中，countingonce将文本映射到所有的词上，然后通过key减少它们来实现字数统计。RDDs可以从磁盘读取并保存在内存中以提高速度，它们也可以被缓存，这样你就不需要每次都重新读取它们。仅此一项就比Hadoop快很多，主要基于磁盘速度。 容错机制也是Spark的亮点之一。Spark不是持久化或检查中间结果，而是记住产生某些数据集的操作序列。因此，当某个节点发生故障时，Spark会根据存储的信息重建数据集。他们认为这很好，因为其他节点会帮助重建。 因此，从本质上讲，Spark的界面比纯Hadoop更小（将来可能会膨胀），但是有许多基于它的项目（例如Twitter的Scalding）实现了类似的性能水平。另一个主要区别是Spark默认情况下是内存中的，这自然会带来性能的大幅提升，甚至允许运行迭代算法。虽然Spark没有内置对迭代的支持，正如他们声称的那样：只要你愿意，它可以快到你可以迭代。 SparkStreaming-微批处理的回归 Spark还带有流式数据处理模型，这当然让我很感兴趣。还有一篇论文对设计进行了精美的总结。与Twitter的Storm框架相比，Spark采用了一种有趣且独特的方法。Storm基本上就像是连接独立事务的管道，事务在其中进行分布式处理。相反，Spark采用一种模型来收集事务，然后在短时间内（假设为5秒）批量处理事件。收集的数据成为它们自己的RDD，然后使用Spark应用程序中常用的集合对其进行处理。 作者声称此模式对慢速节点和故障更稳健，并且5秒间隔对于大多数应用程序通常足够快。我对此不太确定，因为分布式计算总是很复杂，我不相信你可以说有些东西比其他东西好。的确，这种方法也很好地统一了流媒体和非流媒体部分。 结束语 Spark在我看来还是很有前途的。有了对Spark的支持和关注，我坚信它会走向成熟，在这个领域发挥更重要的作用。当然，它可能并不适合所有场景，正如作者所承认的那样，基于RDD稳定性而只更改少数条目的操作并不适合。原则上，您必须备份整个数据集，即使您只想更改一个条目。这很好地并行化，但是很昂贵。写时复制在这里可能更有效，但尚未实现。 顶层是柏林工业大学的一个研究项目，目标相似，但是开发了更复杂的操作，例如迭代，不仅要存储一系列操作以实现容错，还要对它们进行全局调度优化和并行化。
