Hadoop 意味着 HDFS、YARN、MapReduce 和许多其他东西。你的意思是 Spark vs MapReduce吗？因为 Spark 在 Hadoop 上/与 Hadoop 一起运行，这才是重点。

使用 Spark 的主要原因是为了速度，这是因为它的执行可以将数据保留在阶段之间的内存中，而不是在 Map 或 Reduce 之后始终保留回 HDFS。这种优势对于迭代计算非常明显，迭代计算具有数十个阶段，每个阶段都涉及相同的数据。这就是事情可能快“100 倍”的地方。对于 MapReduce 设计的简单、一次性的类似 ETL 的作业，它通常不会更快。

使用 Spark 的另一个原因是它比 MapReduce 更好的高级语言。它提供了一个类似于 Scala 的函数式编程视图，这比编写 MapReduce 代码要好得多。（尽管你必须要么使用 Scala，要么为 Spark 采用稍微欠发达的 Java 或 Python API）。Crunch和Cascading已经在 MapReduce 之上提供了类似的抽象，但这仍然是 Spark 很好的领域。

最后，Spark 还为 ML、图形分析和流式传输提供了一个还很年轻但很有前途的子项目，它们公开了一个类似的、连贯的 API。使用 MapReduce，您将不得不为此转向几个不同的其他项目（Mahout、Giraph、Storm）。很高兴将它放在一个包装中，尽管尚未“烘烤”。

为什么不使用 Spark？转述我自己：

• Spark 主要是 Scala，带有移植的 Java API；MapReduce 可能对基于 Java 的开发人员更友好、更原生
• 现在有比 Spark 更多的 MapReduce 专业知识
• 对于 MapReduce 设计的数据并行、一次性、类似 ETL 的作业，与 Spark 等效项相比，MapReduce 的重量更轻
• Spark 相当成熟，YARN 现在也是如此，但 Spark-on-YARN 仍然很新。两者可能尚未最佳整合。例如，直到最近我不认为 Spark 可以要求 YARN 基于内核数进行分配？也就是说：MapReduce 可能更容易理解、管理和调整

不确定 YARN，但我认为如果数据可以很好地适合计算节点的内存，Spark 与 Hadoop 相比（宣传速度快 100 倍）会产生真正的不同。仅仅因为它避免了硬盘访问。如果数据不适合内存，由于缓冲，仍然会有一些收益。

好信息@Sean Owen。想多加一个。Spark 可能有助于在 Lambda 架构中构建统一的数据管道，同时处理批处理和流处理层，并具有写入公共服务层的能力。在批处理和流处理之间重用逻辑是一个巨大的优势。此外，Spark1.3 中的流式 K-Means 算法是 ML 除了 1.4 中出色的作业监控和流程可视化之外的附加优势。

将Spark 与 MapReduce（Hadoop 的处理框架）进行比较是公平的。在大多数情况下，Spark 的性能可能优于 MapReduce。前者支持内存中数据处理，从而可以将数据处理速度提高 100 倍。因此，如果您需要快速获得洞察力，例如，如果您需要

• 运行客户分析，例如将客户的行为与特定客户群的行为模式进行比较并触发某些操作；
• 管理风险并预测各种可能的情况；
• 实时检测欺诈行为；
• 运行工业大数据分析并预测异常和机器故障。

但是，MapReduce 擅长处理非常大的数据集（如果您对处理所需的时间感到满意）。此外，这是一种更经济的解决方案，因为 MapReduce 从磁盘读取/写入磁盘。而且磁盘通常比内存便宜。