MapReduce模型过程详解

@Author  : Spinach | GHB
@Link    : http://blog.csdn.net/bocai8058

文章目录

MapReduce过程
- 从客户端、jobTracker、taskTracker角度讲(MapReduce作业运行流程)
- 从map、reduce阶段讲(Map、Reduce任务中Shuffle和排序的过程)
指定map和reduce的数量
shuffle中的sort
自定义partitioner
自定义combiner
自定义RecordReader

MapReduce过程

从客户端、jobTracker、taskTracker角度讲(MapReduce作业运行流程)

流程分析：

在客户端启动一个作业。
向JobTracker请求一个Job ID。
将运行作业所需要的资源文件复制到HDFS上，包括MapReduce程序打包的JAR文件、配置文件和客户端计算所得的输入划分信息。这些文件都存放在JobTracker专门为该作业创建的文件夹中。文件夹名为该作业的Job ID。JAR文件默认会有10个副本（mapred.submit.replication属性控制）；输入划分信息告诉了JobTracker应该为这个作业启动多少个map任务等信息。
JobTracker接收到作业后，将其放在一个作业队列里，等待作业调度器对其进行调度（这里是不是很像微机中的进程调度呢，呵呵），当作业调度器根据自己的调度算法调度到该作业时，会根据输入划分信息为每个划分创建一个map任务，并将map任务分配给TaskTracker执行。对于map和reduce任务，TaskTracker根据主机核的数量和内存的大小有固定数量的map槽和reduce槽。这里需要强调的是：map任务不是随随便便地分配给某个TaskTracker的，这里有个概念叫：数据本地化（Data-Local）。意思是：将map任务分配给含有该map处理的数据块的TaskTracker上，同时将程序JAR包复制到该TaskTracker上来运行，这叫“运算移动，数据不移动”。而分配reduce任务时并不考虑数据本地化。
TaskTracker每隔一段时间会给JobTracker发送一个心跳，告诉JobTracker它依然在运行，同时心跳中还携带着很多的信息，比如当前map任务完成的进度等信息。当JobTracker收到作业的最后一个任务完成信息时，便把该作业设置成“成功”。当JobClient查询状态时，它将得知任务已完成，便显示一条消息给用户。

从map、reduce阶段讲(Map、Reduce任务中Shuffle和排序的过程)

流程分析：

Map端：

每个输入分片会让一个map任务来处理，默认情况下，以HDFS的一个块的大小（默认为64M）为一个分片，当然我们也可以设置块的大小。map输出的结果会暂且放在一个环形内存缓冲区中（该缓冲区的大小默认为100M，由io.sort.mb属性控制），当该缓冲区快要溢出时（默认为缓冲区大小的80%，由io.sort.spill.percent属性控制），会在本地文件系统中创建一个溢出文件，将该缓冲区中的数据写入这个文件。
在写入磁盘之前，线程首先根据reduce任务的数目将数据划分为相同数目的分区，也就是一个reduce任务对应一个分区的数据。这样做是为了避免有些reduce任务分配到大量数据，而有些reduce任务却分到很少数据，甚至没有分到数据的尴尬局面。其实分区就是对数据进行hash的过程。然后对每个分区中的数据进行排序(快速排序)，如果此时设置了Combiner，将排序后的结果进行Combia操作，这样做的目的是让尽可能少的数据写入到磁盘。
当map任务输出最后一个记录时，可能会有很多的溢出文件，这时需要将这些文件合并。合并的过程中会不断地进行排序(归并排序)和combia操作，目的有两个：1.尽量减少每次写入磁盘的数据量；2.尽量减少下一复制阶段网络传输的数据量。最后合并成了一个已分区且已排序的文件。为了减少网络传输的数据量，这里可以将数据压缩，只要将mapred.compress.map.out设置为true就可以了。
将分区中的数据拷贝给相对应的reduce任务。有人可能会问：分区中的数据怎么知道它对应的reduce是哪个呢？其实map任务一直和其父TaskTracker保持联系，而TaskTracker又一直和JobTracker保持心跳。所以JobTracker中保存了整个集群中的宏观信息。只要reduce任务向JobTracker获取对应的map输出位置就ok了哦。

