Apache基金会下的Spark再次引爆了大数据的话题。带着比Hadoop MapReduce速度要快100倍的承诺以及更加灵活方便的API，一些人认为这或许预示着Hadoop MapReduce的终结。

作为一个开源的数据处，Spark是如何做到如此迅速地处理数据的呢?秘密就在于它是运行在集群的内存上的，而且不受限于MapReduce的二阶段范式。这大大加快了重复访问同一数据的速度。

Spark既可以单独运行，也可以运行在Hadoop YARN上(注：Hadoop第二代框架中的改进框架，用于将资源管理和处理组件分开，基于YARN的结构不受MapReduce约束)，此时Spark可以直接从HDFS(Hadoop Distributed File System分布式文件系统)中读取数据。诸如Yahoo(雅虎)、Intel(因特尔)、Baidu(百度)、Trend Micro(趋势科技)和Groupon(高朋)等公司已经在使用Spark了。

听上去好像Spark已经注定要取代Hadoop MapReduce了。但真的是这样吗?本文我们将对比这两个平台来看看是否Spark真的技高一筹。

性能

Spark在内存中处理数据，而Hadoop MapReduce是通过map和reduce操作在磁盘中处理数据。因此从这个角度上讲Spark的性能应该是超过Hadoop MapReduce的。

然而，既然在内存中处理，Spark就需要很大的内存容量。就像一个标准的数据库系统操作一样，Spark每次将处理过程加载到内存之中，然后该操作作为缓存一直保持在内存中直到下一步操作。如果Spark与其它资源需求型服务一同运行在Hadoop YARN上，又或者数据块太大以至于不能完全读入内存，此时Spark的性能就会有很大的降低。

与此相反，MapReduce会在一个工作完成的时候立即结束该进程，因此它可以很容易的和其它服务共同运行而不会产生明显的性能降低。

当涉及需要重复读取同样的数据进行迭代式计算的时候，Spark有着自身优势。但是当涉及单次读取、类似ETL(抽取、转换、加载)操作的任务，比如数据转化、数据整合等时，MapReduce绝对是不二之选，因为它就是为此而生的。

小结：当数据大小适于读入内存，尤其是在专用集群上时，Spark表现更好;Hadoop MapReduce适用于那些数据不能全部读入内存的情况，同时它还可以与其它服务同时运行。

使用难度

Spark有着灵活方便的Java，Scala和Python的API，同时对已经熟悉SQL的技术员工来说，Spark还适用Spark SQL(也就是之前被人熟知的 Shark)。多亏了Spark提供的简单易用的构造模块，我们可以很容易的编写自定义函数。它甚至还囊括了可以即时反馈的交互式命令模式。

Hadoop MapReduce是用Java编写的，但由于其难于编程而备受诟病。尽管需要一定时间去学习语法，Pig还是在一定程度上简化了这个过程，Hive也为平台提供了SQL的兼容。一些Hadoop工具也可以无需编程直接运行MapReduce任务。Xplenty就是一个基于Hadoop的数据整合服务，而且也不需要进行任何编程和部署。

尽管Hive提供了命令行接口，但MapReduce并没有交互式模式。诸如Impala，Presto和Tez等项目都在尝试希望为Hadoop提供全交互式查询模式。

安装与维护方面，Spark并不绑定在Hadoop上，虽然在Hortonworks(HDP 2.2 版) 和Cloudera(CDH 5 版)的产品中Spark和Hadoop MapReduce都包含在其分布式系统中。(注：Cloudera，Hortonworks及MapR是Hadoop领域三大知名的初创公司，致力于打造更好的Hadoop企业版应用)。

小结：Spark更易于编程，同时也包含交互式模式;Hadoop MapReduce不易编程但是现有的很多工具使其更易于使用。

成本

Spark和Hadoop MapReduce都是开源的，但是机器和人工的花费仍是不可避免的。

这两个框架既可以在商用服务器上也可以运行在云端，下表可以看到它们有着相似的硬件需求：

框架Apache Spark Apache Hadoop balanced workload slaves内核8–16 4内存 8 GB到数百GB 24GB硬盘4–8 4–6 1TB网络10GB或更多1GB以太网

Spark集群的内存至少要和需要处理的数据块一样大，因为只有数据块和内存大小合适才能发挥出其最优的性能。所以如果真的需要处理非常大的数据，Hadoop绝对是合适之选，毕竟硬盘的费用要远远低于内存的费用。

