大数据序列六：Hadoop之MapReduce分布式计算框架(下)
MapReduce最重要的阶段：shuffle阶段，也是导致mr(mapreduce)只能做离线数据无法做实时数据的最重要的原因之一。
以下对shuffle做一些介绍。
Shuffle机制
什么是shuffle？
map阶段处理的数据如何传递给reduce阶段，是MapReduce框架中最关键的一个流程，这个流程就叫shuffle。换句话说就是map要通过shuffle把数据传递给reduce，在最终呈现给客户端。
以下图作为说明：
从上图可以看出，shuffle就是像一个缓冲区，maptask的数据过来后先写入缓冲区，缓冲区先接着，然后不停的写，直到缓冲区可用剩余不足后，会把缓冲区的数据刷至磁盘中(同时缓冲区还在接收数据)，那什么情况下缓冲区的数据剩余不足要刷到磁盘呢？默认缓冲区是100M，阈值是80%，也就是说如果使用默认缓冲区大小的情况下，达到80M的时候就会把数据刷至磁盘，并且还要进行排序，在进行分组。
所以从以上shuffle机制中能看出来为什么mr不适合做实时数据呢？第一：数据入磁盘，第二：数据做了排序。
不过这不代表mr一无是处，mr做离线数据的分析还是非常好的，为了澄清mr，作者简单的说明下：
大家都知道，hive(处理大数据的工具)默认的执行引擎是mr，那么意味着什么？毋容置疑，不适合做实时数据。那么还有个工具impala(处理大数据的工具)，这个工具没有用mr引擎，而是自己把数据放入内存中处理，那大家可以想象下，内存和磁盘的优缺点。内存：速度快，可用存储小(相比磁盘)，数据容易丢失。磁盘：速度慢，可用存储大(相比内存)，数据不容易丢失。
那么既然impala既然用内存来处理数据，也就意味着它虽然能实时处理，但是有三个无法逾越的问题：
一：处理PB级的数据相对优秀，但是最多只能到这个级别了。
二：并发量不高，普遍并发量保持在20个左右，当然也是根据数据去定(因为impala执行任务实际是集群一启动就会有很多个线程被开启，同时在等待着任务)。
三：impala集群最多能上百台，无法扩容到上千台。
那回过头来看看hive：
虽然我不能做到实时，但是处理数据可远不止PB级别；
虽然我每次执行任务都需要开启一个进程，但是不牵扯并发量问题；
而且根据使用hive的情况，目前集群已经上万台了。
今天说的有点多了，本来hive和impala是后面需要讲解的内容。也好，让各位朋友有个初步的了解。
咱们继续说说mr那些事。
MapReduce的分区与reduceTask的数量
在MapReduce中，通过我们指定分区，会将同一个分区的数据发送到同一个reduce当中进行处理(默认是key相同去往同个分区)，例如我们为了数据的统计，我们可以把一批类似的数据发送到同一个reduce当中去，在同一个reduce当中统计相同类型的数据，那如何才能保证相同key的数据去往同个reduce呢？只需要保证相同key的数据分发到同个分区即可。结合以上原理分析我们知道MR程序shuffle机制默认就是这种规则。
分区源码
翻阅源码验证以上规则，MR程序默认使用的HashPartitioner，保证了相同的key去往同个分区！
自定义分区
实际生产中需求变化多端，默认分区规则往往不能满足需求，需要结合业务逻辑来灵活控制分区规则以及分区数量！
如何制定自己需要的分区规则？
1. 自定义类继承Partitioner，重写getPartition()方法
2. 在Driver驱动中，指定使用自定义Partitioner
3. 在Driver驱动中，要根据自定义Partitioner的逻辑设置相应数量的ReduceTask数量。
自定义分区牵扯源码了，作者这里就不多啰嗦了，若有相关需求的朋友可私聊。
MapReduce中的Combiner
1. Combiner是MR程序中Mapper和Reducer之外的一种组件
2. Combiner组件的父类就是Reducer
3. Combiner和reducer的区别在于运行的位置
4. Combiner是在每一个maptask所在的节点运行;
5. Combiner的意义就是对每一个maptask的输出进行局部汇总，以减小网络传输量。
6. Combiner能够应用的前提是不能影响最终的业务逻辑，此外，Combiner的输出kv应该跟reducer的输入kv类型要对应起来。
本章节对mr计算框架就说到这里，其实还有很多地方没说，比如mr该如何使用呢，其实作者讲解的重心是靠近原理，也希望大家能完全理解，其实只要理解了核心，只要理解了原理，如何使用还不是分分钟的事儿。