Hadoop 学习笔记之参数调优手册

[atguigu@hadoop102 ~]$ sudo yum install -y python
[atguigu@hadoop102 ~]$ python
Python 2.7.5 (default, Apr 11 2018, 07:36:10) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-28)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> print int(20*math.log(3))
21
>>> quit()

hdfs-site.xml 参数设置

<property>
<name>dfs.namenode.handler.count</name>
<value>21</value>
</property>

3、开启回收站配置

开启回收站功能，可以将删除的文件在不超时的情况下，恢复原数据，起到防止误删除、备份等作用。

1）开启回收站功能参数说明

默认值 fs.trash.interval = 0，0表示禁用回收站；其他值表示设置文件的存活时间。
默认值 fs.trash.checkpoint.interval = 0，检查回收站的间隔时间。如果该值为0，则该值设置和fs.trash.interval的参数值相等。
要求fs.trash.checkpoint.interval <= fs.trash.interval。

2）启用回收站

修改 core-site.xml，配置垃圾回收时间为1分钟。

<property>
<name>fs.trash.interval</name>
<value>1</value>
</property>

回收站目录在 HDFS 集群中的路径：/user/test/.Trash/….

3）恢复回收站数据

hadoop fs -mv /user/test/.Trash/Current/user/test/input /user/test/input

注意：

只有在命令行利用 hadoop fs -rm 命令删除的文件才会走回收站。
通过程序删除的文件不会经过回收站，需要调用 moveToTrash() 才进入回收站
通过网页上直接删除的文件也不会走回收站。

二、HDFS—集群压测

为了搞清楚HDFS的读写性能，非常需要对集群进行压测

HDFS的读写性能主要受网络和磁盘影响比较大。为了方便测试，将hadoop102、hadoop103、hadoop104虚拟机网络都设置为100mbps

100Mbps单位是bit；10M/s单位是byte ; 1byte=8bit，100Mbps/8=12.5M/s。

测试网速：来到hadoop102的/opt/module目录，创建一个

python -m SimpleHTTPServer

1、测试 HDFS 写性能

1）测试内容：向 HDFS 集群写10个128M的文件

hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -write -nrFiles 10 -fileSize 128MB

注意：nrFiles n为生成mapTask的数量，生产环境一般可通过hadoop103:8088查看CPU核数，设置为（CPU核数 - 1）

2）注意：如果测试过程中，出现异常

可以在yarn-site.xml中设置虚拟内存检测为false

<property>
<name>yarn.nodemanager.vmem-check-enabled</name>
<value>false</value>
</property>

3）测试结果分析

Number of files：生成mapTask数量，一般是集群中（CPU核数-1），我们测试虚拟机就按照实际的物理内存-1分配即可
Total MBytes processed：单个map处理的文件大小
Throughput mb/sec:单个mapTak的吞吐量；计算方式：处理的总文件大小/每一个mapTask写数据的时间累加；集群整体吞吐量：生成mapTask数量*单个mapTak的吞吐量
Average IO rate mb/sec::平均mapTak的吞吐量；计算方式：每个mapTask处理文件大小/每一个mapTask写数据的时间，全部相加除以task数量
IO rate std deviation: 方差、反映各个 mapTask 处理的差值，越小越均衡

由于副本1就在本地，所以该副本不参与测试

一共参与测试的文件：10个文件 * 2个副本 = 20个

压测后的速度：1.61

实测速度：1.61M/s * 20个文件 ≈ 32M/s

三台服务器的带宽：12.5 + 12.5 + 12.5 ≈ 30m/s

所有网络资源都已经用满。

如果实测速度远远小于网络，并且实测速度不能满足工作需求，可以考虑采用固态硬盘或者增加磁盘个数。

2、测试HDFS读性能

1）测试内容：读取HDFS集群10个128M的文件

hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -read -nrFiles 10 -fileSize 128MB

三、HDFS—集群扩容及缩容

1、添加白名单

白名单：表示在白名单的主机IP地址可以用来存储数据，可以尽量防止黑客恶意访问攻击。

配置白名单步骤如下：

1）在NameNode节点的/opt/module/hadoop-3.1.3/etc/hadoop目录下分别创建whitelist 和blacklist文件

[test@hadoop102 hadoop]$ vim whitelist

[test@hadoop102 hadoop]$ touch blacklist