考虑到Spark的性能标准，在执行相同的任务的时候，需要的硬件更少而运行速度却更快，因此应该是更合算的，尤其是在云端的时候，此时只需要即用即付。

在技术人员方面，即使Hadoop从2005年就开始普及，但是MapReduce方面的专家仍然存在着短缺。而对于从2010年才开始普及的Spark，这又意味着什么呢?或许投身Spark学习的人正在快速增加，但是相比于Hadoop MapReduce仍然存在着更大的技术人才的缺口。

进一步讲，现存了大量的Hadoop即服务的资料和基于Hadoop的服务(比如我们Xplenty的数据整合服务)，这些都降低对技术人员能力和底层硬件知识的要求。相比之下，几乎没有现有可选的Spark服务，仅有的那些也是新产品。

小结：根据基准要求，Spark更加合算，尽管人工成本会很高。依靠着更多熟练的技术人员和Hadoop即服务的供给，Hadoop MapReduce可能更便宜。

兼容性

Spark既可以单独运行，也可以在Hadoop YARN上，或者在预置Mesos上以及云端。它支持实现Hadoop输入范式的数据源，所以可以整合所有Hadoop支持的数据源和文件格式。根据Spark官方教程，它还可以通过JDBC和ODBC同BI(商业智能)工具一起运行。Hive和Pig也在逐步实现这样的功能。

小结：Spark和Hadoop MapReduce具有相同的数据类型和数据源的兼容性。

数据处理

除了平常的数据处理，Spark可以做的远不止这点：它还可以处理图和利用现有的机器学习库。高性能也使得Spark在实时处理上的表现和批处理上的表现一样好。这也催生了一个更好的机遇，那就是用一个平台解决所有问题而不是只能根据任务选取不同的平台，毕竟所有的平台都需要学习和维护。

Hadoop MapReduce在批处理上表现卓越。如果需要进行实时处理，可以利用另外的平台比如Storm或者Impala，而图处理则可以用Giraph。MapReduce过去是用Mahout做机器学习的，但其负责人已经将其抛弃转而支持Spark和h2o(机器学习引擎)。

小结：Spark是数据处理的瑞士军刀;Hadoop MapReduce是批处理的突击刀。

容错

和MapReduce一样，Spark会重试每个任务并进行预测执行。然而，MapReduce是依赖于硬盘驱动器的，所以如果一项处理中途失败，它可以从失败处继续执行，而Spark则必须从头开始执行，所以MapReduce这样节省了时间。

小结：Spark和Hadoop MapReduce都有着较好的容错能力，但是Hadoop MapReduce要稍微更好一点。

安全性

在安全性上，此时的Spark还略显不足。授权验证由共享秘钥机制支持，网络用户接口则通过servlet过滤器和事件日志保护。Spark可以运行在YARN上并配合使用 HDFS，这也就意味着它同时还拥有Kerberos认证授权验证，HDFS文件许可机制和节点间的加密机制。

Hadoop MapReduce拥有所有Hadoop支持的安全机制，同时也整合了其它基于Hadoop的安全项目，比如Knox网关和Sentry。志在解决Hadoop安全的Rhino项目也只是在添加Sentry支持时添加了Spark支持。否则Spark开发者们只能自己去提升其安全性了。

小结：Spark的安全机制仍处在发展期。Hadoop MapReduce拥有更多安全控制机制和项目。

总结

Spark是大数据领域冉冉升起的新星，但是Hadoop MapReduce仍有着较广的应用领域。

在内存中进行数据处理使得Spark具有较好的性能表现，也比较高效合算。它兼容所有Hadoop的数据源和文件格式，支持多种语言的简单易用的API也使人们更快速的可以上手。Spark甚至实现了图处理和机器学习工具。

Hadoop MapReduce是一个更加成熟的平台，为进行批处理而生。当遇到确实非常大的数据以至于无法完全读入内存，又或是依靠着大量对该平台有经验的技术人员，它可能会比Spark更加合算。而且围绕Hadoop MapReduce的衍生系统正在依靠着更多的支撑项目、工具和云服务而更加壮大。

但是即使看上去Spark像是最终的赢家，问题在于我们永远不会单独使用它—我们需要HDFS存储数据，或许还会需要用到HBase，Hive，Pig，Impala或其他Hadoop项目。这意味着在处理非常大的数据的时候，Spark仍然需要同Hadoop和MapReduce共同运行。

来源：极分享