hadoop集群调优-hadoop settings and MapReduce

4 篇文章 0 订阅
2 篇文章 0 订阅

Hadoop Settings

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

 

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

 

Hard Drive scaling

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



 

 

Hadoop File System Compression

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

 

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

 

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

 

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

 

 

 

 

HDFS Block Size

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



 

 

MapReduce

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

 

HadoopMapReduce过程图如下所示:

 

 

 

 

 

MapReduce Process

 

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

 

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

 

InputSplits决定了MapReduce进程在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, sortreduceCopy阶段ReducerMap阶段的中间结果从TaskTracker(执行Map对应的DataNode)中拷贝过来(通过网络,HTTP),存放到本地磁盘或是内存中。这个过程中两个参数起作用,mapreduce.tasktracker.http.threadsmapred.reduce.parallel.copies。第一个参数指的是TaskTracker中用于在集群中提供传输DataNodespartition data服务的线程数量,默认40;第二个参数指的是在copyshuffle阶段Reducer进行拷贝数据的线程数量,默认为5

 

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

 

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

  • 大小: 66.1 KB
  • 大小: 72.4 KB
  • 大小: 139.8 KB
  • 大小: 197.3 KB
  • 大小: 146.9 KB
  • 大小: 171 KB
  • 大小: 106.8 KB
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值