在whitelist中添加如下主机名称，假如集群正常工作的节点为102 103

hadoop102
hadoop103

2）在hdfs-site.xml配置文件中增加dfs.hosts配置参数

<property>
<name>dfs.hosts</name>
<value>/opt/module/hadoop-3.1.3/etc/hadoop/whitelist</value>
</property>


<property>
<name>dfs.hosts.exclude</name>
<value>/opt/module/hadoop-3.1.3/etc/hadoop/blacklist</value>
</property>

3）分发配置文件whitelist，hdfs-site.xml
4）第一次添加白名单必须重启集群，不是第一次，只需要刷新NameNode节点即可
5）在web浏览器上查看DN，http://hadoop102:9870/dfshealth.html#tab-datanode
6）在hadoop104上执行上传数据数据失败
7）二次修改白名单，增加hadoop104
8）刷新NameNode
9）在web浏览器上查看DN，http://hadoop102:9870/dfshealth.html#tab-datanode

2、服役新服务器

在原有集群基础上动态添加新的数据节点

在hadoop100主机上再克隆一台hadoop105主机
修改IP地址和主机名称
拷贝hadoop102的/opt/module目录和/etc/profile.d/my_env.sh到hadoop105
删除hadoop105上Hadoop的历史数据，data和log数据
配置hadoop102和hadoop103到hadoop105的ssh无密登录
直接启动DataNode，即可关联到集群

3、服务器间数据均衡

如果经常在固定几台服务器上提交任务，且副本数为2，由于数据本地性原则，就会导致那几台数据过多，其余服务器存储的数据量少；并且新服役的服务器数据量比较少，需要执行集群均衡命令

开启数据均衡命令：

[tset@hadoop105 hadoop-3.1.3]$ sbin/start-balancer.sh -threshold 10

对于参数10，代表的是集群中各个节点的磁盘空间利用率相差不超过10%，可根据实际情况进行调整。

停止数据均衡命令：

[tset@hadoop105 hadoop-3.1.3]$ sbin/stop-balancer.sh

注意：由于HDFS需要启动单独的Rebalance Server来执行Rebalance操作，所以尽量不要在NameNode上执行start-balancer.sh，而是找一台比较空闲的机器。

4、黑名单退役服务器

黑名单：表示在黑名单的主机IP地址不可以，用来存储数据；用来退役服务器。

黑名单配置步骤如下：

编辑 blacklist 文件，添加主机名称（要退役的节点）
分发配置文件blacklist，hdfs-site.xml
第一次添加黑名单必须重启集群，不是第一次，只需要刷新NameNode节点即可（hdfs dfsadmin -refreshNodes）
检查Web浏览器，退役节点的状态为decommission in progress（退役中），说明数据节点正在复制块到其他节点
等待退役节点状态为decommissioned（所有块已经复制完成），停止该节点及节点资源管理器。注意：如果副本数是3，服役的节点小于等于3，是不能退役成功的，需要修改副本数后才能退役
如果数据不均衡，可以用命令实现集群的再平衡

四、HDFS—存储优化

1、纠删码

1）纠删码原理

HDFS默认情况下，一个文件有3个副本，这样提高了数据的可靠性，但也带来了2倍的冗余开销。Hadoop3.x引入了纠删码，采用计算的方式，可以节省约50％左右的存储空间。

1）纠删码操作相关的命令

[test@hadoop102 hadoop-3.1.3]$ hdfs ec
Usage: bin/hdfs ec [COMMAND]
[-listPolicies]
[-addPolicies -policyFile <file>]
[-getPolicy -path <path>]
[-removePolicy -policy <policy>]
[-setPolicy -path <path> [-policy <policy>] [-replicate]]
[-unsetPolicy -path <path>]
[-listCodecs]
[-enablePolicy -policy <policy>]
[-disablePolicy -policy <policy>]
[-help <command-name>].

2）查看当前支持的纠删码策略

[test@hadoop102 hadoop-3.1.3] hdfs ec -listPolicies

Erasure Coding Policies:
ErasureCodingPolicy=[Name=RS-10-4-1024k, Schema=[ECSchema=[Codec=rs, numDataUnits=10, numParityUnits=4]], CellSize=1048576, Id=5], State=DISABLED

