摘要：更新、更灵活的Spark技术似乎在大数据架构将取代MapReduce。那么对于企业而言，其更新换代的步伐、范围和规模又如何呢？

MapReduce已经开始在逐步退居二线了。采用MapReduce的企业用户固然能够实现良好的运行，但今天的大数据开发人员们对于处理速度和简单性有着极为强烈的追求。所以，当谈到为新的工作负载选择一款处理框架，以便运行在其Hadoop环境中时，现如今的企业用户开始越来越倾向于采用更新、更灵活的Spark技术。

至少，这是从大数据供应商们那里所传达出来的重大信息，他们现在已经把宝压在了Apache Spark上，并正在将其打造成为紧随大数据之后的下一件大事。

今年六月，在旧金山举办的Spark峰会上，Cloudera公司首席战略官麦克·奥尔森谈到了Spark “惊人”的增长和客户偏好的深刻转变。他说他所在的企业作为一家Hadoop分销商正在见证和经历着这一转变结果。

“很久以前，我们希望Spark技术将成为Hadoop的占主导地位的通用处理架构。”他说。“彼时，如果您企业想有一个良好的，通用用途的引擎，您可以选择Apache Spark，而不是Apache MapReduce。”

奥尔森的谈话显然是经过了仔细斟酌的，特别是他使用了“通用用途”这一短语。他的观点是，尽管对于Hadoop的专有用途处理引擎仍然有足够的空间，如用于搜索的Apache Solr或用于SQL查询的Cloudera Impala，但当前开发人员可以用来创建各种各样的分析工作负载(即“通用用途”)的处理框架可以说是两强相争——而且目前看来Spark正在获胜。

获胜原因很简单，Spark极好的解决了开发人员对于MapReduce的一些长期的诟病——特别是其高延迟性，批处理模式响应。

“很长一段时间以来，MapReduce都是Hadoop领域公认的主力。”，Hortonworks公司的创始人兼架构师Arun Murthy表示说。

他指出，该技术是在谷歌的实验室创建的，以解决一项非常具体的使用案例：网络搜索。十多年来，其已经获得了长足的发展，但也许仍尚不足以满足企业对大数据应用程序的胃口。

“其强大之处在于其具备了足够的延展性，以承担更多的用例。”Murthy补充道。“但是，人们固然已经熟知了MapReduce所能够解决的用例，但却不是以最适宜的方式。正如MapReduce会干扰其他技术一样，新技术的出现也会破坏或取代的MapReduce也是非常自然的。”

处理速度和简单性

那么，Spark的优势究竟在何处呢?它提供的主要优点是能够为开发人员提供很快的处理速度。Spark应用程序的处理速度比那些基于MapReduce的快100倍，根据其创作者Mathei Zaharia介绍。Mathei Zaharia现在是一家负责在云中提供Spark技术的Databricks公司的首席技术官，其不在Hadoop上运行，而是在Cassandra数据库。

需要注意的是，Spark可以运行在多种文件系统和数据库，这一点是相当重要的。其中包括Hadoop分布式文件系统(HFDs)。

赋予Spark较之MapReduce比较优势的原因就在于其能够处理其大部分业务在“内存”中，从分布式物理存储复制数据集到更快的逻辑内存。相比之下，MapReduce则是从硬盘驱动器读写。而磁盘访问可以在毫秒之间访问1MB的数据，内存访问数据则是以亚毫秒的速率。换句话说，Spark能给企业带来重要的洞察时间优势。

Gartner的分析师Nick Heudecker表示说：“我的一位客户最近说，在一个非常大的Hadoop集群，完成一项工作使用MapReduce需要花费四个小时，而使用Spark仅仅只需90秒。”

对于许多企业而言，这方面的改善是非常有吸引力的，Heudecker说。“这意味着他们可以不再一天之内仅仅只能运行2个分析了，只要他们愿意，可以在一个给定的数据集运行尽可能多的分析了。”

在六月份举办的Spark峰会上，丰田汽车美国销售部门数据科学负责人Brian Kursar介绍了他的团队在运行其客户体验分析应用程序方面的改进。该款应用程序是用来处理从社交媒体，调查数据和呼叫中心所收集的约7亿条记录，以便发现客户流失问题，并确定关注特定领域，让员工可以在必要的情况下进行干预。

