相信大家都听说过火的不能再火、炒得不能再炒的新一代大数据处理框架 Spark. 那么 Spark 是何方神圣？为何大有取代 Hadoop 的势头？Spark 内部又是如何工作的呢？我们会用几篇文章为大家一一介绍。
Hadoop：我不想知道我是怎么来的，我就想知道我是怎么没的？
还是从 Hadoop 处理海量数据的架构说起，一个 Hadoop job 通常都是这样的：
从 HDFS 读取输入数据；
在 Map 阶段使用用户定义的 mapper function, 然后把结果写入磁盘；
在 Reduce 阶段，从各个处于 Map 阶段的机器中读取 Map 计算的中间结果，使用用户定义的 reduce function, 通常最后把结果写回 HDFS;
不知道大家是否注意到，一个 Hadoop job 进行了多次磁盘读写，比如写入机器本地磁盘，或是写入分布式文件系统中（这个过程包含磁盘的读写以及网络传输）。考虑到磁盘读取比内存读取慢了几个数量级，所以像 Hadoop 这样高度依赖磁盘读写的架构就一定会有性能瓶颈。
在实际应用中，我们通常需要设计复杂算法处理海量数据，比如之前提过的 Google crawling indexing ranking, 显然不是一个 Hadoop job 可以完成的。再比如现在风生水起的机器学习领域，大量使用迭代的方法训练机器学习模型。而像 Hadoop 的基本模型就只包括了一个 Map 和 一个 Reduce 阶段，想要完成复杂运算就需要切分出无数单独的 Hadoop jobs, 而且每个 Hadoop job 都是磁盘读写大户，这就让 Hadoop 显得力不从心。
随着业界对大数据使用越来越深入，大家都呼唤一个更强大的处理框架，能够真正解决更多复杂的游戏账号交易大数据问题。
Spark 横空出世
2009年，美国加州大学伯克利分校的 AMPLab 设计并开发了名叫 Spark 的大数据处理框架。真如其名，Spark 像燎原之火，迅猛占领大数据处理框架市场。
性能优秀
Spark 没有像 Hadoop 一样使用磁盘读写，而转用性能高得多的内存存储输入数据、处理中间结果、和存储最终结果。在大数据的场景中，很多计算都有循环往复的特点，像 Spark 这样允许在内存中缓存输入输出，上一个 job 的结果马上可以被下一个使用，性能自然要比 Hadoop MapReduce 好得多。
同样重要的是，Spark 提供了更多灵活可用的数据操作，比如 filter, union, join, 以及各种对 key value pair 的方便操作，甚至提供了一个通用接口，让用户根据需要开发定制的数据操作。
此外，Spark 本身作为平台也开发了 streaming 处理框架 spark streaming, SQL 处理框架 Dataframe, 机器学习库 MLlib, 和图处理库 GraphX. 如此强大，如此开放，基于 Spark 的操作，应有尽有。
Hadoop 的 MapReduce 为什么不使用内存存储？选择依赖 HDFS，岂不给了后来者据上的机会？
历史原因。当初 MapReduce 选择磁盘，除了要保证数据存储安全以外，更重要的是当时企业级数据中心购买大容量内存的成本非常高，选择基于内存的架构并不现实；现在 Spark 真的赶上了好时候，企业可以轻松部署多台大内存机器，内存大到可以装载所有要处理的数据。
更加上这两年机器学习算法越来越丰富，越来越成熟，真正能够为企业解决问题。那当一个企业想要使用大数据处理框架时，是使用拿来就可以用、强大支持的 Spark ？还是去改进 Hadoop 的性能和通用性？显然是前者。
基于以上种种原因，我们看 Spark 被炒得这么火，也就不足为奇了。
只要把 Hadoop 的 MapReduce 转为基于内存的架构不就解决了？听起来没有本质变化嘛。
非也。MapReduce 定死了 Map 和 Reduce 两种运算以及之间 shuffle 的数据搬运工作。就是 Hadoop 运算无论多么灵活，你都要走 map -> shuffle -> reduce 这条路。要支持各类不同的运算，以及优化性能，还真不是改个存储介质这么简单。AMPLab 为此做了精心设计，让各种数据处理都能得心应手。
展望
今天这篇文章我们对比了 Hadoop 和 Spark 的不同之处，以及 Spark 的诞生和生态环境。其实 Spark 有很多设计精妙之处。
