Spark与MapReduce之争：谁更适合于企业级IT？

新兴的Spark技术有望取代大数据框架中广泛应用的MapReduce技术。这种替代的速度如何，其范围和规模又是怎样的呢？

让我们先说说MapReduce。它的确好用，但是现在大数据开发人员对速度和简洁性的需求变得越来越强烈。所以当面临选择Hadoop 平台上运行的处理框架，以应对新的工作负载时，他们越来越倾向于新兴的框架技术Spark。

至少这是从大数据厂商那里获取到的信息，他们在大力支持Apache Spark，称其为大数据的下一个大事件。

在旧金山6月举行的Spark峰会上，Cloudera首席战略官Mike Olson谈到了Spark正以“惊人”的速度增长，以及客户偏好的明显转变，该公司作为Hadoop分销商，亲眼见证了这些变化。

“我们觉得不用多久Spark能够成为占主导地位的Hadoop通用处理框架，”他说。”那时候，如果你想要找到一个好用、通用的引擎，你会选择Apache Spark，而不是Apache MapReduce。”

Olson的话用词十分准确，特别是“通用”这个词的使用。他的观点是，虽然对于Hadoop专用处理引擎来说发展空间还很大，例如用于搜索的Apache Solr或用于SQL的查询Cloudera Impala，但是，能够让开发者用来创建多样化的分析工作负载(因此称为“通用”)的处理框架竞争，好似两匹赛马之间的竞争，而Spark胜利在望。

其实Spark能赢原因很简单，它找到了那些MapReduce框架被开发人员长期诟病的地方，尤其是MapReduce的高延迟及批处理响应的模式。

“人们在很长时间内已经达成了共识--MapReduce在Hadoop的世界中是一个很好的工作工具，”Arun Murthy--Hortonworks公司创始人兼架构师说道。

他指出，该技术是谷歌实验室创造的，用来解决一个非常具体的用例:web搜索。十年以来,它历经演变——但或许仍不足以满足企业对大数据应用程序的要求。

“它的优势在于其良好的可延展性，能够应付更多用例,” Murthy补充道。“我们当然知道MapReduce存在可以解决问题的用力,但却不是以最优的方式。如同当初MapReduce取代其他技术一样,技术间的更替是完全自然的,新技术的出现也将取代MapReduce。”

Spark的速度与简洁性

那么Spark的伟大之处在什么地方呢?它对于开发人员来说最主要优点就是速度。据该技术的发明者Mathei Zaharia所述，Spark应用程序比那些基于MapReduce的应用程序快上一个数量级 –最高能快上100倍。Mathei Zaharia现在是Databricks公司的首席技术官，该公司提供基于云的Spark程序，这些程序并没有运行在Hadoop平台上，而是运行在Cassandra 数据库上。

值得注意的是,Spark可以运行在不同的文件系统和数据库中,其中也包括Hadoop分布式文件系统,(HFDS)。

Spark相对于MapReduce的优势在于它在内存在完成了大部分操作的处理, 它把数据集从分布式物理存储复制到更快的逻辑内存中。相比之下,MapReduce是从硬盘写入和读取数据的。磁盘访问1MB数据的速度以毫秒为单位，而内存中访问同样大小的数据只需要亚毫秒级的时间。换句话说,Spark可以给企业带来明显的时间优势。

Gartner分析师Nick Heudecker说道:“我最近跟一个使用大规模Hadoop集群的客户说,尝试使用一下Spark,它能够把工作从四个小时(使用MapReduce)降低至90秒(使用Spark)。”

对于许多企业来说,这种改进是极具吸引力的,Heudecker说道。“这意味着，在之前他们只能在一天内完成两次分析，而用了Spark后，现在要进行多少分析都轻而易举。”

今年6月的Spark 峰会上，美国丰田汽车销售公司的数据科学主管Brian Kursar,介绍了他的团队如何使用Spark运行客户体验分析程序后所带来的改进。这些程序平时要处理大约7亿条记录，这些记录来自社会媒体,调查数据和呼叫中心业务,运行程序的目的为了找出客户流失问题的原因以及识别需要关注的领域,以便员工能在必要时进行干预。

