WOT架构师系列访谈（6）Databricks研究员连城

WOT架构师系列访谈（6）Databricks研究员连城 - 51CTO.COM
http://database.51cto.com/art/201405/440690.htm

以前用MapReduce写分布式任务，本质上也是在构造计算图，只是每个节点都必须表示成mapper和reducer两个步骤，产生大量浪费。Spark（也包括微软的Dryad，Google的Dremel以及Hadoop 2的Tez）则是合并了大量不必要的mapper任务，构造出更精简的计算图。Spark的任务看起来“小”、并行度高，是因为Spark采用的是线程级并行，且节点间的消息通讯大都是异步的；相较之下，Hadoop MapReduce则是进程级并行，任务启停代价要高得多，而且各节点间的通讯很多是随心跳消息发送的，调度延迟直接受限于心跳消息间隔。这也是Twitter仅仅是简单地把MapReduce任务改写成等价的Spark任务后，计算性能就可以得到数倍提升的一大原因（其他原因还包括Spark不会像MapReduce那样无论任务是否需要都在mapper端进行代价高昂的排序等等）。

理论已经证明MapReduce模型可以模拟一切分布式计算（但未必可以高效模拟）。Spark基于RDD的计算图可以轻松、完整地表达MapReduce模型，而且由于对分布式数据共享做了更高效的抽象，其效率比MapReduce只高不低。