MapReduce框架原理之内核源码解析

MapReduce 框架原理之内核源码解析

MapTask 工作机制

1. 「MapTask 工作机制图」

   

• Read 阶段：MapTask 通过 InputFormat 获得的 RecordReader,从输出 InputSplit 中解析出一个个 key/value。

  （1）以怎样的方式从分片中读取一条记录，每读取一条记录都会调用 RecordReader 类；

  （2）系统默认的 RecordReader 是 LineRecordReader，如 TextInputFormat；而 SequenceFileInputFormat 的 RecordReader 是 SequenceFileRecordReader；

  （3）LineRecordReader 是用每行的偏移量作为 map 的 key，每行的内容作为 map 的 value；

  （4）应用场景：自定义读取每一条记录的方式；自定义读入 key 的类型，如希望读取的 key 是文件的路径或名字而不是该行在文件中的偏移量。

• Map 阶段：该节点主要是将解析出的 key/value 交给用户编写 map()函数处理，并产生一系列新的 key/value。

• Collect 收集阶段：在用户编写 map()函数中，当数据处理完成后，一般会调用 OutputFormatCollector.collect()输出结果。在该函数内部，它会将生成的 key/value 分区（调用 Partitioner),并写入到一个环形内存缓冲区。

• Spill 阶段：即“溢写”，当环形缓冲区满足后，MapReduce 会将数据写到本地磁盘上，生成一个临时文件。需要注意的是，将数据写入本地磁盘之前，先要对数据及进行一次本地排序，并在必要时对数据进行合并、压缩等操作。

  • 「具体步骤」

    • 步骤一：

      利用快速排序算法对缓冲区内的数据进行排序，排序方式是，先按照分区编号 Partition 进行排序，然后按照 key 进行排序。这样，经过排序后，数据以分区为单位聚集在一起，且同一分区内所有数据按照 key 有序。

    • 步骤二：

      按照分区编号由小到大依次将每个分区中的数据写入到任务工作目录下的临时文件 output/spillN.out(N 表示当前溢写次数)中，如果用户设置了 Combiner，则写入到文件之前，对每个分区中的数据进行一次聚集操作。

    • 步骤三：

      将分区中的数据的元信息写到内存索引数据结构 SpillRecord 中，其中每个分区的元信息包括在临时文件中的偏移量、压缩前数据大小和压缩后数据大小。如果当前内存索引大小超过 1MB,，将内存索引写入到文件 output/spillN.out.index 中。

• Merge 阶段：当所有数据处理完成后，MapTask 会对所有临时文件进行一次合并，以确保最终只会生成一个数据文件。

  当所有数据处理完后，MapTask 将所有临时文件合并成一个大文件，并保存到文件 output/file.out 中，同时生成相应的索引文件 output/file.out.index.

  在进行文件合并过程中，MapTask 以分区为单位进行合并。对于每个分区，他将采用多轮合并的方式。每轮合并 mapreduce.task.io.sortfactor（默认 10 个文件),并将产生的文件重新加入待合并列表中，对文件进行排序后，重复以上过程，直到最终合并到一个大文件。

  让每个 MapTask 最终只生成一个数据文件，可避免同时打开大量文件和同时读取小文件产生的随机读取带来的开销。

ReduceTask 工作机制

1.「ReduceTask 工作机制图」

• Copy 阶段：ReduceTask 从各个 MapTask 上远程拷贝一片数据，并对某一片数据，如果其大小超过一定阈值，则写到磁盘上，否则直接放到内存中。
• Sort 阶段：在远程拷贝数据的同时，ReduceTask 启动了两个后台线程对内存和磁盘上的文件进行合并，以防止内存使用过多或磁盘上文件过多。按照 MapReduce 语义，用户编写 reduce()函数输入数据是按照 key 进行聚集一组数据。为了将 key 相同的数据聚在一起，Hadoop 采用了基于排序的策略。由于各个 MapTask 已经实现对自己的处理结果进行了局部排序，因此，ReduceTask 只需对所有数据进行一次归并排序即可。
• Reduce 阶段：reduce（）函数将计算结果写到 HDFS 上。

ReduceTask 并行度决定机制

回顾：MapTask 并行度由切片个数决定，切片个数由输入文件和切片规则决定。

思考：ReduceTask 并行度是由谁决定的？

• 设置 ReduceTask 并行度（个数）

  ReduceTask 的并行度同样影响整个 Job 的执行并发度和执行效率，但与 MapTask 的并发数由切片数决定不同，ReduceTask 数量的是可以直接手动设置

  //默认值是 1,手动设置为 4

  job.setNumReduceTasks(4);

• 实验：测试 ReduceTask 多少合适

  • 实验环境：1 个 Master 节点，16 个 Slave 节点：CPU:8GHZ，内存: 2G

  • 实验结论：

    MapTask =16
    ReduceTask	1	5	10	15	16	20	25	30	45	60
    总时间	892	146	110	92	88	100	128	101	145	104

  • 注意事项：

    ReduceTask=0,表示没有 Reduce 阶段，输出文件和 Map 个数一致。

    ReduceTask 默认值就是 1，所以输出文件个数为 1 个

    如果数据分布不均匀，就有可能在 Reduce 阶段产生数据倾斜

    ReduceTask 数量并不是任意设置，还要考虑业务逻辑需求，有些情况下，需要计算全局汇总结果，就只能有一个 ReduceTask.

    具体多少个 ReduceTask，需要根据集群性能而定。

    如果分区数不是 1,但是 ReduceTask 为 1，是否执行分区过程。答案是:不执行分区过程。因为在 MapTask 的源码中，执行分区的前提是先判断 ReduceNum 是否大于 1。不大于 1 肯定不执行。

MapTask&ReduceTask 源码解析

1. 「MapTask 源码解析流程」

   

2. 「ReduceTask 源码解析流程」