到这里，map端就分析完了。那到底什么是Shuffle呢？Shuffle的中文意思是“洗牌”，如果我们这样看：一个map产生的数据，结果通过hash过程分区却分配给了不同的reduce任务，是不是一个对数据洗牌的过程呢？呵呵。

Reduce端：

Reduce会接收到不同map任务传来的数据，并且每个map传来的数据都是有序的。如果reduce端接受的数据量相当小，则直接存储在内存中（缓冲区大小由mapred.job.shuffle.input.buffer.percent属性控制，表示用作此用途的堆空间的百分比），如果数据量超过了该缓冲区大小的一定比例（由mapred.job.shuffle.merge.percent决定），则对数据合并后溢写到磁盘中。
随着溢写文件的增多，后台线程会将它们合并成一个更大的有序的文件，这样做是为了给后面的合并节省时间。其实不管在map端还是reduce端，MapReduce都是反复地执行排序，合并操作，现在终于明白了有些人为什么会说：排序是hadoop的灵魂。
合并的过程中会产生许多的中间文件（写入磁盘了），但MapReduce会让写入磁盘的数据尽可能地少，并且最后一次合并的结果并没有写入磁盘，而是直接输入到reduce函数。

指定map和reduce的数量

map数量确定

输入文件数量和大小
blockSize block大小
splitsize大小。分片是按照splitszie的大小进行分割的，一个split的大小在没有设置的情况下，默认等于hdfs block的大小。但应用程序可以通过两个参数来对splitsize进行调节

