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工作负载。