使用MapReduce,完成分析需要160小时。也就是几乎七天时间，Kursar指出。“届时,再改变就有点太晚了,”他说。相同的处理工作,使用Spark重写，将会在四小时内完成。

Spark相对于MapReduce的另一个优势是其具有更优秀的易用性和灵活性。这不足为奇,Spark是Mathei Zaharia在加州大学伯克利分校攻读博士学位时发明的，目的是为了解决他在MapReduce框架中受到的种种限制，而这些限制是其在MapReduce早期用户-Facebook实习时发现的。

“我在这些企业中看到，其用户想要使用大数据做更多事情，而MapReduce所提供的功能远远不能满足他们的需要,”他说。“它有很大的局限性,例如不能做互动查询，不能处理先进算法,如机器学习等。这些缺陷令人沮丧,所以我的目标是解决这些问题,与此同时,我想让用户更容易的使用大数据并从中获取价值。”

大多数用户认为Spark对于开发者来说更加友好,包括丰田的Kursar,他说道:“Spark的API比起MapReduce来说，明显更容易使用。”

Cloudera优秀开发者Justin Kestelyn最近发表了一篇博客，表示Spark具有“丰富，表示清晰的API，和Scala ,Java和Python的API不相上下，相比MapReduce，使用Spark几乎可以减少两倍到五倍的代码量,。

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

这些工具包括Spark SQL,用于结构化关系数据上进行分析查询，Spark Streaming;通过使用频繁的micro-batches来进行几乎实时的数据流处理；MLib工具:用于机器学习；GrapX用于表示,图表,以及数据在任意方面的联系,例如网络社交媒体的用户。

Spark为时尚早？

然而，使用Spark也面临着巨大障碍，原因在于Spark是相对不成熟的。金融服务公司Northern Trust首席架构师Len Hardy的团队是Cloudera Hadoop分布平台的忠实用户，他们在其上运用各种工具，包括Hive(数据仓库),Flume(大规模日志聚合)和Cloudera Impala(运行SQL查询)。

但现在，Hardy 是在生产环境中没有使用Spark。“我们现在离Spark还很远,”他说。“这是一个关于成熟度的问题。这项技术有很大的前景,我们也将使用它,毫无疑问,我们已经准备好在一些已被验证的领域使用它了。

“但是，对于我们的企业数据平台来说，应用spark可能还需要很长时间,我们向合作伙伴和客户提供数据，他们据此做出商业决策,为了保证数据的准确性，我们需要所使用的工具坚如磐石，我只是觉得Spark在成熟度上还差那么一点。”

谨慎是有道理的。所有主要的Hadoop厂商,正在努力提高他们企业支持Spark的能力,但Gartner的Heudecker指出:“Spark的商业支持似乎总是与其他数据管理产品捆绑,但信息经理和业务分析人员必须意识到，Spark的发展速度让厂商不断支持最新组件版本的服务面临着巨大挑战。”

API和最优化方法在很大程度上仍处于发展中,Heudecker补充道,另外厂商在同样Spark框架中，可能难以支持所有的可用组件。企业用户应极其谨慎，不要把关键任务部署在不支持或部分支持的功能上，这将得不偿失。

Cloudera的Olson承认Spark仍然是一种年轻的技术。“这还为时尚早——仍然有大量的工作需要完成，比如安全需求方面,”他说道。

但在Spark峰会的几个月后,他坚持他的意见,在不远的将来,大多数Hadoop上的新的分析应用程序将会构建在Spark而不是MapReduce上。

“使用Spark的Hadoop集群所占的平均市场份额正在提升，超越的临界点迟早会来,”Olson说。“现在,我不能预测这将在何时发生,但我都会告诉我们的一些客户,特别是在金融服务和消费品领域,几乎已经达到临界点。而这些行业的很多人注定要追随这一趋势。”