使用MapReduce，该分析花了160个小时运行。这几乎是七天的时间，Kursar向与会代表们指出。“等到该分析结束，所获得的洞察已经有点太迟了。”他说。而同样的处理工作改用Spark，在短短四小时内就完成了。

Spark较之MapReduce的另一大优势在于其相对易用性和灵活性。这不足为奇，正如Mathei Zaharia在加利福尼亚大学伯克利大学攻读博士学位期间创造Spark时所回应的那样，通过在包括Facebook在内的Hadoop的早期用户那里进行暑期实习工作的过程中，他看到了MapReduce的局限性。

“我在这些企业中所看到的是：用户想要借助大数据做更多的工作，而这远远超出了MapReduce所能支持的范畴。”他说。“它有很多的局限性，它不能进行交互式查询，也不能处理高级的算法，如机器学习。这是一种无奈，所以我的目标是要解决这些问题，同时，我想让用户采用大数据变得更容易，并开始从中获得价值。”

大多数用户认为Spark是开发者更友好的，包括丰田的Kursar。他说：“这款API的使用比MapReduce明显容易得多。”

由Cloudera公司开发者关系负责人Justin Kestelyn最近撰写的博客声称，Spark是对于Java、Scala、Python而言，“富有表现力的”API。较之MapReduce，可以减少两倍到五倍之间的代码量。

但这种易用性并不意味着灵活性被牺牲了，正如Forrester的分析师Mike Gualtieri在今年早些时候发表的一份报告所指出的。他写道，相反，Spark包括了专业的工具，可单独或一起用来构建应用程序。

这些包括Spark SQL，用于结构化的分析查询，关系数据;Spark Streaming，通过频繁的‘微批次’进行近实时的数据流处理;MLib机器学习;和GrapX作为一个图表，数据以任意方式连接，例如社交媒体的用户网络。

然而， Spark的一个显著障碍是其相对不成熟。在金融服务公司北美信托银行，其首席架构师莱恩·哈代的团队是Cloudera的Hadoop发行版的用户中，他们采用了一系列的工具，包括Hive(数据仓库)、Flume(大规模的日志聚合)和Cloudera的Impala(运行SQL查询)。Early days

但是现在，哈代已经开始在生产环境中不再使用Spark了。“我们现在正在开始远离Spark了。”他说。“这是一个关乎成熟度的问题。该技术具有巨大潜力，我们将使用它，这一点毫无疑问 - 而且我们已经在使用它进行一些概念证明了。”

“对于我们的企业数据平台，我们将需要利用企业数据平台将数据传送到合作伙伴和客户，以便他们可以做出商业决策，我们需要的工具是坚如磐石的，我只是感到Spark在这一点上还没有达到我们的要求。”

这种谨慎不是没有必要的。自然，所有主要的Hadoop供应商均争先恐后地加强了他们对Spark的支持，但Gartner 的Heudecker指出：“对Spark的商业支持几乎都是与其他数据管理产品捆绑在一起的，而信息管理人员和业务分析人员必须意识到Spark的发展步伐使得捆绑供应商不断支持最新版本的组件是具有挑战性的。”

API和最佳实践仍然在进展中，Heudecker补充说，而供应商们可能很难在Spark框架内同等支持所有可用的组件。企业用户应该采取非常谨慎的态度，不要在关键任务应用程序上部署不支持或部分支持的功能。

Cloudera的奥尔森承认，Spark仍然是一项很新的技术。“这仍然是使用的早期，例如，在安全方面有很多工作要做。”他说。

但是，在Spark峰会后的几个月，他依然坚持自己的观点：在不远的将来，Hadoop的最新的分析应用程序将建立在Spark 上，而不是基于MapReduce。

“在一般的Hadoop集群占主导地位市场份额的将是Spark，这一转折点迟早会到来的。”奥尔森说。“现在，我不能准确预测这一天何时会到来，但我会说，我们的一些客户，特别是在金融服务和消费品领域已经达到了临界点。许多其他行业也必然要跟随。”