hadoop集群调优－hadoop settings and MapReduce

Hadoop Settings

由于Hadoop节点的系统配置，一些hadoop的设置可以减少运行系统中的瓶颈。首先，提高Java运行时的堆内存容量，也要和系统中的整体内存容量相关；其次，保持hadoop中派生的task数量与处理器数量相关。

 

一个比较好的规则是一个Reducer或两个Mapper分配一个处理器；如果系统拥有足够多的内存容量，设置Java堆的最大大小为1GB或更大。此外，还需要注意的是一个任务要有3个Java虚拟机在运行，所以必要还要至少保留每个任务3GB的内存，

 

Hard Drive scaling

Hadoop DataNode中的硬盘数量能够提高读写性能，将数据放到更多的硬盘中能够允许hadoop从多个HDFS数据块中读取更多的数据。Hadoop的工作量就像是RAID控制器一样，能够同时从多个地址中读取数据，可以提高整体的性能。从基本测试的执行结果来看，更多的磁盘数量能够显著提高hadoop的读写性能，直到存储的总线达到饱和状态。在我们的每个DataNode中，都添加了12块硬盘。从下图中可以看出，从4块硬盘开始，直到加入第12块硬盘，整体的执行时间减少了大约79%。

 

 

Hadoop File System Compression

在Hadoop中启用压缩可以通过减少网络和磁盘IO来提高集群的性能，同样还可以降低HDFS中的磁盘使用率，但是这部分提升是以CPU处理时间的提高为代价的，需要考虑到CPU和IO之间的权衡问题。

 

Hadoop提供了对中间map执行结果，map输入数据和reduce输出数据的压缩支持，同时还支持应用级别的压缩，比如Java Job本身，支持的压缩方法包括：Deflate, gzip, bzip2和LZO。每种方法都有其优缺点。

 

MapReduce输出的数据在整个计算过程中都会进行中间存储，map输出的中间结果只能被reducer看到（通过HTTP服务的方式下载）。因为map和reduce端的可能并不在同一台机器，同一个进程中，压缩数据能够节省网络带宽和磁盘I/O。

 

LZO通常情况下不是处理器敏感的算法，花费大约20%到40%的CPU处理能力，能够留给在系统中运行的其他Hadoop任务足够的CPU资源；而且LZO是可Split的，将比较大的文件拆分成可管理的块。当使用压缩时，建议使用可Split和Index整个文件的算法，否则本地化文件的不支持可能导致MapReduce应用非常低效。使用压缩相比于未压缩能够减少大概20%的执行时间。

 

 

 

 

HDFS Block Size

更改默认的HDFS块大小在两个方面提高Hadoop集群的性能。首先，它能够比最佳地匹配硬件驱动attach的控制器，提升硬件驱动器和存储控制器。其次，HDFS的块大小会影响单个MapReduce Job的任务数量，在文件总大小固定的情况下，提高HDFS的块大小会减少MapReduce的Task数量。

 

 

MapReduce

MapReduce比起HDFS设置，要更加复杂，需要了解所有的MapReduce配置参数，才能做到提高性能。

 

Hadoop的MapReduce过程图如下所示：

 

 

 

 

 

MapReduce Process

 

MapReduce的任务由两阶段组成，Map阶段和Reduce阶段。

 

Map阶段会将任务和数据分发到集群的数据节点中，大部分的Map任务都可以在对应的DataNode上被创建。为了能够在Map阶段达到最大的性能，需要有效利用DataNodes上的所有处理器核心。

 

InputSplits决定了Map和Reduce进程在DataNodes中被创建的数量。每个Map进程使用map方法处理输入数据，将其按照数据进行分组，根据Partition策略写到Map端的本地磁盘中，以便于Reducer能够拿来进行map输出。

 

Map执行时，对于一个给定的Key，如果Partition到特定的Reducer，则这个Reducer需要能够看到所有的Map上这个Key对应的结果，并通过HTTP的方式获得这些中间结果数据。在Reducer方法被执行之前，首先在Reducer端执行数据的排序合并操作。

 

如果能够保持Map阶段和Reduce阶段都在同一个节点，就可以最小化传输的数据，并加速执行时间。

 

 

Map Process

Map阶段是从InputSplit开始，当Map阶段执行进程的map方法将中间结果数据写入到本地磁盘中时，它使用的一个内存缓冲区，通过io.sort.mb来控制缓冲区的大小（默认100M，一般不够用），这部分内存是要占用Map端执行的虚拟机内存的。

 

另外一个与io.sort.mb设置共存的参数是io.sort.record.percent，这个代表内存缓冲区用于元数据的百分比（相对于记录的本身信息），默认值为.05，表示百分之五。如果内存缓冲区的空间已经使用超过80%后（在参数io.sort.spill.percent），就会新启动一个线程用户将数据缓冲至本地磁盘中，但并不耽误map方法继续向内存缓冲区写入操作。

 

如果Map阶段的输出数据非常大，频繁的文件spill就会导致map阶段执行时间的变长。适当地增大内存缓冲区，使得map操作能够都在内存中完成能够节省大部分时间，这都是因为如果spill次数太多，会在磁盘中大量执行磁盘归并的操作，将不同的小文件合并成一个文件。

 

 

Reduce Process

Reduce阶段是由5个步骤组成，copy, shuffle, merge, sort和reduce。Copy阶段Reducer将Map阶段的中间结果从TaskTracker（执行Map对应的DataNode）中拷贝过来（通过网络，HTTP），存放到本地磁盘或是内存中。这个过程中两个参数起作用，mapreduce.tasktracker.http.threads和mapred.reduce.parallel.copies。第一个参数指的是TaskTracker中用于在集群中提供传输DataNodes和partition data服务的线程数量，默认40；第二个参数指的是在copy和shuffle阶段Reducer进行拷贝数据的线程数量，默认为5。

 

Map处理完的数据被拷贝到Reducer的内存中，其内存数量被两个参数所控制——mapred.job.shuffle.input.buffer.percent（默认0.70）和mapred.child.java.opts（-Xmx200）。增大Reducer端的Java堆内存，提升至1G，如果内存比较充裕的化可以提升得更高，这样就可以使得copy，shuffle和merge三部分操作都在内存中，这样就可以提高MapReduce的性能。如果copy，shuffle和merge三部分操作仍然溢出至磁盘中，可以更改参数mapred.job.shuffle.merge.percent（默认0.66），类似于之前map端的溢出百分比，这决定了Reduce端copy，shuffle和merge的记录数溢出百分比。

 

io.sort.factor，这个参数决定了Map 阶段输出流一次能够合并的文件数量，这取决于Reducer处理merged文件的速度。增大这个参数能够将merged文件移动到Reducer更快。

 

更改参数mapred.job.reduce.input.buffer.percent（默认0.0）能够将merged文件放到内存中，以提高处理速度，需要说明的是，这部分内存也来源于Reducer阶段的Java虚拟机，如果Reduce阶段不是太耗内存，可以将所有中间处理结果都放到内存中。

 

 

 

 

Summary

 

通过设置在Hadoop框架中的这些优化策略，我们可以发现最终会得到大概38%的执行时间降低百分比。更改这些同时也会对其他造成一些有益的影响，比如由于进行了压缩，降低HDFS的磁盘占用率，支持更大的Hadoop工作负载。