Hadoop离线_MapReduce参数优化

资源相关参数

• mapred-site.xml中的配置

**mapreduce.map.memory.mb**
一个 MapTask 可使用的资源上限（单位:MB），默认为1024
如果 MapTask 实际使用的资源量超过该值，则会被强制杀死。

**mapreduce.reduce.memory.mb**
一个 ReduceTask 可使用的资源上限（单位:MB），默认为1024
如果 ReduceTask 实际使用的资源量超过该值，则会被强制杀死。

**mapred.child.java.opts**
配置每个 map 或者 reduce 使用的内存的大小，默认是200M

**mapreduce.map.cpu.vcores**
每个 MapTask 可使用的最多 cpu Core 数目, 默认值: 1

**mapreduce.reduce.cpu.vcores**
每个 ReduceTask 可使用的最多 cpu Core 数目, 默认值: 1
最后两个vcores指的是virtual core/虚拟核处理器

 注：剩下两个参数要在yarn集群启动之前配置

**mapreduce.task.io.sort.mb**
shuffle的环形缓冲区大小，默认 100M

**mapreduce.map.sort.spill.percent**
环形缓冲区溢出的阈值，默认 80%
 

• yarn-site.xml中的配置（在yarn集群启动之前进行配置）

**yarn.scheduler.minimum-allocation-mb**
给应用程序container分配的最小内存，默认 1024M

**yarn.scheduler.maximum-allocation-mb**
给应用程序container分配的最大内存，默认 8192M

**yarn.scheduler.minimum-allocation-vcores**
container最小的虚拟内核的个数，默认 1个

**yarn.scheduler.maximum-allocation-vcores**
container最大的虚拟内核的个数，默认 32个

**yarn.nodemanager.resource.memory-mb**
给每个nodemanager的内存资源，默认 8192M

容错相关参数

**mapreduce.map.maxattempts**
每个Map Task最大重试次数，一旦重试参数超过该值，则认为Map Task运行失败，默认值：4

**mapreduce.reduce.maxattempts**
每个Reduce Task最大重试次数，一旦重试参数超过该值，则认为Map Task运行失败，默认值：4

**mapreduce.job.maxtaskfailures.per.tracker**
当失败的 MapTask 失败比例超过该值时，整个作业则失败，默认值为 0
如果你的应用程序允许丢弃部分输入数据，则该该值设为一个大于0的值。
比如5，表示如果有低于5%的MapTask失败，整个作业仍认为成功。

**mapreduce.task.timeout**
Task超时时间，默认值为600000毫秒（经常需要设置的一个参数）
该参数表达的意思为：如果一个task在一定时间内没有任何进入，即不会读取新的数据，也没有输出数据，则认为该task处于block状态，可能是卡住了
为了防止因为用户程序永远block住不退出，则强制设置了一个该超时时间。如果你的程序对每条输入数据的处理时间过长（比如会访问数据库，通过网络拉取数据等），建议将该参数调大.
该参数过小常出现的错误提示是AttemptID:attempt_14267829456721_123456_m_000224_0 Timed out after 300 secsContainer killed by the ApplicationMaster.

• 一般一个任务长时间没有完成，可能是因为数据倾斜造成的
  数据倾斜：大量的数据都涌到同一个reduceTask里面去，造成一个reduceTask里面处理得数据量太大，迟迟不能完成。比如，reduceTakss完成80%就不动了，很有可能就是发生了数据倾斜。

效率和稳定性相关参数

**mapreduce.map.speculative**
是否为Map Task打开推测执行机制，默认为true。
如果Map执行时间比较长，那么集群就会推测这个Map已经卡住了，会重新启动同样的Map进行并行的执行，哪个先执行完了，就采取哪个的结果来作为最终结果
**mapreduce.reduce.speculative**
是否为Reduce Task打开推测执行机制，默认为true。
如果reduce执行时间比较长，那么集群就会推测这个reduce已经卡住了，会重新启动同样的reduce进行并行的执行，哪个先执行完了，就采取哪个的结果来作为最终结果