ErasureCodingPolicy=[Name=RS-3-2-1024k, Schema=[ECSchema=[Codec=rs, numDataUnits=3, numParityUnits=2]], CellSize=1048576, Id=2], State=DISABLED

ErasureCodingPolicy=[Name=RS-6-3-1024k, Schema=[ECSchema=[Codec=rs, numDataUnits=6, numParityUnits=3]], CellSize=1048576, Id=1], State=ENABLED

ErasureCodingPolicy=[Name=RS-LEGACY-6-3-1024k, Schema=[ECSchema=[Codec=rs-legacy, numDataUnits=6, numParityUnits=3]], CellSize=1048576, Id=3], State=DISABLED

ErasureCodingPolicy=[Name=XOR-2-1-1024k, Schema=[ECSchema=[Codec=xor, numDataUnits=2, numParityUnits=1]], CellSize=1048576, Id=4], State=DISABLED

3）纠删码策略解释:

RS-3-2-1024k：使用RS编码，每3个数据单元，生成2个校验单元，共5个单元，也就是说：这5个单元中，只要有任意的3个单元存在（不管是数据单元还是校验单元，只要总数=3），就可以得到原始数据。每个单元的大小是1024k=1024*1024=1048576。
RS-10-4-1024k：使用RS编码，每10个数据单元（cell），生成4个校验单元，共14个单元，也就是说：这14个单元中，只要有任意的10个单元存在（不管是数据单元还是校验单元，只要总数=10），就可以得到原始数据。每个单元的大小是1024k=1024*1024=1048576。
RS-6-3-1024k：使用RS编码，每6个数据单元，生成3个校验单元，共9个单元，也就是说：这9个单元中，只要有任意的6个单元存在（不管是数据单元还是校验单元，只要总数=6），就可以得到原始数据。每个单元的大小是1024k=1024*1024=1048576。
RS-LEGACY-6-3-1024k：策略和上面的RS-6-3-1024k一样，只是编码的算法用的是rs-legacy。
XOR-2-1-1024k：使用XOR编码（速度比RS编码快），每2个数据单元，生成1个校验单元，共3个单元，也就是说：这3个单元中，只要有任意的2个单元存在（不管是数据单元还是校验单元，只要总数= 2），就可以得到原始数据。每个单元的大小是1024k=1024*1024=1048576。

2）纠删码案例实操

纠删码策略是给具体一个路径设置。所有往此路径下存储的文件，都会执行此策略。

默认只开启对RS-6-3-1024k策略的支持，如要使用别的策略需要提前启用。

将/input目录设置为RS-3-2-1024k策略，具体步骤

（1）开启对RS-3-2-1024k策略的支持
        [test@hadoop102 hadoop-3.1.3]$ hdfs ec -enablePolicy -policy RS-3-2-1024k
        Erasure coding policy RS-3-2-1024k is enabled
（2）在HDFS创建目录，并设置RS-3-2-1024k策略
        [test@hadoop102 hadoop-3.1.3]$ hdfs dfs -mkdir /input
        [test@hadoop202 hadoop-3.1.3]$ hdfs ec -setPolicy -path /input -policy RS-3-2-1024k
（3）上传文件，并查看文件编码后的存储情况
        [test@hadoop102 hadoop-3.1.3]$ hdfs dfs -put web.log /input
        注：你所上传的文件需要大于2M才能看出效果。（低于2M，只有一个数据单元和两个校验单元）
（4）查看存储路径的数据单元和校验单元，并作破坏实验

2、异构存储（冷热数据分离）

异构存储主要解决，不同的数据，存储在不同类型的硬盘中，达到最佳性能的问题。

1）存储类型

RAM_DISK：（内存镜像文件系统）
SSD：（SSD固态硬盘）
DISK：（普通磁盘，在HDFS中，如果没有主动声明数据目录存储类型默认都是DISK）
ARCHIVE：（没有特指哪种存储介质，主要的指的是计算能力比较弱而存储密度比较高的存储介质，用来解决数据量的容量扩增的问题，一般用于归档）

2）存储策略

3）异构存储Shell操作

（1）查看当前有哪些存储策略可以用
        hdfs storagepolicies -listPolicies
（2）为指定路径（数据存储目录）设置指定的存储策略
        hdfs storagepolicies -setStoragePolicy -path xxx -policy xxx
