处理业务，使用spark比MR快的原因
前言
从官网上看，使用spark处理业务要比MR快100倍左右。
原因主要有三点：
- 运算资源：内存&硬盘
- 根本原因：spark DAG任务划分减少了不必要的shuffle
- 资源申请粒度：进程&线程
内存&硬盘
注意：MR和spark最终的shuffle阶段（如果有），都避免不了写磁盘
MapReduce
MR在map阶段会在溢写阶段将中间结果频繁的写入磁盘，在reduce阶段再从磁盘拉取数据。频繁的磁盘IO消耗大量时间
mapTask、reduceTask工作机制
Spark
Spark不需要将计算的中间结果写入磁盘。这得益于spark的RDD（Resilient Distributed Dataset），即弹性分布式数据集。在各个RDD的分区中，各自处理自己的中间结果即可。在迭代计算时，这一优势更为明显
spark DAG任务划分减少了不必要的shuffle
通过Spark独有的DAG任务划分，减少了不必要的shuffle。在多个job联合作业求一个最终结果时尤为明显。
- 对MR来说，每一个job的结果都会落地到磁盘。后续依赖于次job结果的job，会从磁盘中读取数据再进行计算。
- 对于spark来说，每一个job的结果都可以保存到内存中供后续job使用。配合spark的缓存机制，大大的减少了不必要的shuffle
资源申请粒度：进程&线程
开启和调度进程的代价一般情况下大于线程的代价。所以spark运行速度快于MR任务，但是在资源控制方面MR要好于spark
MapReduce
- MR任务以进程的方式运行在yarn集群中。N个MapTask就要对应申请N个进程
Spark
- Spark的任务是以县城的方式运行在进程中。N个MapTask就要对应申请N个线程。
- 以Spark集群的standAlone模式举例：N个MapTask对于若干个Executor(由集群自动分配的进程，个数不小于1)和N个task线程。即MapTask与最终的task线程数是1比1的。
资源控制的角度来讲，MR优于Spark:
- MR采用多进程模型，可以更好的细粒度处理每个任务占用的资源。
- Spark采用多线程模型，同节点（Worker）的任务(Task)运行在一个进程（Executor）中，难以细粒度控制每个任务占用资源。（操作系统分配资源的最小单位是进程）
多任务计算示例
网上有个多任务计算的示例，直接看 后半部分就行。
求ItemId相似性最高的前N个ItemId