MapReduce谢幕，谁将成为最终的接棒者？

【编者按】MapReduce，曾Hadoop的杀手级组件，被广泛运用于海量数据分析场景。然而时过境迁，随着新型资源管理器YARN的发布，Spark等各种计算框架的应用场景增多，即使在离线数据处理中，MapReduce亦不乏可与其匹敌的对手。同时，限于其批处理设计，在实时计算中，MapReduce更显狼狈。着眼未来，谁将成为数据处理最终的通用平台尚不得知，但MapReduce的前景已然堪忧。那么，在MapReduce谢幕后，谁又能成为真正的接棒者，近日Andrew J. Brust在Gigaom进行了简要分析。

以下为译文：

Hadoop的早期应用以及初次被人们注意都离不开MapReduce，当初，MapReduce是令人敬佩的大数据处理算法。然而时至近日，局势已经发生了明显的变化。随着Hadoop 2.0的发布，MapReduce开始为新技术让步。那么，纵观全局，谁又会成为下一个接棒者？

大数据历史中的MapReduce

初期的MapReduce算法基本是根植于Hadoop核心集群管理设施，大数据先锋们在享受其便利的同时，还必须忍受MapReduce的众多缺点。起先，MapReduce与Hadoop的深度集成也并无不合理之处，因为MapReduce足够强大，可以将数据与查询工作拆分到集群中的多个服务器，并促进机器间的协作，然后得到结果。

然而，这套原理背后存在的问题也显而易见：需要连续、快速的执行多个短查询时，MapReduce的批处理机制并不能对任务进行截取，然后并发执行。Hadoop 2.0引进了YARN作为集群管理层的独立算法，它可以执行MapReduce任务，也可以容纳其他的引擎任务。

Spark的出现

在YARN发展的同时，AMPLab开发了一款基于内存的分布式处理引擎——Spark。Spark可以在Hadoop集群中运行，通过使用内存而非硬盘避免了MapReduce的批处理问题。重要的是，经Hartonworks证实，Spark已具备“YARN Ready”特性。

到目前为止，一切进展都很顺利，YARN提供了一个通用框架，用于批处理与交互引擎在Hadoop集群中处理数据；而Spark作为一种流计算引擎，可利用内存快速处理某些工作负载。

然而其他的Hadoop组件也不容忽视，像是SQL查询层Hive或者数据转换脚本环境Pig，这种依赖于MapRedeuce的组件该如何处理？要如何利用Hadoop的架构转变来改造这些组件呢？

升级

Hortonworks，牵头做YARN的公司，在YARN之外，还创建了一个夹在Hive和Pig之间的组件Tez。Hortonworks将Tez的源代码作为Hive的升级版加进了Apache软件基金会的源码中。

在最新的Hive和Hadoop版本中，用户就可以使用它们的交互性进行迭代查询工作。与此同时，一个包括Cloudera和MapR的行业协会宣布将改进Hive和Pig，以及其他的Hadoop分布式组件，使它们可以直接执行。

共生的敌人

Spark和Tez，两个原本没有什么可比之处的产品，由于受到MapReduce退出及Hadoop主流趋势的影响，突然变成了竞争对手，消费者们应该警惕他们竞争将带来的分裂风险。

内存引擎在一些负载工作中确实能很好地工作，但是让内存引擎来默认执行大部分工作，特别是那些需要PB级（或更高）数据量的工作，似乎很不专业。

面向批处理的MapReduce并非针对企业级设计，YARN、Tez和Spark也都出现了亟待解决的缺陷。讽刺的是，基于相同Hadoop分布式组件上的多种使用方法，却都不是特别适用于企业。

引擎，合并？

如果YARN的开放式架构能够支持多个相似而且重叠的解决方案，那么我们将需要一个针对给定查询的优选程序，让客户更简单的操作。有选择是件好事，但分裂并复杂的选择却并不是件好事。

在20世纪80年代，Unix操作系统出现了严重分裂，并因此阻碍了该操作系统的市场扩展。近些年，Hadoop已经成为了一个数据操作系统，希望它不会重蹈Unix覆辙。

原文链接：http://gigaom.com/2014/07/20/spark-and-tez-out-of-phase/