到这里为止，似乎看起来SparkSQL和Hive On MapReduce没有什么区别？其实SparkSQL快，并不快在引擎。SparkSQL的引擎优化，并没有Hive复杂，毕竟人Hive多年积累，十多年下来也不是吃素的。但是Spark本身快呀。
Spark标榜自己比MapReduce快几倍几十倍，很多人以为这是因为Spark是“基于内存的计算引擎”，其实这不是真的。Spark还是 要落磁盘的，Shuffle的过程需要也会将中间数据吐到本地磁盘上。所以说Spark是基于内存计算的说法，不考虑手动Cache的情景，是不正确的。
SparkSQL的快，根本不是刚才说的那一坨东西哪儿比Hive On MR快了，而是Spark引��本身快了。
事实上，不管是SparkSQL，Impala还是Presto等等，这些标榜第二代的SQL On Hadoop引擎，都至少做了三个改进，消除了冗余的HDFS读写，冗余的MapReduce阶段，节省了JVM启动时间。
在MapReduce模型下，需要Shuffle的操作，就必须接入一个完整的MapReduce操作，而接入一个MR操作，就必须将前阶段的MR结果写入HDFS，并且在Map阶段重新读出来，这才是万恶之源。
事实上，如果只是上面的SQL查询，不管用MapReduce还是Spark，都不一定会有显著的差异，因为它只经过了一个shuffle阶段。
真正体现差异的，是这样的查询：
SELECT g1.name, g1.avg, g2.cnt
FROM (SELECT name, avg(id) AS avg FROM students GROUP BY name) g1
JOIN (SELECT name, count(id) AS cnt FROM students GROUP BY name) g2
ON (g1.name = g2.name)
ORDER BY avg;
而他们所对应的MR任务和Spark任务分别是这样的：
一次HDFS中间数据写入，其实会因为Replication的常数扩张为三倍写入，而磁盘读写是非常耗时的。这才是Spark速度的主要来源。 另一个加速，来自于JVM重用。考虑一个上万Task的Hive任务，如果用MapReduce执行，每个Task都会启动一次JVM，而每次JVM启动 时间可能就是几秒到十几秒，而一个短Task的计算本身可能也就是几秒到十几秒，当MR的Hive任务启动完成，Spark的任务已经计算结束了。对于短 Task多的情形下，这是很大的节省。
更多Spark相关教程见以下内容：
CentOS 7.0下安装并配置Spark
CentOS 6.2(64位)下安装Spark0.8.0详细记录
Spark简介及其在Ubuntu下的安装使用