（3）获取指定路径（数据存储目录或文件）的存储策略
        hdfs storagepolicies -getStoragePolicy -path xxx
（4）取消存储策略；执行改命令之后该目录或者文件，以其上级的目录为准，如果是根目录，那么就是HOT
        hdfs storagepolicies -unsetStoragePolicy -path xxx
（5）查看文件块的分布
        bin/hdfs fsck xxx -files -blocks -locations
（6）查看集群节点
        hadoop dfsadmin -report

五、HDFS—故障排除

1、NameNode故障处理

1）NameNode进程挂了并且存储的数据也丢失了，如何恢复NameNode

故障模拟：

kill -9 NameNode进程；
删除NameNode存储的数据（/opt/module/hadoop-3.1.3/data/tmp/dfs/name）

解决问题：

拷贝SecondaryNameNode中数据到原NameNode存储数据目录
重新启动NameNode

2、集群安全模式&磁盘修复

安全模式：文件系统只接受读数据请求，而不接受删除、修改等变更请求

1）进入安全模式场景

NameNode在加载镜像文件和编辑日志期间处于安全模式；
NameNode再接收DataNode注册时，处于安全模式

2）退出安全模式条件

dfs.namenode.safemode.min.datanodes:最小可用datanode数量，默认0
dfs.namenode.safemode.threshold-pct:副本数达到最小要求的block占系统总block数的百分比，默认0.999f。（只允许丢一个块）
dfs.namenode.safemode.extension:稳定时间，默认值30000毫秒，即30秒

3）集群处于安全模式，不能执行重要操作（写操作）。集群启动完成后，自动退出安全模式

bin/hdfs dfsadmin -safemode get   （功能描述：查看安全模式状态）
bin/hdfs dfsadmin -safemode enter （功能描述：进入安全模式状态）
bin/hdfs dfsadmin -safemode leave   （功能描述：离开安全模式状态）
bin/hdfs dfsadmin -safemode wait   （功能描述：等待安全模式状态）

磁盘修复：数据块损坏，进入安全模式

删除元数据或者联系产商修复数据

3、慢磁盘监控

“慢磁盘”指的时写入数据非常慢的一类磁盘。其实慢性磁盘并不少见，当机器运行时间长了，上面跑的任务多了，磁盘的读写性能自然会退化，严重时就会出现写入数据延时的问题。

找出慢磁盘方法：

1）通过心跳未联系时间

一般出现慢磁盘现象，会影响到DataNode与NameNode之间的心跳。正常情况心跳时间间隔是3s。超过3s说明有异常

2）fio命令，测试磁盘的读写性能

顺序读测试

sudo fio -filename=/home/test/test.log -direct=1 -iodepth 1 -thread -rw=read -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_r

顺序写测试

sudo fio -filename=/home/test/test.log -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_w

随机写测试

sudo fio -filename=/home/test/test.log -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_randw

混合随机读写

sudo fio -filename=/home/atguigu/test.log -direct=1 -iodepth 1 -thread -rw=randrw -rwmixread=70 -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_r_w -ioscheduler=noop

4、小文件归档

1）HDFS存储小文件弊端

每个文件均按块存储，每个块的元数据存储在NameNode的内存中，因此HDFS存储小文件会非常低效。因为大量的小文件会耗尽NameNode中的大部分内存。但注意，存储小文件所需要的磁盘容量和数据块的大小无关。例如，一个1MB的文件设置为128MB的块存储，实际使用的是1MB的磁盘空间，而不是128MB。

2）解决存储小文件办法之一

HDFS存档文件或HAR文件，是一个更高效的文件存档工具，它将文件存入HDFS块，在减少NameNode内存使用的同时，允许对文件进行透明的访问。具体说来，HDFS存档文件对内还是一个一个独立文件，对NameNode而言却是一个整体，减少了NameNode的内存。

归档文件：把/input目录里面的所有文件归档成一个叫input.har的归档文件，并把归档后文件存储到/output路径下

hadoop archive -archiveName input.har -p /input /output

查看归档

hadoop fs -ls /output/input.har

hadoop fs -ls har:///output/input.har

解归档文件

hadoop fs -cp har:///output/input.har/* /

六、MapReduce生产经验

1、MapReduce 任务跑的慢的原因

计算机性能：CPU、内存、磁盘、网络

I/O操作优化：数据倾斜、Map运行时间太长，导致Reduce等待过久、小文件过多

