Spark VS MapReduce 浅谈

计算速度

计算的速度是取决于计算机本身的计算能力的。 并且目前来看，所有的计算机计算都是基于内存的（如果有不是的，请原谅我的孤陋寡闻...）， 也就是说 MR 和 Spark 是没有区别的。

Shuffle

我们都知道，不管是Spark 还是 MR， 其理论依据都是 一篇名为 MapReduce 的论文 那么对于 Map 和 Reduce 两个阶段，其都是会产生 Shuffle 的， 而Shuffle会使得数据落地到磁盘， 相比于内存计算，磁盘的读写一般是要慢很多的， 当然不要抬杠说一些非常复杂的计算逻辑噢~~~ 所以 Shuffle 也是影响速度的一个重要因素

Shuffle 方式或者说算法，其实二者差别也不大， 因为理论依据一样，所以理论上， 二者在这一块基本不会拉开差距，

计算模型

上面说了看似废话的两点， 但是还是得要说明，防止一些先入为主的错误观念。 那就是Spark的计算模型 DAG， 下面我们以Spark的视角来看DAG的优势。

编程更简单方便

因为DAG的存在， 是的 Spark 编程比MR方便快捷， 也更加的简单了， 在我看来这也是从MR转Spark的一个非常重要的一点， 谁也不会否认，用了Spark，真的不想再去编程MR了。

具体更好的控制力

因为DAG的存在， 使得我们可以把 各种业务 任意组合， 好处是显而易见的：

• 业务上的任务更加清晰了， 维护成本更低了， 而 MR 则是一个一个的Job，完全是分开的， 要维护一个正常的业务开发， 那是真的不那么简单，
• 而对于Spark而言， 因为任务都是在一个 Application 里面， 所以在计算方面，资源分配方面， 都有了更大的可操作空间， 比如说：Cache 算子的出现， 如果没有DAG，你根本无法使用类似这样的算子。 而MR要做类似Cache之类的优化是非常困难的， 当然，这里可以说，虽然难， 如果你是大佬，你也是可以进行优化的， 优化的效果，理论上也是可以让二者在运行速度上没差， 但是我估计，没人会愿意去做这种吃力吃力才讨好的事情吧。
• Shuffle的次数会更少， 还是是因为任务都是在一个 Application 里面， Spark很容易可以根据任务流来进行Shuffle的规划， 而MR则完全依赖于用户， 这就导致MR的不可控， 虽然如果你是一个优秀的开发者， 噢~不是，应该是大神的开发者， 你也可以优化的没有一丝差异。

这里先额外提一句就是： 如果是团队开发，那队友都是水平参差不齐的， 很难做好优化工作， 就算是一个大神开发， 因为业务的多变，不当维护很难， 面对一些场景，可能不得不舍弃一些优化， 所以，不要想着MR能做到和Spark一样的水平， 那只是理想的国度，基本不存在的。

资源调度

这里不得不提一下的是： MR的资源调度是细粒度调度的， 也就是说，他每个Job都要经历一次资源的申请到释放， 并且其执行的 Task 任务也是基于JVM 进程的。

而Sarpk则是粗粒度的资源调度， 其一个Application 只会进行一次资源申请， 在没有执行完所有任务，他是不会释放资源的， 并且其Task执行是基于更加轻量级的线程， 当我们处理数据的Task很多的时候， 这个节省的时间也是不可忽视的。

结束语

该文其实主要是以 DAG计算模型为主， 这也是在笔者看来Spark对于MR最重要的改变， 因为DAG的存在才有后来各种各样比MR高效的优化， 这里可能挖的其实还不够深， 如果有兴趣，欢迎你来进行补充和讨论。