hdfs 调试纠删码 hadoop纠删码实现

Hadoop学习（十一）

注意：如果想看用的到的集群参数设置就去第10章直接看

1.HDFS—存储优化

1.纠删码

原理：

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

具体实现：

纠删码命令：

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>].

查看支持的纠删码策略

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

策略解释：

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.异构存储储（冷热数据分离）

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

下面是异构使用场景及存储类型

异构的shell操作

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

测试环境准备：

节点	存储类型分配
hadoop100	RAM_DISK，SSD
hadoop101	SSD，DISK
hadoop102	DISK，RAM_DISK
hadoop103	ARCHIVE
hadoop104	ARCHIVE

hadoop100的节点的hdfs-site.xml加入

<property>
<name>dfs.replication</name>
<value>2</value>
</property>
<property>
<name>dfs.storage.policy.enabled</name>
<value>true</value>
</property>
<property>
<name>dfs.datanode.data.dir</name> 
<value>[SSD]file:///opt/module/hadoop-3.1.3/hdfsdata/ssd,[RAM_DISK]file:///opt/module/hadoop-3.1.3/hdfsdata/ram_disk</value>
</property>

hadoop101

<property>
<name>dfs.replication</name>
<value>2</value>
</property>
<property>
<name>dfs.storage.policy.enabled</name>
<value>true</value>
</property>
<property>
<name>dfs.datanode.data.dir</name>
<value>[SSD]file:///opt/module/hadoop-3.1.3/hdfsdata/ssd,[DISK]file:///opt/module/hadoop-3.1.3/hdfsdata/disk</value>
</property>

hadoop102

<property>
<name>dfs.replication</name>
<value>2</value>
</property>
<property>
<name>dfs.storage.policy.enabled</name>
<value>true</value>
</property>
<property>
<name>dfs.datanode.data.dir</name>
<value>[RAM_DISK]file:///opt/module/hdfsdata/ram_disk,[DISK]file:///o
pt/module/hadoop-3.1.3/hdfsdata/disk</value>
</property>

hadoop103

<property>
<name>dfs.replication</name>
<value>2</value>
</property>
<property>
<name>dfs.storage.policy.enabled</name>
<value>true</value>
</property>
<property>
<name>dfs.datanode.data.dir</name>
<value>[ARCHIVE]file:///opt/module/hadoop-3.1.3/hdfsdata/archive</value>
</property>

hadoop104

<property>
<name>dfs.replication</name>
<value>2</value>
</property>
<property>
<name>dfs.storage.policy.enabled</name>
<value>true</value>
</property>
<property>
<name>dfs.datanode.data.dir</name>
<value>[ARCHIVE]file:///opt/module/hadoop3.1.3/hdfsdata/archive</value>
</property>

启动集群

（1） HOT 存储策略案例

1.最开始我们未设置存储策略的情况下，我们获取该目录的存储策略

hadoop fs -mkdir /hdfsdata
 hadoop fs -put /opt/module/hadoop-3.1.3/NOTICE.txt /hdfsdata
 hdfs storagepolicies -getStoragePolicy -path /hdfsdata

2.我们查看上传的文件块分布

hdfs fsck /hdfsdata -files -blocks -locations
[DatanodeInfoWithStorage[192.168.10.102:9866,DS-0b133854-7f9e-48df-939b-5ca6482c5afb,DISK], DatanodeInfoWithStorage[192.168.10.101:9866,DS-ca1bd3b9-d9a5-4101-9f92-3da5f1baa28b,DISK]]

未设置存储策略，所有文件块都存储在 DISK 下。所以，默认存储策略为 HOT

（2） WARM 存储策略测试

1.接下来我们为数据降温

hdfs storagepolicies -setStoragePolicy -path /hdfsdata -policy WARM

2.再次查看文件块分布，我们可以看到文件块依然放在原处。

hdfs fsck /hdfsdata -files -blocks -locations

3.我们需要让他 HDFS 按照存储策略自行移动文件块

hdfs mover /hdfsdata

4.再次查看文件块分布

hdfs fsck /hdfsdata -files -blocks -locations
[DatanodeInfoWithStorage[192.168.10.103:9866,DS-d46d08e1-80c6-4fca-b0a2-
4a3dd7ec7459,ARCHIVE], DatanodeInfoWithStorage[192.168.10.101:9866,DS-ca1bd3b9-d9a5-4101-9f92-3da5f1baa28b,DISK]]

文件块一半在 DISK，一半在 ARCHIVE，符合我们设置的 WARM 策略

其他策略也是同样的，就不演示了

2. HDFS—故障排除

快照恢复到之前

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

有两种方案：

推荐第二种，至少只是少了一个checkpoint的数据，如果第一种的话集群数据全没了

第一种：rm -rf 所有服务器的logs和datas，然后初始化我们的NameNode在重启即可

