|NO.Z.00061|——————————|BigDataEnd|——|Hadoop&MapReduce.V32|——|Hadoop.v32|MR调优-shuffle调优|小文件优化|数据倾斜|

一、Job调优

~~~     [MR调优-shuffle调优-推测执行-小文件优化]  
~~~     [MR调优-shuffle调优-数据倾斜]

### --- 推测执行

~~~     集群规模很大时（几百上千台节点的集群），个别机器出现软硬件故障的概率就变大了，
~~~     并且会因此延长整个任务的执行时间推测执行通过将一个task分给多台机器跑，
~~~     取先运行完的那个，会很好的解决这个问题。对于小集群，可以将这个功能关闭。

### --- 建议：

~~~     大型集群建议开启，小集群建议关闭！
~~~     集群的推测执行都是关闭的。在需要推测执行的作业执行的时候开启

### --- Slow Start

~~~     MapReduce的AM在申请资源的时候，会一次性申请所有的Map资源，延后申请reduce的资源，
~~~     这样就能达到先执行完大部分Map再执行Reduce的目的。
~~~     mapreduce.job.reduce.slowstart.completedmaps
~~~     当多少占比的Map执行完后开始执行Reduce。默认5%的Map跑完后开始起Reduce。
~~~     如果想要Map完全结束后执行Reduce调整该值为1

### --- 小文件优化

~~~     # HDFS：hadoop的存储每个文件都会在NameNode上记录元数据，如果同样大小的文件，
~~~     文件很小的话，就会产生很多文件，造成NameNode的压力。
~~~     # MR：Mapreduce中一个map默认处理一个分片或者一个小文件，
~~~     如果map的启动时间都比数据处理的时间还要长，那么就会造成性能低，
~~~     而且在map端溢写磁盘的时候每一个map最终会产生reduce数量个数的中间结果，
~~~     如果map数量特别多，就会造成临时文件很多，而且在reduce拉取数据的时候增加磁盘的IO。

### --- 如何处理小文件？

~~~     从源头解决，尽量在HDFS上不存储小文件，也就是数据上传HDFS的时候就合并小文件
~~~     通过运行MR程序合并HDFS上已经存在的小文件
~~~     MR计算的时候可以使用CombineTextInputFormat来降低MapTask并行度

### --- 数据倾斜

~~~     MR是一个并行处理的任务，整个Job花费的时间是作业中所有Task最慢的那个了。
~~~     为什么会这样呢？为什么会有的Task快有的Task慢？
~~~     数据倾斜，每个Reduce处理的数据量不是同一个级别的，所有数据量少的Task已经跑完了，
~~~     数据量大的Task则需要更多时间。
~~~     有可能就是某些作业所在的NodeManager有问题或者container有问题，导致作业执行缓慢。

### --- 数据倾斜

~~~     # 那么为什么会产生数据倾斜呢？
~~~     数据本身就不平衡，所以在默认的hashpartition时造成分区数据不一致问题

~~~     # 那如何解决数据倾斜的问题呢？
~~~     默认的是hash算法进行分区，我们可以尝试自定义分区，修改分区实现逻辑，
~~~     结合业务特点，使得每个分区数据基本平衡
~~~     可以尝试修改分区的键，让其符合hash分区，并且使得最后的分区平衡，
~~~     比如在key前加随机数nkey。
~~~     抽取导致倾斜的key对应的数据单独处理。
~~~     # 如果不是数据倾斜带来的问题，而是节点服务有问题造成某些map和reduce执行缓慢呢？
~~~     使用推测执行找个其他的节点重启一样的任务竞争，谁快谁为准。
~~~     推测执行时以空间换时间的优化。会带来集群资源的浪费，会给集群增加压力。

Walter Savage Landor:strove with none,for none was worth my strife.Nature I loved and, next to Nature, Art:I warm'd both hands before the fire of life.It sinks, and I am ready to depart

——W.S.Landor