Hadoop MapReduce虽然已经可以满足大数据的应用场景,但是其执行速度和编程复杂度并不让人们满意。于是UC Berkeley的AMP Lab推出的Spark应运而生,Spark拥有更快的执行速度和更友好的编程介面,在推出后短短两年就迅速抢占MapReduce的市场份额,成为主流的大数据计算框架。
不知道你意识到没有,我在这段开头说的,「Hadoop MapReduce虽然已经可以满足大数据的应用场景,但是其执行速度和编程复杂度并不让人们满意」,这句话其实是错误的。这样说好像可以让你更加清晰地看到事物发展的因果关系,同时也可以暗示别人自己有洞察事物发展规律的能力。然而,这种靠事后分析的因果规律常常是错误的,往往把结果当作了原因。
事实上,在Spark出现之前,我们并没有对MapReduce的执行速度不满,我们觉得大数据嘛、分散式计算嘛,这样的速度也还可以啦。至于编程复杂度也是一样,一方面Hive、Mahout这些工具将常用的MapReduce编程封装起来了;另一方面,MapReduce已经将分散式编程极大地简化了,当时人们并没有太多不满。
真实的情况是,人们在Spark出现之后,才开始对MapReduce不满。原来大数据计算速度可以快这么多,编程也可以更简单。而且Spark支持Yarn和HDFS,公司迁移到Spark上的成本很小,于是很快,越来越多的公司用Spark代替MapReduce。也就是说,因为有了Spark,才对MapReduce不满;而不是对MapReduce不满,所以诞生了Spark。真实的因果关系是相反的。
当你去询问人们有什么问题需要解决,有什么需求需要被满足的时候,他们往往自己也不知道自己想要什么,常常言不由衷。但是如果你真正解决了他们的问题,他们就会恍然大悟:啊,这才是我真正想要的,以前那些统统都是「垃圾」,我早就想要这样的东西(功能)了。
所以顶尖的产品大师(问题解决专家),并不会拿著个小本本四处去做需求调研,问人们想要什么。而是在旁边默默观察人们是如何使用产品(解决问题)的,然后思考更好的产品体验(解决问题的办法)是什么。最后当他拿出新的产品设计(解决方案)的时候,人们就会视他为知己:你最懂我的需求(我最懂你的设计)。
说了那么多,我们回到Spark。Spark和MapReduce相比,有更快的执行速度。下图是Spark和MapReduce进行逻辑回归机器学习的性能比较,Spark比MapReduce快100多倍。