为什么不改进MapReduce，而要取代它？

MapReduce的高延迟已经成为Hadoop发展的瓶颈，为当前的MapReduce寻找性能更高的替代品已成为Hadoop社区的一个共识。

MapReduce

有关MapReduce框架，最早要追溯到Google，Google将这个框架与灵活、可扩展性存储结合到一起，用以解决各类数据处理和分析任务。后来Doug Cutting和Mike Cafarella在2005年联合创立了Apache Hadoop时，采用的就是这个架构。

类似的项目，比如Apache Pig和Apache Hive，它们将专门的查询转化成可以运行在多功能MapReduce框架上的任务，同时也继承了MapReduce的可扩展性、容错能力、良好的吞吐能力还有糟糕的延迟，特别是Hive，延迟使其无力应付交互式应用。

关于MapReduce的抱怨使人们对企业数据中心和Hadoop项目的热情渐渐减少，MapReduce延迟太高，批处理模式响应也难以应对大量需要处理分析数据的应用。

Hadoop生态圈需要的是一个比MapReduce更加强大、更加灵活、更具实时性的系统。

Spark

如今MapReduce的主要替代者是Apache Spark。和MapReduce一样，它也是一个多功能引擎，但是Spark设计之初就考虑到运行更多的负载，而且速度更快。

最初的MapReduce通过简单的方式执行任务，但是本身结构严格：处理或者转化（map）；同步（shuffle）；以及在集群中将所有结点的结果整合到一起（reduce）。你必须将问题变成一系列MapReduce任务，然后按照顺序执行这些任务，延迟很高。在前一个任务执行完成之前，任何一个任务都无法开始，运行复杂、多阶段的应用程序很让人头疼。

一种替代方案是让开发者构建有关任务的复杂、多步有向非循环图（DAG），一次执行所有这些图，而不需要一个一个按照顺序来。这个方案避免了MapReduce中麻烦的同步问题，也使得应用程序的构建更加简单。对于DAG引擎的研究，微软在早些时候已经开始了，比如：Dryad，Dryad一直在微软内部使用，针对Bing搜索和其他托管服务。

在Spark中既包含了上述一些思想，也有一些重要的创新，比如：Spark支持跨DAG的内存数据分享，使不同任务可以以非常高的速度处理相同数据。Spark甚至支持循环数据流，这使得它能很好地处理迭代图算法（社交网络分析中常用）、机器学习和流处理，这是通过MapReduce或者其他DAG引擎是很难做到的。

Spark包含了流处理、快速故障还原、语言集成API、优化调度和传输数据等许多高级的功能。内存使用是Spark最引人注目的地方，MapReduce需要经常处理存储在磁盘上的数据，相比之下，Spark可以利用分散在集群中所有节点的大量RAM，它能够智能利用磁盘，解决溢出数据和持久性问题，这使Spark在应对负载时有了巨大的性能优势。

为什么不改进MapReduce，而要取代它？

在过去两年，Hadoop社区对MapReduce做了很多改进，但这些改进大多只是停留在了代码层，软件开发者把这称为原有代码基础上的“技术债务”，这些负债导致在原有基础上的改进只能解决一时的问题，从这个意义上讲，MapReduce实在是已经负债累累。

创建全新的代码库（无技术负债），针对当前和未来可预见的负载进行设计，这个过程相对还比较简单、风险较小。需要考虑的问题是：我们是不是真的有必要创建一个全新的项目？

作为MapReduce的替代品，Spark已经比较发展得比较成熟，拥有来自25个国家超过一百个贡献者，社区非常活跃，实际上已经没有必要去创建一个全新项目。

从长远来看，我们期望减少在MapReduce上的投入，相应增加在新框架上的投入，比如：Impala和Spark，理所当然，运行在该平台上的负载将逐渐转移到新的框架上。Google已经开始将负载从MapReduce转移到Pregel和Dremel上，而FaceBook则将负载转移到Presto上。