《Spark亚太研究院系列丛书——Spark实战高手之路 从零开始》本书通过Spark的shell测试Spark的工作；使用Spark的cache机制观察一下效率的提升构建Spark的IDE开发环境；通过Spark的IDE搭建Spark开发环境；测试Spark IDE开发环境等等。本节为大家介绍MapReduce已死，Spark称霸。

AD：51CTO 网+ 第十二期沙龙：大话数据之美_如何用数据驱动用户体验

一、MapReduce已死，Spark称霸

由于Hadoop的MapReduce高延迟的死穴，导致Hadoop无力处理很多对时间有要求的场景，人们对其批评越来越多，Hadoop无力改变现在而导致正在死亡。正如任何领域一样，死亡是一个过程，Hadoop正在示例这样的一个过程，Hadoop的死亡过程在2012年已经开始

1，原先支持Hadoop的四大商业机构纷纷宣布支持Spark；

2，Mahout前一阶段表示从现在起他们将不再接受任何形式的以MapReduce形式实现的算法，另外一方面，Mahout宣布新的算法基于Spark；

3，Cloudera的机器学习框架Oryx的执行引擎也将由Hadoop的MapReduce替换成Spark；

4，Google已经开始将负载从MapReduce转移到Pregel和Dremel上；

5，FaceBook则将负载转移到Presto上；

现在很多原来使用深度使用Hadoop的公司都在纷纷转向Spark，国内的淘宝是典型的案例。在此，我们以使用世界上使用Hadoop最典型的公司Yahoo！为例，大家可以看一下其数据处理的架构图：
 

而使用Spark后的架构如下：
 

大家可以看出，现阶段的Yahoo！是使用Hadoop和Spark并存的架构，而随着时间的推进和Spark本身流处理、图技术、机器学习、NoSQL查询的出色特性，最终Yahoo！可能会完成Spark全面取代Hadoop，而这也代表了所有做云计算大数据公司的趋势。

或许有朋友会问，Hadoop为何不改进自己？

其实，Hadoop社区一直在改进Hadoop本身，但事实是无力回天：

1，Hadoop的改进基本停留在代码层次，也就是修修补补的事情，这就导致了Hadoop现在具有深度的“技术债务”，负载累累；

2，Hadoop本身的计算模型决定了Hadoop上的所有工作都要转化成Map、Shuffle和Reduce等核心阶段，由于每次计算都要从磁盘读或者写数据，同时真个计算模型需要网络传输，这就导致了越来越不能忍受的延迟性，同时在前一个任务运行完之前，任何一个任务都不可以运行，这直接导致了其无力支持交互式应用；

那么，为什么不全部重新写一个更好的Hadoop呢?答案是Spark的出现使得没有必要这样做了。

Spark是继Hadoop之后，成为替代Hadoop的下一代云计算大数据核心技术，目前SPARK已经构建了自己的整个大数据处理生态系统，如流处理、图技术、机器学习、NoSQL查询等方面都有自己的技术，并且是Apache顶级Project，可以预计的是2014年下半年到2015年在社区和商业应用上会有爆发式的增长。

国外一些大型互联网公司已经部署了Spark。甚至连Hadoop的早期主要贡献者Yahoo现在也在多个项目中部署使用Spark；国内的淘宝、优酷土豆、网易、Baidu、腾讯等已经使用Spark技术用于自己的商业生产系统中，国内外的应用开始越来越广泛。Spark正在逐渐走向成熟，并在这个领域扮演更加重要的角色。
 

喜欢的朋友可以添加我们的微信账号：

51CTO读书频道二维码

51CTO读书频道活动讨论群：342347198