第二种：将SecondaryNameNode的数据复制到原NameNode存储数据的目录，在重启NameNode

一般到后来HA，会有多个NameNode的，高可用，只有一个是Active，其他都是Standby

3.安全模式

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

进入场景

退出条件

dfs.namenode.safemode.min.datanodes:最小可用 datanode 数量，默认 0

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

4.慢磁盘监控

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

如何发现慢磁盘？ 正常在 HDFS 上创建一个目录，只需要不到 1s 的时间。如果你发现创建目录超过 1 分 钟及以上，而且这个现象并不是每次都有。只是偶尔慢了一下，就很有可能存在慢磁盘。 可以采用如下方法找出是哪块磁盘慢：

（1）通过心跳未联系时间。

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

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

5.小文件归档

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

解决方法：

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

实现步骤：

6.集群迁移

1. Apache 和 Apache 集群间数据拷贝

（1）scp 实现两个远程主机之间的文件复制

scp -r hello.txt root@hadoop103:/user/atguigu/hello.txt // 推 push 
 scp -r root@hadoop103:/user/atguigu/hello.txt hello.txt // 拉 pull
 scp -r root@hadoop103:/user/atguigu/hello.txt root@hadoop104:/user/atguigu //是通过本 地主机中转实现两个远程主机的文件复制；如果在两个远程主机之间 ssh 没有配置的情况下 可以使用该方式

（2）采用 distcp 命令实现两个 Hadoop 集群之间的递归数据复制

bin/hadoop distcp 
hdfs://hadoop102:8020/user/atguigu/hello.txt
hdfs://hadoop105:8020/user/atguigu/hello.txt

7.MapReduce常用参数调优

1.参数调优

2.数据倾斜

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

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

减少方法：

（1）首先检查是否空值过多造成的数据倾斜

生产环境，可以直接过滤掉空值；如果想保留空值，就自定义分区，将空值加随机数打 散。最后再二次聚合。

（2）能在 map 阶段提前处理，最好先在 Map 阶段处理。如：Combiner、MapJoin

（3）设置多个 reduce 个数

8.Hadoop-Yarn 生产经验

1.常用调优参数

（1）Resourcemanager 相关

yarn.resourcemanager.scheduler.client.thread-count ResourceManager 处理调度
器请求的线程数量
yarn.resourcemanager.scheduler.class 配置调度器

（2）Nodemanager 相关

yarn.nodemanager.resource.memory-mb NodeManager 使用内存数
yarn.nodemanager.resource.system-reserved-memory-mb NodeManager 为系统保留
多少内存，和上一个参数二者取一即可
yarn.nodemanager.resource.cpu-vcores NodeManager 使用 CPU 核数
yarn.nodemanager.resource.count-logical-processors-as-cores 是否将虚拟核
数当作 CPU 核数
yarn.nodemanager.resource.pcores-vcores-multiplier 虚拟核数和物理核数乘数，例
如：4 核 8 线程，该参数就应设为 2
yarn.nodemanager.resource.detect-hardware-capabilities 是否让 yarn 自己检测硬
件进行配置
yarn.nodemanager.pmem-check-enabled 是否开启物理内存检查限制 container
yarn.nodemanager.vmem-check-enabled 是否开启虚拟内存检查限制 container
yarn.nodemanager.vmem-pmem-ratio 虚拟内存物理内存比例

（3）Container 容器相关

yarn.scheduler.minimum-allocation-mb 容器最小内存
yarn.scheduler.maximum-allocation-mb 容器最大内存
yarn.scheduler.minimum-allocation-vcores 容器最小核数
yarn.scheduler.maximum-allocation-vcores 容器最大核数

10.综合调优

1.Hadoop 小文件优化方法

1. Hadoop 小文件弊端

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

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

2.Hadoop 小文件解决方案

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

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

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

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

开启uber模式：

在 mapred-site.xml 中添加如下配置

<!-- 开启 uber 模式，默认关闭 -->
<property>
 <name>mapreduce.job.ubertask.enable</name>
 <value>true</value>
</property>
<!-- uber 模式中最大的 mapTask 数量，可向下修改 --> 
<property>
 <name>mapreduce.job.ubertask.maxmaps</name>
 <value>9</value>
</property>
<!-- uber 模式中最大的 reduce 数量，可向下修改 -->
<property>
 <name>mapreduce.job.ubertask.maxreduces</name>
 <value>1</value>
</property>
<!-- uber 模式中最大的输入数据量，默认使用 dfs.blocksize 的值，可向下修
改 -->
<property>
 <name>mapreduce.job.ubertask.maxbytes</name>
 <value></value>
</property>

分发配置在执行可以看到all containers个数为1

2. 企业开发场景案例

1.需求

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

