学习Hadoop第十课（MapReduce）
上一节课我们一起学习了RPC简单用法，这节课我们来学习MapReduce，MapReduce可谓是Hadoop当中非常重要的一部分，不学好这部分，我们就无法真正学会Haoop。
那么，首先我们来看一个MapReduce最简单的例子，如下图所示，假如我们要计算一份海量的数据，那么我们应该怎样快速计算出结果呢？
首先，我们需要知道的是，我们对于一份非常大的文件上传到我们的HDFS分布式系统上时它已经不是一个文件了，而是被物理分割成了很多份，至于被分成多少块那就要看文件的大小了，假如文件的大小是1G，HDFS默认的Block Size（区块）大小是128M，那么这1G的文件就会被分成8个区块，每个区块对应一个Mapper，8个区块对应着8个Mapper，每个Mapper执行完自己的任务之后把结果传到Reducer，等8个Mapper执行完毕之后Reducer把8个子结果综合起来就是我们最后要的结果。
我们以下面这个简单的例子来说的话，就是假如我们要计算1+5+7+3+4+9+3+5+6的值，我们为了快速计算，先把1+5+7、3+4+9、3+5+6分成三个区块，这三个区块分别用三台电脑来计算，每台电脑都相当于一个Map，当三台电脑各自计算完自己分到的数字之和后传到Reducer，Reducer再把三个Map计算出来的中间值13、16、14相加，这样便可以得到最终的结果43，这就是最简单的MapReduce原理。
看完了上面那个简单的例子后我们来看一下MapReduce的简介。
接下来我们来看一下MapReduce的架构，在Hadoop2.0中MapReduce是运行在Yarn之上的，Yarn的老大是ResourceManager，小弟是NodeManager，ResourceManagger用来管理资源的分配调度，NodeManager负责做具体的事情。那么对于分布式处理来说，框架的原理是什么呢？
第1步：Client端会把可运行的Jar包先上传到HDFS分布式系统，那么大家有可能会问既然ResourceManager是资源管理者，那么为什么不把资源直接上传到ResourceManager上呢？这是因为每一个可运行的Jar包都可能包含很多依赖的内容，资源所占的大小可能很大，当成千上万个运行资源都上传到ResourceManager时势必会导致ResourceManager崩溃，而我们的HDFS分布式系统则刚好就是用来处理大数据的，它可以处理海量数据，当然也就可以存储运行所需要的资源文件了。因此我们把资源都上传到HDFS分布式系统上。
第2步：Client把在HDFS上的存储信息列表发送给ResourceManager，存储信息包括文件的大小，文件在HDFS系统上存放的路径，该文件被物理分割成了几块，每个块分别放在了什么位置等信息。
第3步：ResourceManager和NodeManager之间是通过心跳机制来保持联系的，就是NodeManager每隔一段时间就要向ResourceManager报告一下自己还活着的信息，如果ResourceManager长期得不到NodeManager的信息，那么就认为该NodeManager已经挂掉了，需要再启动一台设备做为NodeManager。那么我们思考一下，我们是让ResourceManager把主动把任务下发给各个NodeManager好呢还是NodeManager主动向ResourceManager领任务好呢？我想大家肯定很明确的就会做出答复：那就是NodeManager主动向ResourceManager领取任务的方式比较好，因为这样可以大大减轻ResourceManager做为管理者的压力。
第4步：NodeManager向ResourceManager领取到任务后便通过HTTP协议从HDFS系统上下载运行所需要的资源，NodeManager当中一个Block块对应着一个Map，每个Map处理一个块的内容，当所有Map都处理完之后再通过Reducer进行合并。
第5步：NodeManager把处理好的内容再上传给HDFS分布式系统，从而完成了整个流程。
上面我们说了MapReduce的架构，接下来我们具体来看一下MapReduce的原理，也就是NodeManager当中具体发生了什么，如下图所示。我们看页面左下角，我们发现一个file文件有可能被物理切分成block1、block2...blockN个块，一个块又被切分成了两个切片，每个切片对应着一个MapperTask，每个Mapper把处理后的结果（Map）传给shuffle处理，shuffle处理完之后再交给Reducer进行处理，Reducer处理完之后把处理结果写到结果文件当中，每个Reducer对应一个结果文件。
当然，光看上面的图例，我们还不足以明白其中的道理，接下来我们详细看一下各个部分分别应该怎样理解。
首先，左下角关于切片的数量应该是大家感兴趣的，就是到底一个文件应该分成多少个切片比较合适呢？由于我也是初学者，跟大家一样也是小白，我也是跟着老师一节课一节课学习的，对于源码也不熟悉，这里我只贴出获取切片大小最核心的代码，其实就一句代码，如下图所示，Math.max(minSize,Math.min(maxSize,blockSize))这个函数是获取切片大小的数学表达式，其中minSize的默认值是1，maxSize的默认值是2的63次方减1，这两个值都可以在配置文件中进行修改。blockSize的大小是128M即134217728个字节。那么默认情况下一个切片的大小（Math.min(maxSize,blockSize)的值是134217728，Math.max(1,134217728)的值是134217728）是一个block块的大小，也就是说默认情况下，一个block块对应着一个切片，这也是最优的大小。当然，如果想改变切片的大小可以调整maxSize和minSize的值，假如想减少一个切片的大小，比如想把它减为64M即67634176字节，那么我们只需将maxSize在配置文件中改为67634176即可，这样Math.min(67634176,134217728)=67634176，然后Math.max(1,67634176)=67634176，从而达到了将切片减小的目的。如果想将切片大小变大的话，可以改变minSize的值为256M即270536704。我们从上图中发现一个block块对应着两个切片，它就是改变了切片的默认值，让每个切片变成了一个Block块的二分之一大小。
说完了左下角的内容，我们再来说说Mapper获取数据的格式
假如有这么一个文件，文件内容是(两个单词之间的有两个空格):
hello tom
hello jerry
hello kitty
hello world
hello tom
那么Mapper读取到的
接下来该进行处理了，处理的方式是把V1进行分割成两个单词，然后把每个单词及数字1（
在Mapper和Reducer之间通过了一个shuffle过程，这个shuffle过程是Hadoop的核心内容，非常非常重要，面试的时候80%-90%会问这个问题。那么我们接下来便一起来学习一下shuffle这个过程，shuffle过程如下图所示。
我们来分析一下shuffle这个阶段，首先是map从input切片中读取数据，然后map把数据写入到环形缓冲区（上图中的buffer in memory，一个map对应一个环形缓冲区），这个环形缓冲区的默认大小是100M，当写入的内容达到缓冲区的80%时开始写入到磁盘（将数据写入到磁盘的一个小文件当中），这个过程首先要对数据进行分区，关于分区，我们可以自定义一个Partition类来按我们的规则进行分区，那么假如我们没有自定义分区规则，那么MapReduce是有一个默认的分区规则的，如下图所示，参数key是指Map处理完原始数据后的K2，就是上面我们所说的
当map task处理完之后，Reduce便把上图中的map的0号分区的内容取过来，另外两个Reduce把1号分区和2号分区的内容去过来，由于Map往往有多个，因此Reduce会向所有的Map中获取相应分区号的内容，获取到内容后两两进行合并，如果是偶数个文件，刚好两两合并后再进行两两合并，如果是奇数个文件，那么先合并其中的两个文件，这两个文件合并完之后再与剩下的那个文件进行合并，最终交给Reduce处理，Reduce处理完之后将结果输出，一个Reducer对应一个结果文件。
public int getPartition(K key, V value, int numReduceTasks){
return (key.hashCode() & Integer.MAX_VALUE) % numReduceTasks;
}
好了，这节我们学习到这儿，由于所说的都是些理论的东西，很难理解，等学了后面的一些实例之后可能有更好的理解。