2、MapReduce常用调优参数

1）自定义分区，减少数据倾斜;
        定义类，继承Partitioner接口，重写getPartition方法
2）减少溢写的次数
        mapreduce.task.io.sort.mb
        Shuffle的环形缓冲区大小，默认100m，可以提高到200m
        mapreduce.map.sort.spill.percent
        环形缓冲区溢出的阈值，默认80% ，可以提高的90%
3）增加每次Merge合并次数
        mapreduce.task.io.sort.factor默认10，可以提高到20
4）在不影响业务结果的前提条件下可以提前采用Combiner
        job.setCombinerClass(xxxReducer.class);
5）为了减少磁盘IO，可以采用Snappy或者LZO压缩
        conf.setBoolean("mapreduce.map.output.compress", true);
        conf.setClass("mapreduce.map.output.compress.codec",         SnappyCodec.class,CompressionCodec.class);
6）mapreduce.map.memory.mb
        默认MapTask内存上限1024MB。可以根据128m数据对应1G内存原则提高该内存。
7）mapreduce.map.java.opts：
        控制MapTask堆内存大小。（如果内存不够，报：java.lang.OutOfMemoryError）
8）mapreduce.map.cpu.vcores
        默认MapTask的CPU核数1。计算密集型任务可以增加CPU核数
9）异常重试
        mapreduce.map.maxattempts每个Map Task最大重试次数，一旦重试次数超过该值，则认为Map Task运行失败，默认值：4。根据机器性能适当提高。

1）mapreduce.reduce.shuffle.parallelcopies
        每个Reduce去Map中拉取数据的并行数，默认值是5。可以提高到10。
2）mapreduce.reduce.shuffle.input.buffer.percent
        Buffer大小占Reduce可用内存的比例，默认值0.7。可以提高到0.8
3）mapreduce.reduce.shuffle.merge.percent
        Buffer中的数据达到多少比例开始写入磁盘，默认值0.66。可以提高到0.75
4）mapreduce.reduce.memory.mb
        默认ReduceTask内存上限1024MB，根据128m数据对应1G内存原则，适当提高内存到4-6G
5）mapreduce.reduce.java.opts：
        控制ReduceTask堆内存大小。（如果内存不够，报：java.lang.OutOfMemoryError）
6）mapreduce.reduce.cpu.vcores
        默认ReduceTask的CPU核数1个。可以提高到2-4个
7）mapreduce.reduce.maxattempts
        每个Reduce Task最大重试次数，一旦重试次数超过该值，则认为Map Task运行失败，默认值：4。
8）mapreduce.job.reduce.slowstart.completedmaps
        当MapTask完成的比例达到该值后才会为ReduceTask申请资源。默认是0.05。
9）mapreduce.task.timeout
        如果一个Task在一定时间内没有任何进入，即不会读取新的数据，也没有输出数据，则认为该Task处于Block状态，可能是卡住了，也许永远会卡住，为了防止因为用户程序永远Block住不退出，则强制设置了一个该超时时间（单位毫秒），默认是600000（10分钟）。如果你的程序对每条输入数据的处理时间过长，建议将该参数调大。
10）如果可以不用Reduce，尽可能不用

3、MapReduce数据倾斜问题

1）数据倾斜现象

数据频率倾斜——某一个区域的数据量要远远大于其他区域。

数据大小倾斜——部分记录的大小远远大于平均值。

2）减少数据倾斜的方法

首先检查是否空值过多造成的数据倾斜。过滤空值、自定义分区，将空值加随机数打散。最后再二次聚合
能在map阶段提前处理，最好先在Map阶段处理。如：Combiner、MapJoin
设置多个reduce个数

七、Hadoop综合调优

1、Hadoop小文件优化方法

1）Hadoop小文件弊端

HDFS上每个文件都要在NameNode上创建对应的元数据，这个元数据的大小约为150byte，这样当小文件比较多的时候，就会产生很多的元数据文件，一方面会大量占用NameNode的内存空间，另一方面就是元数据文件过多，使得寻址索引速度变慢。

小文件过多，在进行MR计算时，会生成过多切片，需要启动过多的MapTask。每个MapTask处理的数据量小，导致MapTask的处理时间比启动时间还小，白白消耗资源。

2）Hadoop小文件解决方案

