在大数据计算引擎上，MapReduce和Spark是一直被拿来作比较的两个框架，尤其是作为后来者的Spark，越来越多地占据主流市场，这与Spark的性能表现优异是分不开的。那么Spark为什么能够性能表现优异，今天的大数据开发分享，我们来做一个spark与mapreduce几个方面的对比。作为Hadoop框架下的分布式计算引擎，MapReduce从一出现，就是承担着极其重要的任务的——分布式并行计算。而在早期的大数据市场上，MapReduce也的确很好地完成了分布式计算任务。当然，主要是在离线大规模数据场景下。
而后来者Spark，从一出现，就是奔着改良MapReduce的不足而来的。提到Spark，大家都知道是基于内存计算的，而MapReduce基于磁盘计算，速度比不上Spark也就正常了。一、Spark内存计算VSMapReduce读写磁盘MapReduce：MapReduce通常需要将计算的中间结果写入磁盘。map进程和reduce进程需要读取指定位置的数据作为输入，如果不将中间结果写入磁盘以保证可靠存储，一旦中间结果丢失或者损坏，MapReduce没有机制能够恢复中间结果。此外，一个job可能涉及到多个stage，而每个stage的处理结果都需要存储到HDFS中，这就必然导致频繁的磁盘IO。Spark：Spark不需要将计算的中间结果写入磁盘，这得益于Spark的RDD（弹性分布式数据集）和DAG（有向无环图），前者是Spark中引入的一种只读的、可扩展的数据结构，后者则记录了job的stage以及在job执行过程中父RDD和子RDD之间的依赖关系。中间结果能够以RDD的形式存放在内存中，一旦Job中的某个RDD丢失或者损坏，则可以根据DAG来重新计算得到该RDD。此外，在Spark中一个job的多个stage任务可以串联或者并联执行，stage的中间结果不需写入HDFS。我们知道频繁的磁盘IO非常影响系统的处理性能，而基于内存计算则大大提升了处理性能。二、任务调度对比Hadoop的MapReduce是针对大文件的批处理而设计的，延迟较高；Hadoop的MapReduce的MapTask和ReduceTask都是进程级别的，而SparkTask则是基于线程模型的；Spark通过复用线程池中的线程来减少启动、关闭task所需要的开销。三、执行策略对比MapReduce在shuffle前需要花费大量时间进行排序；Spark在shuffle时只有部分场景才需要排序，支持基于Hash的分布式聚合，更加省时；四、数据格式和内存布局MapReduceSchemaonRead处理方式会引起较大的处理开销；SparkRDD能支持粗粒度写操作，对于读操作则可以精确到每条record，因此RDD可以用来作为分布式索引。此外用户可以自定义分区策略，如Hash分区等。关于大数据开发，spark与mapreduce的几个方面的对比，以上就为大家做了基本的介绍了。在目前的大数据计算引擎之争上，MapReduce无疑是被Spark抢走了大部分的