hadoop性能调优--管理员角度二

hadoop参数调优

1.合理规划资源

1.设置合理的槽位数目

在hadoop中，计算资源是用槽位slot表示的。slot分为两种：map slot和reduce slot。每种slot代表一定量的资源，且同种slot代表的资源量是相同的。管理员需根据实际需要为TT配置一定数目的Map slot和Reduce slot，从而限制每个TT上并发执行的Map Task和Reduce Task数目。
+---------------------------------------++------------------------------------------------------------------------++
+ 0.20.x(包括1.x)，CDH3                       mapred.tasktracker.map.tasks.maximum            ++
+                                                                 mapred.tasktracker.reduce.tasks.maximum        ++
+ 0.21.x,0.22.x                                          mapreduce.tasktracker.map.tasks.maximum      ++
+                                                                 mapreduce.tasktracker.reduce.tasks.maximum  ++
+---------------------------------------++------------------------------------------------------------------------++

2.编写健康检测脚本

Hadoop允许管理员为每个TT配置一个节点健康状况监测脚本。TT中包含一个
专门的线程周期性执行该脚本，并将脚本执行结果通过心跳机制汇报给JT。
一旦JT发现某个TT的当前状况为“不健康”（比如内存或者CPU使用率过高），
则会将其加入黑名单，从此不再为它分配新的任务（当前正在执行的任务仍
会正常执行完毕），直到该脚本执行结果显示为“健康”。
该机制只有在Hadoop 0.20.2以上版本中有。

2.调整心跳配置

1.调整心跳间隔

TT与JT之间的心跳间隔大小应该适度。如果太小，JT需要处理高并发的心跳信息，势必造成不小的压力；
如果太大，则空闲的资源不能及时通知JT（进而为之分配新的Task），造成资源空闲，进而降低
系统吞吐率。对于中小规模（300个节点以下）的hadoop集群，缩短TT与JT之间的
心跳间隔可明显提高系统吞吐率。
在Hadoop1.0以及更低版本中，当节点集群规模小于300个节点时，心跳间隔
将一直是3秒（不能修改）。这意味着，如果你的集群有10个节点，那么JT
平均每秒只需处理3.3（10/3=3.3）个心跳请求；而如果你的集群有100个节点，
那么JT平均每秒也只需处理33个心跳请求。对于一台普通的服务器，这样的负载过低，
完全没有充分利用服务器资源。综上，对于中小规模的hadoop集群，3秒的心跳

间隔过大，管理员可根据需要适当减小心跳间隔

+----------------------+------------------------------------------------+-------------------------------------

+   hadoop版本号                 配置参数                                          默认值

+---------------------+-------------------------------------------------+--------------------------------------
+0.20.x,0.21.x,0.22.x  不可配置                                            +  集群规模小于300时，心跳间隔为3秒，
+                                                                                                +  之后每增加100个节点，则心跳间隔增加1秒
+----------------------+-------------------------------------------------+---------------------------------
+1.x,CDH 3              mapreduce.jobtracker.heartbeat.interval.min            +  集群规模小于300时，心跳间隔为300毫秒
+                                 mapred.heartbeats.second                                          +
+                                 mapreduce.jobtracker.heartbeats.scaling.factory    +
--------------------------------------------------------------------------------------------------------------

2.启用带外心跳

通常，心跳由各个TT以固定时间间隔为周期发送给JT的，心跳中包含节点资源
使用情况、各任务运行状态等信息。心跳机制是典型的pull-based模型。
TT周期性通过心跳向JT汇报信息，同时获取新的分配的任务。这种模型使得
任务分配过程存在较大延时：当TT出现空闲资源时，它只能通过下一次心跳
(对于不同规模的集群，心跳间隔不同，比如1000个节点的集群，心跳间隔为10秒钟)告诉JT，而不能立刻通知它。
为了减少任务分配延迟，Hadoop引入了带外心跳(out-of-band heartbeat)。
带外心跳不同于常规心跳，它是任务运行结束或者任务允许功能失败时触发的，
能够在出现空闲资源时第一时间通知JT，以便它能够迅速为空闲资源分配新的任务。
带外心跳的配置方法：

                                                       配置带外心跳

Hadoop版本号                               配置参数              含义                       默认值
0.20.2                                          未引入该机制                --                         --
0.20.x(除0.20.2),0.21.x,            mapreduce.tasktracker.   是否启用带外心跳        false
0.22.x,CDH 3                             outofband.heartbeat

3.磁盘块配置

Map Task中间结果要写到本地磁盘上，对于I/O密集型的任务来说，这部分数据会对
本地磁盘造成很大压力，管理员可通过配置多块磁盘缓解写压力。当存在多块
可用磁盘时，hadoop将采用轮询的方式将不同Map Task的中间结果写到这些磁盘上，
从而平摊负载，


                                  配置多个磁盘块