InputSplit=Math.max(minSize, Math.min(maxSize, blockSize)
其中：minSize=mapred.min.split.sizemaxSize=mapred.max.split.size

reduce数量

reduce可以为0
reducer个数是由partition个数决定，默认是1。
- key的hash值
- numReduceTasks，需要我们通过job.setNumReduceTasks(reduceNum) 方法来设置的reducer个数，最终得出partition个数就是我们设置的个数，比如我们设置job.setNumReduceTasks(3) hashcode除以10的余数就是0、1、2三个值，默认之所以用key的hash值是为了把数据均匀的分布到reducer防止数据倾斜。
- 当然了我们可以根据我们自己的业务来继承Partition类重写getPartition方法来决定partition数。

引用：https://www.cnblogs.com/codeOfLife/p/5676754.html | https://www.cnblogs.com/xiangyangzhu/p/5278328.html | https://blog.csdn.net/Franksten/article/details/78862087 | https://blog.csdn.net/qq1010885678/article/details/50922812 | https://blog.csdn.net/u010842515/article/details/62886000 | https://blog.csdn.net/lpxuan151009/article/details/7937821

shuffle中的sort

整体的Shuffle过程包含以下几个部分：Map端Shuffle、Sort阶段、Reduce端Shuffle。即是说：Shuffle过程横跨map和reduce两端，中间包含 sort阶段，就是数据从map task输出到reduce task输入的这段过程。

Shuffle的sort阶段主要采用两种算法：快速排序和归并排序。

快速排序(Quick Sort)：是对冒泡排序的一种改进，基本思想是选取一个记录作为枢轴，经过一趟排序，将整段序列分为两个部分，其中一部分的值都小于枢轴，另一部分都大于枢轴。然后继续对这两部分继续进行排序，从而使整个序列达到有序。

归并排序：归并排序是建立在归并操作上的一种有效的排序算法。该算法是采用分治法（Divide and Conquer）的一个非常典型的应用。首先考虑下如何将将二个有序数列合并。这个非常简单，只要从比较二个数列的第一个数，谁小就先取谁，取了后就在对应数列中删除这个数。然后再进行比较，如果有数列为空，那直接将另一个数列的数据依次取出即可。

spill内部的排序是快速排序
合并spill文件的排序是归并排序

整体排序次数有多次，例如1.map端的spill内部快速排序；2.map端的spill文件合并和归并排序；3.reduce端的spill文件合并和归并排序。实际如果有partitioner，还要进行一次快速排序操作

自定义partitioner

Partitioner是partitioner的基类，如果需要定制partitioner也需要继承该类。

Partitioner分区是在map执行完成后与reduce未执行前执行的，可以让Map对Key进行分区(指定reduce数量)，负责将map产生的中间结果进行划分，确保相同的key到达同一个reduce节点，从而可以根据不同的key来分发到不同的reduce中去处理。

HashPartitioner

在一般的MapReduce过程中，我们知道可以通过job.setNumReduceTasks(N)来创建多个ReducerTask进行处理任务。可是，这种情况下，系统会调用默认的Partitioner也就是HashPartitioner来对Map的key进行分区。

进入Hadoop的源码，可以看到HashPartitioner的实现其实很简单。如下：

public class HashPartitioner<K2, V2> implements Partitioner<K2, V2>
{public void configure(JobConf job) {} /** Use {@link Object#hashCode()} to partition. */ public int getPartition(K2 key, V2 value, int numReduceTasks) { return (key.hashCode() & Integer.MAX_VALUE) % numReduceTasks;}
}

HashPartitioner是处理Mapper任务输出的，getPartition()方法有三个形参，源码中key、value分别指的是Mapper任务的输出，numReduceTasks指的是设置的Reducer任务数量，默认值是1。那么任何整数与1相除的余数肯定是0。也就是说getPartition(…)方法的返回值总是0。也就是Mapper任务的输出总是送给一个Reducer任务，最终只能输出到一个文件中。

例如：自定义的partitioner，将偶数和奇数放在不同的分区中

public class MyPartitioner extends Partitioner<LongWritable, Text>
{@Overridepublic int getPartition(LongWritable key, Text value, int numPartitions) {//偶数放到第二个分区进行计算if (key.get() % 2 == 0){//将输入到reduce中的key设置为1key.set(1);return 1;} else {//奇数放在第一个分区进行计算//将输入到reduce中的key设置为0key.set(0);return 0;}}
}

在运行Mapreduce程序时，只需在主函数里加入如下两行代码即可：

job.setPartitionerClass(MyPartitioner.class);
job.setNumReduceTasks(3);//设置为3

BinaryPartitioner
HashPartitioner
KeyFieldBasedPartitioner
TotalOrderPartitioner

自定义combiner

每一个map可能会产生大量的输出，combiner的作用就是同一个map中相同的key进行合并，以减少在map和reduce节点之间的数据传输量，以提高网络IO性能，是MapReduce的一种优化手段之一。

Combiner最基本是实现本地key的归并，Combiner具有类似本地的reduce功能，是一个特殊的Reducer。

如果不用Combiner，那么，所有的结果都是reduce完成，效率会相对低下。使用Combiner，先完成的map会在本地聚合，从而提升速度。

注：Combiner的输出是Reducer的输入，如果Combiner是可插拔的，添加Combiner绝不能改变最终的计算结果。所以Combiner只应该用于一种Reduce的输入key/value与输出key/value类型完全一致，且不影响最终结果的场景。比如累加，最大值等。

自定义RecordReader

RecordReader表示以怎样的方式从分片中读取一条记录，每读取一条记录都会调用RecordReader类，系统默认的RecordReader是LineRecordReader，它是TextInputFormat对应的RecordReader；而SequenceFileInputFormat对应的RecordReader是SequenceFileRecordReader。LineRecordReader是每行的偏移量作为读入map的key，每行的内容作为读入map的value。很多时候hadoop内置的RecordReader并不能满足我们的需求，比如我们在读取记录的时候，希望Map读入的Key值不是偏移量而是行号或者是文件名，这时候就需要我们自定义RecordReader。