一、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