MapReduce浅读MapReduce概要
MapReduce概要
背景
几个小时要处理完TB的数据，但是这些程序一般都不是分布式系统人员开发的，使用起来因为一些分布式的系统问题，会非常的痛苦
总体目标
非专业的分布式系统开发人员可以轻松的开发高效的处理大数据的程序，开发人员只需要定义好map和reduce函数，然后就可以在成千上万的机器上运行了，完全可以不去关心分布式系统的细节。
优势
模型容易编程，将一些分布式系统中的头痛问题隐藏起来：
- 并发：和顺序执行一样的结果
- 如何在服务器上启动worker和sever
- 在不同机器之间移动数据
- 容错
模型的扩展性好，map和reduce函数彼此之间不需要等待，数据获取上彼此也不干扰，因此可以并行执行，因此可以通过简单的加机器就提升系统性能
限制
那什么会是限制性能的因素呢？CPU?内存？硬盘？网络？一般来说会是网络带宽，要处理的数据传输会远大于网络带宽，因此MR在设计会尽量减少网络上的数据传输。
容错
如果一个server在执行MR job的时候挂了怎么办？
我们可以简单的重新执行一遍任务，这是基于一个基本的假设：map和reduce函数都是纯函数，不会改变输入的数据、不会保持状态、不共享内存、不存在map和map，或者reduce和reduce之间的联系。
所以重新执行也会产生相同的输出。纯函数的这个特点是MR相对于其他并行编程方案的主要不同，然后也是因为这个特性使得MR非常简单。
更多的一些细节
- master分配任务给worker，对于map函数会记录住中间输出位置
- 每个输入都存储在GFS中，一共存3份
- 所有的server同时运行GFS和MR workers，让map worker从本机的GFS中读取数据，减少网络传输
- 输入的分片会远远大于workers的数量，master在每台机器上面执行Map任务，当原来的任务完成之后map会处理新的任务
- worker将输出按key散列映射输出到R分区保存在本地磁盘上
- 当全部没有Map执行的时候Reduce将会执行
- master告诉Reducers去获取Map workers产生的中间数据分区，Reduce worker将最终的结果输出到GFS
负载均衡
怎么让任务均衡的在worker上运行？因为每个分片处理的时间都是不同的，不同的内容和大小，机器性能也不同，因此分片的个数要大于worker，不会因为某个分片处理的特别慢和影响整个的完成时间，早完成的worker会接着处理下一个分片，最后所有worker一起完成任务。
容错
mr怎么处理worker崩溃？
- map worker崩溃 master重新执行，将task重新分配给GFS上的其他副本的的机器上去，即使workers可能实际上已经完成了任务，但是reducer需要中间文件，因此需要重新执行map任务。这个时候，可能有些reducer可能已经读取了crashed worker产生的中间文件，这个时候也没有关系，因为map和reduce函数都是无副作用的，因此重新执行就可
- reduce worker在产生output之前崩溃：master将任务分配给其他worker执行即可
- reduce worker在产生output的时候崩溃：GFS的atomic rename能够保证在完成之前临时文件都是不可见的，因此master重新分配任务即可
其他的一些问题
- 假如master意外的开启两个Ｍap worker处理同一个输入会怎么样？ 它只会告诉Reduce worker其中的一个。
- 假如两个Reduce worker处理中间数据的同一个分区会怎么样？ 它们都会将同一份数据写到GFS上面，GFS的原子重命名操作会触发，先完成的获胜将结果写到GFS.
- 假如一个ｗorker非常慢怎么办 — 一个掉队者？ 产生原因可能是非常糟糕的硬件设施。 master会对这些最后的任务创建第二份副本任务执行。
- 假如一个worker因为软件或者硬件的问题导致计算结果错误怎么办？ 太糟糕了！MR假设是建立在"fail-stop"的cpu和软件之上。
- 假如master崩溃怎么办？
不适合哪些应用
首先必须明确并不是所以应用都适合map/shuffle/reduce这种模式
- 小数据不适合，因为成本太高
- 对于大数据的更新，例如：在大索引中增加些新的文件
- 不确定的读（Map 和 Reduce都不能确定输入）
- 多次shuffles，例如：page-rank
总结
MapReduce的出现使得集群计算变的流行，但是MapReduce也有优缺点：
缺点：不是最有效或者灵活的
有点：扩展性好，容易编程，错误处理和数据移动都被隐藏了