标签：seq   直接   次数   瓶颈   性能   put   mapreduce   资源   completed   

1、MapReduce跑的慢的原因

MapReduce程序效率的瓶颈主要在于两点：

1、机器性能不足（CPU、内存、磁盘健康、网络）

2、IO操作优化

1. 数据倾斜
2. Map和Reduce数设置不合理
3. Map运行时间太长，导致Reduce等待的时间太久
4. 小文件
5. 大量不可切分的超大文件
6. spill溢写次数过多
7. merge次数过多

2、优化方法

我们可以从六个方面考虑优化问题

1. 数据输入
2. Map阶段
3. Reduce阶段
4. IO传输
5. 数据倾斜问题
6. 常用参数调优

2.1 数据输入

1. 合并小文件：在执行MR任务前将小文件进行合并，大量的小文件会产生大量的map任务，增大Map任务装载次数，而任务的装载比较耗时，从而导致MR运行较慢。
2. 采用CombineTextInputFormat来作为输入，解决输入端大量小文件场景。

2.2 Map阶段

1. 减少溢写次数：通过调整io.sort..mb及sort.spill.percent参数值，增大触发spill的内存上限，减少spill此书，从而减少磁盘IO。
2. 减少合并次数：通过调账io.sort.factor参数，增大merge的文件数目，减少merge的次数，从而缩短了MR处理时间。
3. 在Map之后，不影响业务逻辑前提下，先进行Combine处理，减少I/O。

2.3 Reduce阶段

1. 合理设置Map和Reduce数：两个都不能设置太少，也不能设置太多。太多会导致Task等待，延长处理时间；太多，会导致Map、Reduce任务间竞争资源，造成处理超时等错误。
2. 设置Map、Reduce共存：调整slowstart.completedmaps参数，使Map运行到一定程度后，Reduce也开始运行，减少Reduce的等待时间。
3. 规避使用Reduce：因为Reduce在用于连接数据集的时候将会产生大量的网络消耗。
4. 合理是设置Reduce端的Buffer：默认情况下，数据情况下，数据达到一个阈值的时候，Buffer中的数据就会写入磁盘，然后Reduce会从磁盘中获取所有的数据。也就是说，Buffer和Reduce是没有直接关联的，中间多次写磁盘->读磁盘的过程，既然有这个弊端，那么就可以通过参数来配置，使得Buffer中的一部分数据可以直接输送到Reduce，从而减少IO开销：mapreduce.reduce.input.buffer.percent，默认为0.0.当值大于0的时候，会保留指定比例的内存读Buffer中的数据直接拿给Reduce使用，这样一来，设置Buffer需要的内存，设置Buffer需要内存，读取数据需要内存，Reduce计算也要内存，所有要根据作业的运行情况进行调整。

2.4 I/O传输

1. 采用数据压缩的方式，减少网络IO的时间，安装snappy和LZO压缩编码器。
2. 使用SequenceFile二进制文件。

2.5 数据倾斜问题

1. 数据倾斜现象
   
   1. 数据频率倾斜——某一个区域的数据量要远远大于其他区域。
   2. 数据大小影斜——部分记录的大小远远大于平均值。
2. 减少数据倾斜的方法

Hadoop企业优化

标签：seq   直接   次数   瓶颈   性能   put   mapreduce   资源   completed   

原文地址：https://www.cnblogs.com/ssshhh/p/12164392.html