（2）需求分析： 1G / 128m = 8 个 MapTask；1 个 ReduceTask；1 个 mrAppMaster 平均每个节点运行 10 个 / 3 台 ≈ 3 个任务（4 3 3）

2.HDFS 参数调优

修改hadoop-env.sh

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

修改 hdfs-site.xml

<!-- NameNode 有一个工作线程池，默认值是 10 -->
<property>
 <name>dfs.namenode.handler.count</name>
 <value>21</value>
</property>

修改 core-site.xml

<!-- 配置垃圾回收时间为 60 分钟 -->
<property>
 <name>fs.trash.interval</name>
 <value>60</value>
</property>

分发配置

3. MapReduce 参数调优

修改 mapred-site.xml

<!-- 环形缓冲区大小，默认 100m -->
<property>
 <name>mapreduce.task.io.sort.mb</name>
 <value>100</value>
</property>
<!-- 环形缓冲区溢写阈值，默认 0.8 -->
<property>
 <name>mapreduce.map.sort.spill.percent</name>
 <value>0.80</value>
</property>
<!-- merge 合并次数，默认 10 个 -->
<property>
 <name>mapreduce.task.io.sort.factor</name>
 <value>10</value>
</property>
<!-- maptask 内存，默认 1g； maptask 堆内存大小默认和该值大小一致
mapreduce.map.java.opts -->
<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>
<!-- matask 的 CPU 核数，默认 1 个 -->
<property>
 <name>mapreduce.map.cpu.vcores</name>
 <value>1</value>
</property>
<!-- matask 异常重试次数，默认 4 次 -->
<property>
 <name>mapreduce.map.maxattempts</name>
 <value>4</value>
</property>
<!-- 每个 Reduce 去 Map 中拉取数据的并行数。默认值是 5 -->
<property>
 <name>mapreduce.reduce.shuffle.parallelcopies</name>
 <value>5</value>
</property>
<!-- Buffer 大小占 Reduce 可用内存的比例，默认值 0.7 -->
<property>
 <name>mapreduce.reduce.shuffle.input.buffer.percent</name>
 <value>0.70</value>
</property>
<!-- Buffer 中的数据达到多少比例开始写入磁盘，默认值 0.66。 -->
<property>
 <name>mapreduce.reduce.shuffle.merge.percent</name>
 <value>0.66</value>
</property>
<!-- reducetask 内存，默认 1g；reducetask 堆内存大小默认和该值大小一致
mapreduce.reduce.java.opts -->
<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>
<!-- reducetask 的 CPU 核数，默认 1 个 -->
<property>
 <name>mapreduce.reduce.cpu.vcores</name>
 <value>2</value>
</property>
<!-- reducetask 失败重试次数，默认 4 次 -->
<property>
 <name>mapreduce.reduce.maxattempts</name>
 <value>4</value>
</property>
<!-- 当 MapTask 完成的比例达到该值后才会为 ReduceTask 申请资源。默认是 0.05
-->
<property>
 <name>mapreduce.job.reduce.slowstart.completedmaps</name>
 <value>0.05</value>
</property>
<!-- 如果程序在规定的默认 10 分钟内没有读到数据，将强制超时退出 -->
<property>
 <name>mapreduce.task.timeout</name>
 <value>600000</value>
</property>

分发配置

3. 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.capaci
ty.CapacityScheduler</value>
</property>
<!-- ResourceManager 处理调度器请求的线程数量,默认 50；如果提交的任务数大于 50，可以
增加该值，但是不能超过 3 台 * 4 线程 = 12 线程（去除其他应用程序实际不能超过 8） -->
<property>
<description>Number of threads to handle scheduler 
interface.</description>
<name>yarn.resourcemanager.scheduler.client.thread-count</name>
<value>8</value>
</property>
<!-- 是否让 yarn 自动检测硬件进行配置，默认是 false，如果该节点有很多其他应用程序，建议
手动配置。如果该节点没有其他应用程序，可以采用自动 -->
<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>
<!-- 是否将虚拟核数当作 CPU 核数，默认是 false，采用物理 CPU 核数 -->
<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-ascores</name>
<value>false</value>
</property>
<!-- 虚拟核数和物理核数乘数，默认是 1.0 -->
<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>
<!-- NodeManager 使用内存数，默认 8G，修改为 4G 内存 -->
<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>
<!-- nodemanager 的 CPU 核数，不按照硬件环境自动设定时默认是 8 个，修改为 4 个 -->
<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>
<!-- 容器最小内存，默认 1G -->
<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>
<!-- 容器最大内存，默认 8G，修改为 2G -->
<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>
<!-- 容器最小 CPU 核数，默认 1 个 -->
<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>
<!-- 容器最大 CPU 核数，默认 4 个，修改为 2 个 -->
<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>
<!-- 虚拟内存和物理内存设置比例,默认 2.1 -->
<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>

分发启动集群即可