① 在数据采集的时候，就将小文件或小批数据合成大文件再上传HDFS（数据源头）

② Hadoop Archive（存储方向）
是一个高效的将小文件放入HDFS块中的文件存档工具，能够将多个小文件打包成一个HAR文件，从而达到减少NameNode的内存使用

③ CombineTextInputFormat（计算方向）
CombineTextInputFormat用于将多个小文件在切片过程中生成一个单独的切片或者少量的切片。

④ 开启uber模式，实现JVM重用（计算方向）
默认情况下，每个Task任务都需要启动一个JVM来运行，如果Task任务计算的数据量很小，我们可以让同一个Job的多个Task运行在一个JVM中，不必为每个Task都开启一个JVM。

uber 模式测试：

未开启uber模式，在/input路径上上传5个小文件并执行wordcount程序

hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar wordcount /input /output

观察控制台日志

INFO mapreduce.Job: Job job_1613281510851_0002 running in uber mode : false

观察8088开启了 5 个容器

开启uber模式，在mapred-site.xml中添加如下配置

<property>
   <name>mapreduce.job.ubertask.enable</name>
   <value>true</value>
</property>


<property>
   <name>mapreduce.job.ubertask.maxmaps</name>
   <value>9</value>
</property>

<property>
   <name>mapreduce.job.ubertask.maxreduces</name>
   <value>1</value>
</property>

<property>
   <name>mapreduce.job.ubertask.maxbytes</name>
   <value></value>
</property>

再次执行wordcount程序

观察控制台

INFO mapreduce.Job: Job job_1613281510851_0003 running in uber mode : true

观察8088，只开起了一个容器

八、开发场景案例

1、需求

从1G数据中，统计每个单词出现次数。服务器3台，每台配置4G内存，4核CPU，4线程

需求分析：

1G / 128m = 8个MapTask；1个ReduceTask；1个mrAppMaster

平均每个节点运行10个 / 3台 ≈ 3个任务（4 3 3）

2、 HDFS参数调优

1）修改：hadoop-env.sh

export HDFS_NAMENODE_OPTS="-Dhadoop.security.logger=INFO,RFAS -Xmx1024m"
export HDFS_DATANODE_OPTS="-Dhadoop.security.logger=ERROR,RFAS -Xmx1024m"

2）修改hdfs-site.xml

<property>
<name>dfs.namenode.handler.count</name>
<value>21</value>
</property>

3）修改core-site.xml

<property>
<name>fs.trash.interval</name>
<value>60</value>
</property>

3、MapReduce参数调优

1）修改mapred-site.xml

<property>
<name>mapreduce.task.io.sort.mb</name>
<value>100</value>
</property>


<property>
<name>mapreduce.map.sort.spill.percent</name>
<value>0.80</value>
</property>


<property>
<name>mapreduce.task.io.sort.factor</name>
<value>10</value>
</property>


<property>
<name>mapreduce.map.memory.mb</name>
<value>-1</value>
<description>The amount of memory to request from the scheduler for each map task. If this is not specified or is non-positive, it is inferred from mapreduce.map.java.opts and mapreduce.job.heap.memory-mb.ratio. If java-opts are also not specified, we set it to 1024.
</description>
</property>


<property>
<name>mapreduce.map.cpu.vcores</name>
<value>1</value>
</property>


<property>
<name>mapreduce.map.maxattempts</name>
<value>4</value>
</property>


<property>
<name>mapreduce.reduce.shuffle.parallelcopies</name>
<value>5</value>
</property>


<property>
<name>mapreduce.reduce.shuffle.input.buffer.percent</name>
<value>0.70</value>
</property>


<property>
<name>mapreduce.reduce.shuffle.merge.percent</name>
<value>0.66</value>
</property>


<property>
<name>mapreduce.reduce.memory.mb</name>
<value>-1</value>
<description>The amount of memory to request from the scheduler for each reduce task. If this is not specified or is non-positive, it is inferred
from mapreduce.reduce.java.opts and mapreduce.job.heap.memory-mb.ratio.
If java-opts are also not specified, we set it to 1024.
</description>
</property>


<property>
<name>mapreduce.reduce.cpu.vcores</name>
<value>2</value>
</property>


<property>
<name>mapreduce.reduce.maxattempts</name>
<value>4</value>
</property>


