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高效的优化，
这里可能挖的其实还不够深，
如果有兴趣，欢迎你来进行补充和讨论。