hadoop版本号                          配置参数                                       默认值
0.20.x(包括1.x),CDH 3           mapred.local.dir                           /tmp/hadoop-${user.name}/mapred/local
0.21.x,0.22.x                            mapreduce.cluster.local.dir       /tmp/hadoop-${user.name}/mapred/local

4.设置合理的RPC Handler和HTTP线程数目

（1）配置RPC Handler数目

JT需要并发处理来自各个TT的RPC请求，管理员可根据集群规模和服务器并发处理能够调整RPC Handler数目，
以使JT服务能力最佳：


配置RPC Handler数目
Hadoop版本号             配置参数                                  默认值
0.20.x(包括1x),cdh 3     mapred.job.tracker.handler.count           10
0.21.x，0.22.x           mapreduce.jobtracker.handler.count          10

（2）配置HTTP线程数目

在shuffle阶段，reduce task通过http请求从各个tt上读取map task 中间结果，而每个tt通过jetty server处理这些http请求。
管理员调整jetty server的工作线程数以提高jetty server的并发处理能力：
配置http线程数目
hadoop版本号              配置参数                           默认值
0.20.x,cdh3             tasktracker.http.threads               40
0.21.x,0.22.x           mapreduce.tasktracker.http.threads     40

5.慎用黑名单机制

当一个作业运行结束时，它会统计在各个tt上失败的任务数目。
如果一个tt失败的任务数目超过一定值，则作业会将它加到自己的黑名单中。
如果一个tt被一定数目的作业加入黑名单，则jt会将该tt加入系统黑名单，
此后jt不再为其分配新的任务，直到一定时间段内没有出现失败的任务。
当hadoop集群规模较小时，如果一定数量的节点被频繁加入系统黑名单中，
则会大大降低集群吞吐率和计算能力，因此建议关闭该功能。

6.启用批量任务调度

在hadoop中，调度器是最核心的组件之一，它负责将系统中空闲的资源分配给
各个任务。hadoop1.0中提供多种调度器，包括默认的FIFO调度器、Fair Scheduler、
Capacity Scheduler等，调度器的调度效率直接决定了系统的吞吐率高低。
通常而言，为了将空闲资源尽可能分配给任务，Hadoop调度器均支持批量任务调度，
即一次将所有空闲任务分配下去，而不是一次只分配一个，(FIFO调度器本身就是批量调度器)

7.选择合适的压缩算法

hadoop通常用于处理I/O密集型应用。Map Task会输出大量中间数据，
这些数据的读写对用户是透明的，如果能够支持中间数据压缩存储，则会明显提升
系统的I/O性能。当选择压缩算法时，需要考虑压缩比和压缩效率两个因素。
有的压缩算法有很好的压缩比，但压缩/解压缩效率很低；反之，有一些算法
压缩/解压缩效率很高，但压缩比很低。因此一个优秀的压缩算法需平衡压缩比和压缩效率两个因素。


当前有多种可选的压缩格式，比如gzip/zip/bzip2/LZO/Snappy等，
LZO和Snappy在压缩比和压缩效率方面都比较优秀。
Snappy是谷歌开源的数据压缩库，它的编码/解码器已经内置到Hadoop 1.0
以后的版本中；LZO则不同，它是基于GPL许可的，不能通过Apache来分发许可，
因此它的Hadoop编码/解码器必须单独下载。


在mapred-site.xml中配置如下可以压缩MapTask中间输出数据结果：
<property>
  <name>mapred.compress.map.output</name>
  <value>true</value>
</property>
<property>
 <name>mapred.map.output.compression.codec</name>
 <value>org.apache.hadoop.io.compress.SnappyCodec</value>
<property>
"mapred.compress.map.output"表示是否要压缩MapTask中间输出结果，
"mapred.map.output.compression.codec"表示采用的编码/解码器


在hadoop的0.20.x(不包括1.x),0.21.x，0.22.x没有内置Snappy
在hadoop的1.x,cdh 3中内置了Snappy


8.启用预读取机制
预读取机制可以有效提高磁盘的I/O读性能。由于hadoop是典型的顺序读系统，
采用预读取机制可明显提高hdfs读性能和mapreduce作业执行效率。管理员可为
mapreduce的数据拷贝和IFile文件读取启用预读取功能。


配置预读取功能
hadoop版本号                                          配置参数                                                                              含义                                          默认值
Apache各版本和CDH3 u3以下版本     暂未引入该机制                                                                     --                                                 --
  
                                                                     mapred.tasktracker.shuffle.fadvise                           是否启用Shuffle预读取机制          true
                                             mapred.tasktracker.shuffle.readahead.bytes          Shuffle预读取缓冲区大小           4MB
CDH3 u3以及更高版本     mapreduce.ifile.readahead                                         是否启用IFile预读取机制           true
                                             mapreduce.ifile.readahead.bytes                              IFile预读取缓冲区大小             4MB