在 MapReduce 为海量数据的计算服务多年后，随着时代的发展和 Spark 等新技术的出现，它的劣势也慢慢的凸显出来了：
- 执行速度慢。
- 编程复杂度过高。
先看第一点
2000 年代诞生的 MapReduce ，因为计算资源有限，所以 MapReduce 在计算完成后会将结果写回HDFS中，也就是落盘。
以上面800个数据块为例子，MapReduce 会有800次的 Map 计算结果落盘以及多个 Reduce 计算结果聚合（这个行为有一个专业的术语： Shuffle，这里不具体说明）。
按照现在的思维，大家肯定认为结果应该写在内存中，但实际情况就像上面所说：计算资源有限。为了让大家有所概念，这里看下2000年的内存报价。
所以在那个时候，大家并不会觉得慢，也不会认为有什么问题。
再看第二点（编程复杂度过高）
虽说 Pig、Hive 已经对 MapReduce 编程进行封装降低了海量数据计算的难度，但是在构造一些复杂计算需求时依然需要进行 MapReduce 编程。
由于 MapReduce 的计算模型只有 Map 和 Reduce 两个阶段，在实现复杂计算需求时就要编写多个 Mapper 和 Reducer 的实现。不仅如此，还要协调这些 MapReduce 任务顺序，甚至要设计一个协调系统。如此一来，就增加整个系统的复杂度。
Spark 的诞生有效的解决了这两个问题。
Spark 是什么？
Spark 和 MapReduce 一样，都是一个计算引擎，都是为了解决海量数据计算。两者的工作流程大体类似，都是分而治之，都是移动计算。只不过 Spark 利用内存存储计算结果使得任务执行更高效，提供的编程模型使得编程更简单。
Spark 的高效通过文字很难体现，后面会专门写一篇相关的文章。
大家可以通过下面的代码直观的感受一下 Spark 编程的简易程度。
val textFile = sc.textFile("hdfs://...")
val counts = textFile.flatMap(line => line.split(" ")).map(word => (word, 1)).reduceByKey(_ + _)
counts.saveAsTextFile("hdfs://...")
这段和 MapReduce 的 WordCount 程序达到同样的目的，但是只用了三行代码（了解函数式编程应该不难理解）。
所以，Spark 出现后早就没有人去用 MapReduce 了。但这并不影响 MapReduce 的地位，毕竟它的设计思想影响了很多技术，例如Spark。
和 MapReduce 相比，Spark 确实有很多概念比较晦涩难懂，例如 RDD、DAG、Stage。还有在学习的过程中对 Spark 的一些描述产生的疑问，例如“为什么说 Spark 是内存计算？计算不都基于内存？”，以及随之而来的“Spark 的高效到底体现在哪里？”、“同一个 Stage 的多个算子是最终由几个任务执行？”等等。最后，只能通过一遍遍的的教程和源码来解答心中的疑问。
由于文章篇幅的原因，如果你和我一样有同样的疑问，请关注我，欢迎大家一起交流。
