【前言：笔者将分两篇文章进行阐述Spark和MapReduce的对比，首篇侧重于"宏观"上的对比，更多的是笔者总结的针对"相对于MapReduce我们为什么选择Spark"之类的问题的几个核心归纳点；次篇则从任务处理级别运用的并行机制方面上对比，更多的是让大家对Spark为什么比MapReduce快有一个更深、更全面的认识。通过两篇文章的解读，希望帮助大家对Spark和MapReduce有一个更深入的了解，并且能够在遇到诸如"MapReduce相对于Spark的局限性？"等类似的面试题时能够得到较好地表现，顺利拿下offer】

首先纠正一个误区：在浏览Spark官网时，经常能看到如下这张图：

从上图可以看出Spark的运行速度明显比Hadoop（其实是跟MapReduce计算引擎对比）快上百倍！相信很多人在初学Spark时，认为Spark比MapReduce快的第一直观概念都是由此而来，甚至笔者发现网上有些资料更是直接照搬这个对比，给初学者造成一个很严重的误区。

这张图是分别使用Spark和Hadoop运行逻辑回归机器学习算法的运行时间比较，那么能代表Spark运行任何类型的任务在相同的条件下都能得到这个对比结果吗？很显然是不对的，对于这个对比我们要知其然更要知其所以然。

首先，大多数机器学习算法的核心是什么？就是对同一份数据在训练模型时，进行不断的迭代、调参然后形成一个相对优的模型。而Spark作为一个基于内存迭代式大数据计算引擎很适合这样的场景，之前的文章《Spark RDD详解》也有介绍，对于相同的数据集，我们是可以在第一次访问它之后，将数据集加载到内存，后续的访问直接从内存中取即可。但是MapReduce由于运行时中间结果必然刷磁盘等因素，导致不适合机器学习等的迭代场景应用，还有就是HDFS本身也有缓存功能，官方的对比极有可能在运行逻辑回归时没有很好配置该缓存功能，否则性能差距也不至于这么大。

相对于MapReduce，我们为什么选择Spark，笔者做了如下总结：

Spark

1.集流批处理、交互式查询、机器学习及图计算等于一体

2.基于内存迭代式计算，适合低延迟、迭代运算类型作业

3.可以通过缓存共享rdd、DataFrame，提升效率【尤其是SparkSQL可以将数据以列式的形式存储于内存中】

4.中间结果支持checkpoint，遇错可快速恢复

5.支持DAG、map之间以pipeline方式运行，无需刷磁盘

6.多线程模型，每个worker节点运行一个或多个executor服务，每个task作为线程运行在executor中，task间可共享资源

7.Spark编程模型更灵活，支持多种语言如java、scala、python、R，并支持丰富的transformation和action的算子

MapReduce

1.适合离线数据处理，不适合迭代计算、交互式处理、流式处理

2.中间结果需要落地，需要大量的磁盘IO和网络IO影响性能

3.虽然MapReduce中间结果可以存储于HDFS，利用HDFS缓存功能，但相对Spark缓存功能较低效

4.多进程模型，任务调度(频繁申请、释放资源)和启动开销大，不适合低延迟类型作业

5.MR编程不够灵活，仅支持map和reduce两种操作。当一个计算逻辑复杂的时候，需要写多个MR任务运行【并且这些MR任务生成的结果在下一个MR任务使用时需要将数据持久化到磁盘才行，这就不可避免的进行遭遇大量磁盘IO影响效率】

写在最后

虽然Spark相对于MapReduce有很多优势，但并不代表Spark目前可以完全取代MapReduce。

笔者之前负责的一个任务，数据存储格式是parquet，压缩比比较高，解压后数据量剧增，又加上存在一些大字段问题，任务比较复杂仅sql语句就几千行，导致Spark处理时总是报OOM，在有限的资源试了各种调优方法都不能使任务正常稳定的运行。最后改用Hive的原生引擎MapReduce执行，在资源配置相同的情况下，任务能够稳定运行，而且速度并没有想象中的那么慢。所以，对于技术之间的对比以及应用，还是建议首先要对技术本身有深入的理解比如设计思想、编程模型、源码分析等，并且要结合实际的业务场景需求等，不能空谈技术。