<property>
<name>mapreduce.job.reduce.slowstart.completedmaps</name>
<value>0.05</value>
</property>


<property>
<name>mapreduce.task.timeout</name>
<value>600000</value>
</property>

4、 Yarn参数调优

修改yarn-site.xml配置参数如下

<property>
   <description>The class to use as the resource scheduler.</description>
   <name>yarn.resourcemanager.scheduler.class</name>
   <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler</value>
</property>


<property>
   <description>Number of threads to handle scheduler interface.</description>
   <name>yarn.resourcemanager.scheduler.client.thread-count</name>
   <value>8</value>
</property>


<property>
   <description>Enable auto-detection of node capabilities such as
   memory and CPU.
   </description>
   <name>yarn.nodemanager.resource.detect-hardware-capabilities</name>
   <value>false</value>
</property>


<property>
   <description>Flag to determine if logical processors(such as
   hyperthreads) should be counted as cores. Only applicable on Linux
   when yarn.nodemanager.resource.cpu-vcores is set to -1 and
   yarn.nodemanager.resource.detect-hardware-capabilities is true.
   </description>
   <name>yarn.nodemanager.resource.count-logical-processors-as-cores</name>
   <value>false</value>
</property>


<property>
   <description>Multiplier to determine how to convert phyiscal cores to
   vcores. This value is used if yarn.nodemanager.resource.cpu-vcores
   is set to -1(which implies auto-calculate vcores) and
   yarn.nodemanager.resource.detect-hardware-capabilities is set to true. The   number of vcores will be calculated as   number of CPUs * multiplier.
   </description>
   <name>yarn.nodemanager.resource.pcores-vcores-multiplier</name>
   <value>1.0</value>
</property>


<property>
   <description>Amount of physical memory, in MB, that can be allocated
   for containers. If set to -1 and
   yarn.nodemanager.resource.detect-hardware-capabilities is true, it is
   automatically calculated(in case of Windows and Linux).
   In other cases, the default is 8192MB.
   </description>
   <name>yarn.nodemanager.resource.memory-mb</name>
   <value>4096</value>
</property>


<property>
   <description>Number of vcores that can be allocated
   for containers. This is used by the RM scheduler when allocating
   resources for containers. This is not used to limit the number of
   CPUs used by YARN containers. If it is set to -1 and
   yarn.nodemanager.resource.detect-hardware-capabilities is true, it is
   automatically determined from the hardware in case of Windows and Linux.
   In other cases, number of vcores is 8 by default.</description>
   <name>yarn.nodemanager.resource.cpu-vcores</name>
   <value>4</value>
</property>


<property>
   <description>The minimum allocation for every container request at the RM   in MBs. Memory requests lower than this will be set to the value of this   property. Additionally, a node manager that is configured to have less memory   than this value will be shut down by the resource manager.
   </description>
   <name>yarn.scheduler.minimum-allocation-mb</name>
   <value>1024</value>
</property>


<property>
   <description>The maximum allocation for every container request at the RM   in MBs. Memory requests higher than this will throw an   InvalidResourceRequestException.
   </description>
   <name>yarn.scheduler.maximum-allocation-mb</name>
   <value>2048</value>
</property>


<property>
   <description>The minimum allocation for every container request at the RM   in terms of virtual CPU cores. Requests lower than this will be set to the   value of this property. Additionally, a node manager that is configured to   have fewer virtual cores than this value will be shut down by the resource   manager.
   </description>
   <name>yarn.scheduler.minimum-allocation-vcores</name>
   <value>1</value>
</property>


<property>
   <description>The maximum allocation for every container request at the RM   in terms of virtual CPU cores. Requests higher than this will throw an
   InvalidResourceRequestException.</description>
   <name>yarn.scheduler.maximum-allocation-vcores</name>
   <value>2</value>
</property>


<property>
   <description>Whether virtual memory limits will be enforced for
   containers.</description>
   <name>yarn.nodemanager.vmem-check-enabled</name>
   <value>false</value>
</property>


<property>
   <description>Ratio between virtual memory to physical memory when   setting memory limits for containers. Container allocations are   expressed in terms of physical memory, and virtual memory usage   is allowed to exceed this allocation by this ratio.
   </description>
   <name>yarn.nodemanager.vmem-pmem-ratio</name>
   <value>2.1</value>
</property>