一篇解析论文MapReduce

Posted 2022-02-23 秋雨——

自己通过阅读了解论文和极客时间相关讲解，并通过自己已有的框架知识，总结该文章，阅读需要有一定的大数据基础知识。

文章目录

• • MapReduce的计算模型
  • MapReduce如何使得开发者无需关心分布式的存在（易用性）
  • MapReduce 的性能优化
  • 遗憾与缺陷

MapReduce整篇论文分为三个部分

MapReduce的计算模型

面对海量的数据，我们所需要的计算，有以下三种情况：

• 第一种，面对所有的数据，我们都只需要单条数据就能完成处理。

• 第二种，需要汇总多条数据才能完成计算。（将相同的搬运到一个节点，不同的仍旧可以在不同的节点）

• 第三种，就是第一二种的结合，例如提取关键字，统计关键字的出现次数。

所以对应的计算模型，就是Map（第一种）和Reduce（第二种）。

• Map：映射函数，将接受的一个key-value转化为0到多个新的key-value输出。

• Reduce：化简函数，接收一个key及其下所有的Value，然后化简为一组新的值Value输出出去。

Map 帮助我们解决了并行在很多台机器上处理互相之间没有依赖关系的数据；而 Reduce 则用来处理互相之间有依赖关系的数据，我们可以通过 MapReduce 框架自带的 Shuffle 功能，通过排序来根据设定好的 Key进行分组，把相同 Key 的数据放到同一个节点上，供 Reduce 处理。

MapReduce如何使得开发者无需关心分布式的存在（易用性）

用户只需编写对应的Map和Reduce的逻辑。

• MapReduce的协同

  指master对于map和reduce的协调，由master找到对应的空闲节点启动对应的worker。

  其中分区函数把输出的数据分成 R 个不同的区域。而这些本地文件的位置，会被 worker 传回给到 master 节点，再由 master 节点将这些地址转发给 reduce 任务所在的 worker 那里，reduce去进行拉取。

  整个过程map和reduce是不会直接通信的，都是与master进行交互。

  因与Hadoop的MapReduce基本一样，故不做赘述过程。

  在Hadoop1.0中，JobTracker既承担了调度的任务，又承担了master的任务，这使得服务器一多，JobTracker的负载就很重，所以就有了Hadoop集群承载服务器的上限，其成为脆弱的‘单点’。

  在Hadoop2.0中，将JobTracker的任务分为Resource Mananger（调度任务）和 Application Master（master，单个任务的管理），回归了论文中的设计。

• MapReduce的容错

  worker节点的失效：

  MapReduce 框架解决问题的方式非常简单。就是换一台服务器重新运行这个 Worker 节点被分配到的所有任务。master 节点会定时地去 ping 每一个worker 节点，一旦 worker 节点没有响应，我们就会认为这个节点失效了。

  master节点的失效：

  方案一：任由其失败，再重新提交就可以。

  方案二：master中的信息定时存入Checkpoint，当失败重启后，读取Checkpoint，不至于重新运行整个任务。

• 对错误数据视而不见

  MapReduce 会记录 Map 或者 Reduce 函数，运行出错的具体数据的行号，如果同样行号的数据执行重试还是出错，它就会跳过这一行的数据。如果这样的数据行数在总体数据中的比例很小，那么整个 MapReduce 程序会忽视这些错误，仍然执行完成。（我们不可能为了一条数据（大数据场景下，几条数据的错误并不会对结果造成影响）），而去重新扫描几个TB的数据）。

MapReduce 的性能优化

• 把程序搬到数据那里（尽可能减少网络传输）

  GFS 知道每一个 Block 的数据是在哪台服务器上的。而 MapReduce，会找到同样服务器上的 worker，来分配对应的map 任务。如果那台服务器上没有，那么它就会找离这台服务器最近的、有 worker 的服务器，来分配对应的任务。

• Combiner（减少map和reduce间网络传输）

  在map端进行轻度聚合，然后再交由reduce聚合。（也可以减少reduce端的压力）

注意不要改变逻辑，如算平均值，不能用这种方法。

• MapReduce的dubug

  master 里面内嵌一个 HTTP 服务器，将 master 的各种状态展示出来。我们可以看到任务的执行情况，完成进度，输入多少，输出多少，以及每个任务的日志信息。

  MapReduce 框架里提供一个计数器（counter）的机制，所有 map 和 reduce 的计数器都会汇总到 master 节点上，通过上面的 HTTP 服务器里展现出来。（我们可以统计有价值的信息，例如有多少个信息是非法的，如果比例太高，我们需要调整对应的程序）。

在Hadoop，这个HTTP服务器即指我们访问的8088号端口。

遗憾与缺陷

分布式：仍旧会让用户意识到分布式的存在。无论是 Combiner还是Partitioner，都让用户明白其面对的仍旧为分布式。

性能：每个任务开销比较大，我们必须先使得数据本地化，复制到各个worker节点，才能启动进程。

​ 所有的中间数据都要读写多次硬盘。