Review(5)

5 小文件过多了  什么危害  如何规避？

 

哪里会产生小文件 ?

• 源数据本身有很多小文件
• 动态分区会产生大量小文件
• reduce个数越多, 小文件越多
• 按分区插入数据的时候会产生大量的小文件, 文件个数 = maptask个数 * 分区数

小文件太多造成的影响 ?

• 从Hive的角度看，小文件会开很多map，一个map开一个JVM去执行，所以这些任务的初始化，启动，执行会浪费大量的资源，严重影响性能。
• HDFS存储太多小文件, 会导致namenode元数据特别大, 占用太多内存, 制约了集群的扩展

小文件解决方法

方法一: 通过调整参数进行合并

 

#每个Map最大输入大小(这个值决定了合并后文件的数量)
set mapred.max.split.size=256000000;

#一个节点上split的至少的大小(这个值决定了多个DataNode上的文件是否需要合并)
set mapred.min.split.size.per.node=100000000;

#一个交换机下split的至少的大小(这个值决定了多个交换机上的文件是否需要合并)
set mapred.min.split.size.per.rack=100000000;

#执行Map前进行小文件合并
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;

#===设置map输出和reduce输出进行合并的相关参数：

#设置map端输出进行合并，默认为true
set hive.merge.mapfiles = true

#设置reduce端输出进行合并，默认为false
set hive.merge.mapredfiles = true

#设置合并文件的大小
set hive.merge.size.per.task = 256*1000*1000

#当输出文件的平均大小小于该值时，启动一个独立的MapReduce任务进行文件merge。
set hive.merge.smallfiles.avgsize=16000000

 

方法二: 针对按分区插入数据的时候产生大量的小文件的问题, 可以使用DISTRIBUTE BY rand() 将数据随机分配给Reduce，这样可以使得每个Reduce处理的数据大体一致.

# 设置每个reducer处理的大小为5个G
set hive.exec.reducers.bytes.per.reducer=5120000000;

# 使用distribute by rand()将数据随机分配给reduce, 避免出现有的文件特别大, 有的文件特别小
insert overwrite table test partition(dt)

select * from iteblog_tmp
DISTRIBUTE BY rand();

 

方法三: 使用Sequencefile作为表存储格式，不要用textfile，在一定程度上可以减少小文件

 

方法四: 使用hadoop的archive归档

#用来控制归档是否可用
set hive.archive.enabled=true;
#通知Hive在创建归档时是否可以设置父目录
set hive.archive.har.parentdir.settable=true;
#控制需要归档文件的大小
set har.partfile.size=1099511627776;

#使用以下命令进行归档
ALTER TABLE srcpart ARCHIVE PARTITION(ds='2008-04-08', hr='12');

#对已归档的分区恢复为原文件
ALTER TABLE srcpart UNARCHIVE PARTITION(ds='2008-04-08', hr='12');

#::注意，归档的分区不能够INSERT OVERWRITE，必须先unarchive

 

hadoop自带的三种小文件处理方案 – Hadoop Archive，Sequence file和CombineFileInputFormat.

Hadoop Archive

Hadoop Archive或者HAR，是一个高效地将小文件放入HDFS块中的文件存档工具，它能够将多个小文件打包成一个HAR文件，这样在减少namenode内存使用的同时，仍然允许对文件进行透明的访问。

Sequence file

sequence file由一系列的二进制key/value组成，如果为key小文件名，value为文件内容，则可以将大批小文件合并成一个大文件。

CombineFileInputFormat

它是一种新的inputformat，用于将多个文件合并成一个单独的split，另外，它会考虑数据的存储位置。
 

Spark coalsce（合并分区小文件）

 

6 Yarn的工作流程

    1.用户向Yarn的RM提交应用程序，其中包括
    ApplicationMaster程序，启动ApplicationMaster命令等
    2.RM首先为该app程序分配第一个container容器，并与对应的NM通信，要求NM在这个Container中启动应用程序的application master
    3.App master首先向Apps manager注册，这样的话，我们就可以通过web 8088，查看应用程序的运行状态，且监控它的运行状态
    4.ApplicationMaster向Resource Scheduler申请和领取资源
    5.一旦ApplicationMaster申请到资源后，便与对应的NM通信，要求它启动任务
    6.NM节点启动container容器，运行task任务
    7.各个容器的任务，通过rpc向app master汇报自己的状态和进度，以让APP master随时掌握各个任务的运行状态，从而在任务失败时 重启任务。
    那么用户可以通过web界面实时查看应用的当前运行状态
    8.app运行完成后，app master向 apps manager注销并关闭
 

7.Yarn调度器哪几种 区别 CDH动态资源池

 

    1).FIFO:先进先出

    2).Capacity：计算

    3).Fair:公平（生产上使用）

（1）FIFO Scheduler

将所有的Applications放到队列中，先按照作业的优先级高低、再按照到达时间的先后，为每个app分配资源。如果第一个app需要的资源被满足了，如果还剩下了资源并且满足第二个app需要的资源，那么就为第二个app分配资源，and so on。

优点：简单，不需要配置。

缺点：不适合共享集群。如果有大的app需要很多资源，那么其他app可能会一直等待。

一个例子

上图的示例：有一个很大的job1，它先提交，并且占据了全部的资源。那么job2提交时发现没有资源了，则job2必须等待job1执行结束，才能获得资源执行。

配置

FIFO Scheduler不需要配置

（2）Capacity Scheduler

CapacityScheduler用于一个集群（集群被多个组织共享）中运行多个Application的情况，目标是最大化吞吐量和集群利用率。

CapacityScheduler允许将整个集群的资源分成多个部分，每个组织使用其中的一部分，即每个组织有一个专门的队列，每个组织的队列还可以进一步划分成层次结构（Hierarchical Queues），从而允许组织内部的不同用户组的使用。
每个队列内部，按照FIFO的方式调度Applications。当某个队列的资源空闲时，可以将它的剩余资源共享给其他队列。

配置

CapacityScheduler的配置文件etc/hadoop/capacity-scheduler.xml

 说明：root队列下面有两个队列，分别为prod（40%的容量，即使用40%的集群资源）和dev（60%的容量，最大的75%  ->  说明即使prod队列空闲了，那么dev最多只能使用75%的集群资源。这样就可以保证prod中添加新的apps时马上可以使用25%的资源）。

除了队列的容量和层次，还可以指定单个用户或者应用被分配的资源大小、同时可以运行的app数量、队列的ACLs。

可以指定app要放在哪个队列中。如果不指定，app将会被放在名字是 default的队列中。

CapacityScheduler的队列名字必须是层次结构最后的名字，比如eng。不能是root.dev.eng或者dev.eng。

（3）Fair Scheduler　

FairScheduler允许应用在一个集群中公平地共享资源。默认情况下FairScheduler的公平调度只基于内存，也可以配置成基于memory and CPU。当集群中只有一个app时，它独占集群资源。当有新的app提交时，空闲的资源被新的app使用，这样最终每个app就会得到大约相同的资源。可以为不同的app设置优先级，决定每个app占用的资源百分比。FairScheduler可以让短的作业在合理的时间内完成，而不必一直等待长作业的完成。

Fair Sharing： Scheduler将apps组织成queues，将资源在这些queues之间公平分配。默认情况下，所有的apps都加入到名字为“default“的队列中。app也可以指定要加入哪个队列中。队列内部的默认调度策略是基于内存的共享策略，也可以配置成FIFO和multi-resource with Dominant Resource Fairness

Minimum Sharing：FairScheduller提供公平共享，还允许指定minimum shares to queues，从而保证所有的用户以及Apps都能得到足够的资源。如果有的app用不了指定的minimum的资源，那么可以将超出的资源分给别的app使用。

FairScheduler默认让所有的apps都运行，但是也可以通过配置文件小智每个用户以及每个queue运行的apps的数量。这是针对一个用户一次提交hundreds of apps产生大量中间结果数据或者大量的context-switching的情况。

使用FairScheduler需要修改yarn-size.xml文件，创建allocation file，列出存在的队列和各自的 weights and capacities

prod和dev的权重也可以设置成2和3。

dev下的两个sub-queue没有指定权重，则为1:1。

在设置权重时，需要考虑default queue和用户命名的queue的权重，这些没有在xml文件中指定，但是它们的权重都是1.

队列还可以被配置minimum maximum Resources以及可以运行的最大的apps的数量

FairScheduler支持preemption（抢占），当queue占用的资源大于它应得的，那么调度器可以杀掉queue对应的containers，将yarn.scheduler.fair.preemption设置成true即可。

 

FairScheduler和CapacityScheduler的异同

相同：

（1）以队列划分资源

（2）设定最低保证和最大使用上限

（3）在某个队列空闲时可以将资源共享给其他队列。

不同：

（1）Fair Scheduler队列内部支持多种调度策略，包括FIFO、Fair（队列中的N个作业，每个获得该队列1 / N的资源）、DRF（Dominant Resource Fairness）（多种资源类型e.g. CPU，内存 的公平资源分配策略）

（2）Fair Scheduler支持资源抢占。当队列中有新的应用提交时，系统调度器理应为它回收资源，但是考虑到共享的资源正在进行计算，所以调度器采用先等待再强制回收的策略，即等待一段时间后入股仍没有获得资源，那么从使用共享资源的队列中杀死一部分任务

（3）Fair Scheduler中有一个基于任务数量的负载均衡机制，该机制尽可能将系统中的任务分配到各个节点

（4）Fair Scheduler可以为每个队列单独设置调度策略（FIFO Fair DRF）

（5）Fair Scheduler由于可以采用Fair算法，因此可以使得小应用快速获得资源，避免了饿死的情况。

Hierarchical queues with pluggable policies

FairScheduler支持层次队列（hierarchical queues），所有队列都从root队列开始，root队列的孩子队列公平地共享可用的资源。孩子队列再把可用资源公平地分配给他们的孩子队列。apps可能只会在叶子队列被调度。此外，用户可以为每个队列设置不同的共享资源的策略，内置的队列策略包括 FifoPolicy, FairSharePolicy (default), and DominantResourceFairnessPolicy。

用户可以通过继承org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy实现自己定义的策略。

Delay Scheduling&Dominant Resource Fairness

CapacityScheduler和FairScheduler都支持Delay Scheduling和DRF

不同的apps对CPU和内存的需求量不一样，有的可能需要大量的CPU和一点点内存，有的可能正相反。这会使调度变得复杂。YARN解决的方法是Dominant Resource Fairness，即看app主要需要的资源是什么，用它作为该app对集群使用的度量。

CDH动态资源池

动态资源池是调度池中运行的 YARN 应用程序或 Impala 查询之间的资源的通过动态资源池，根据用户对特定池以及可用于这些池的资源的访问权限，查询调度和分配资源。如果某个池的分配未使用，可以将其提供给其他池。资源份额。动态资源池有 ACL，可限制提交工作的用户并管理这些用户。

配置集定义在指定时间可能处于活动状态的池之间的资源分配。例如，您可以定义“工作日”和“周末”配置集，

它们为不同的周中日定义不同的资源池配置。

计划模式定义配置集何时处于活动状态。配置集在受影响的服务中每小时更新一次

资源池可以嵌套，其中子池由其父池的设置所限制。

如果强制执行静态服务池 (cgroups)，可用于共享的资源将受为每个服务所进行的分配影响。例如，如果

YARN 的静态池占总群集资源的 75%，则资源池只使用该 75% 的资源。

开启Hdfs 权限检查

提交任务 队列名称为用户名

  

 

开启资源管理器 ACL 和设置相应的用户或者用户组

其中 yarn.acl.enable 默认值为 true。

 而对于 yarn.admin.acl 默认值为*，意味着所有人都可以管理 Resource Manager (比如运行 yarn

rmadmin)、管理已提交 (比如取消 kill) 的任务。格式为 "以逗号分隔的用户列表＋空格＋以逗号分隔

的用户组列表"，例如 "user1,user2 group1,group2"。如果只有组信息，需要在最前端加入一个空格，

例如" group1,group2"。另外特别需要注意的是必须至少将"yarn"加入到用户列表中，默认安装 CDH

后，有关 YARN 服务的命令会以 yarn 用户的身份进行运行，若 yarn 不设置于 yarn.admin.acl 中，会

出现权限相关的错误 (例如刷新动态资源池)。

在该示例中，yarn.admin.acl 列表中包含一个用户 yarn 以及一个组 developuser。

关闭 未声明的资源池的自动生成（取消打钩）

当用户提交一个作业，指定的队列-->develop 不存在时，会自动创建一个新队列而不是报错（比如

报错：队列 XXX 不存在），如何避免这种情况发生？只需设置 yarn.scheduler.fair.allow-undeclared

pools，将它的值配置为 false（默认是 true）。

配置用户未指定队列名称，使用 default 队列（取消打钩）

当设置为 true 时，如果未指定池名称，DRF 会使用用户名作为默认的池名称。当设置为 false 时，

所有应用程序都在一个名为 default 的共享池中运行。

 

 这里我们设置两条规则，大概意思为当指定的资源池存在时，使用指定资源池；假如没有指定资源

池或者指定资源池不存在时，则使用默认资源池 root.default。

 有先后顺序（当 1 满足不了时，执行 2）：

a. 仅当指定的资源池存在时，使用指定资源池；

b. 使用默认资源池 root.default.

 使用参数-Dmapreduce.job.queuename=xxx,显性指定一个 Yarn 的应用程序运行所在的资源池。

 在提交访问控制 (Submission Access Control) 栏设置哪些用户或用户组可以向该资源池提交任务

 在管理访问控制 (Administration Access Control) 栏设置哪些用户或用户组可以对资源池中的任务进

行管理

 

8.Yarn的生产上调优参数哪些 ？ 如何调优规划  让你的内存最大化利用   yarn上面是vcore（虚拟core）
swap 使用场景

 0)Container调优

 

定义：

Container：容器  Yarn的资源的抽象，
封装了某个节点的多维度资源,如内存 cpu，磁盘，网络
当AM向RM申请资源时，RM为AM返回的资源就是使用container来标识

1）例如：

48G内存:
25%给Linux  
75%给大数据进程 : 36G内存
DN:  4G 设置：hadoop-env.sh 重启生效
NM:  2G    设置：yarn-env.sh 重启生效
还剩: 36-4-2=30G 是给容器的
一大瓶装的29L
小瓶的规格29L 1瓶 1个container
小瓶的规格8L  3瓶 3个container 33.3
小瓶的规格3L  10瓶 10个container 10

内存：

yarn.nodemanager.resource.memory-mb   30G--总内存
yarn.scheduler.minimum-allocation-mb  2G--最小内存（生产上）
yarn.scheduler.maximum-allocation-mb  30G--最大内存（一般==总内存）

2）数据本地化：DN和NM在一个节点上

3）Vcore(虚拟core)：

如:根据设置core:VCore=1:2 比例 把物理内存虚拟化出2*Core个Vcore

Hadoop YARN同时支持内存和CPU两种资源的调度，本文介绍如何配置YARN对内存和CPU的使用。
YARN作为一个资源调度器，应该考虑到集群里面每一台机子的计算资源，然后根据application申请的资源进行分配Container。Container是YARN里面资源分配的基本单位，具有一定的内存以及CPU资源。
在YARN集群中，平衡内存、CPU、磁盘的资源的很重要的，根据经验，每两个container使用一块磁盘以及一个CPU核的时候可以使集群的资源得到一个比较好的利用。
 

内存配置

关于内存相关的配置可以参考hortonwork公司的文档Determine HDP Memory Configuration Settings来配置你的集群。
YARN以及MAPREDUCE所有可用的内存资源应该要除去系统运行需要的以及其他的hadoop的一些程序，总共保留的内存=系统内存+HBASE内存。
可以参考下面的表格确定应该保留的内存：
每台机子内存     系统需要的内存     HBase需要的内存

计算每台机子最多可以拥有多少个container，可以使用下面的公式:

containers = min (2CORES, 1.8DISKS, (Total available RAM) / MIN_CONTAINER_SIZE)

说明：

CORES为机器CPU核数
DISKS为机器上挂载的磁盘个数
Total available RAM为机器总内存
MIN_CONTAINER_SIZE是指container最小的容量大小，这需要根据具体情况去设置，可以参考下面的表格：

每个container的平均使用内存大小计算方式为：

RAM-per-container = max(MIN_CONTAINER_SIZE, (Total Available RAM) / containers))

通过上面的计算，YARN以及MAPREDUCE可以这样配置：
配置文件 配置设置 默认值 计算值

举个例子：对于128G内存、32核CPU的机器，挂载了7个磁盘，根据上面的说明，系统保留内存为24G，不适应HBase情况下，系统剩余可用内存为104G，计算containers值如下：
containers = min (232, 1.8 7 , (128-24)/2) = min (64, 12.6 , 51) = 13
计算RAM-per-container值如下：
RAM-per-container = max (2, (124-24)/13) = max (2, 8) = 8
你也可以使用脚本yarn-utils.py来计算上面的值：

#!/usr/bin/env python
import optparse
from pprint import pprint
import logging
import sys
import math
import ast

''' Reserved for OS + DN + NM, Map: Memory => Reservation '''
reservedStack = { 4:1, 8:2, 16:2, 24:4, 48:6, 64:8, 72:8, 96:12,
                   128:24, 256:32, 512:64}
''' Reserved for HBase. Map: Memory => Reservation '''
  
reservedHBase = {4:1, 8:1, 16:2, 24:4, 48:8, 64:8, 72:8, 96:16,
                   128:24, 256:32, 512:64}
GB = 1024

def getMinContainerSize(memory):
  if (memory <= 4):
    return 256
  elif (memory <= 8):
    return 512
  elif (memory <= 24):
    return 1024
  else:
    return 2048
  pass

def getReservedStackMemory(memory):
  if (reservedStack.has_key(memory)):
    return reservedStack[memory]
  if (memory <= 4):
    ret = 1
  elif (memory >= 512):
    ret = 64
  else:
    ret = 1
  return ret

def getReservedHBaseMem(memory):
  if (reservedHBase.has_key(memory)):
    return reservedHBase[memory]
  if (memory <= 4):
    ret = 1
  elif (memory >= 512):
    ret = 64
  else:
    ret = 2
  return ret
                    
def main():
  log = logging.getLogger(__name__)
  out_hdlr = logging.StreamHandler(sys.stdout)
  out_hdlr.setFormatter(logging.Formatter(' %(message)s'))
  out_hdlr.setLevel(logging.INFO)
  log.addHandler(out_hdlr)
  log.setLevel(logging.INFO)
  parser = optparse.OptionParser()
  memory = 0
  cores = 0
  disks = 0
  hbaseEnabled = True
  parser.add_option('-c', '--cores', default = 16,
                     help = 'Number of cores on each host')
  parser.add_option('-m', '--memory', default = 64,
                    help = 'Amount of Memory on each host in GB')
  parser.add_option('-d', '--disks', default = 4,
                    help = 'Number of disks on each host')
  parser.add_option('-k', '--hbase', default = "True",
                    help = 'True if HBase is installed, False is not')
  (options, args) = parser.parse_args()
  
  cores = int (options.cores)
  memory = int (options.memory)
  disks = int (options.disks)
  hbaseEnabled = ast.literal_eval(options.hbase)
  
  log.info("Using cores=" + str(cores) + " memory=" + str(memory) + "GB" +
            " disks=" + str(disks) + " hbase=" + str(hbaseEnabled))
  minContainerSize = getMinContainerSize(memory)
  reservedStackMemory = getReservedStackMemory(memory)
  reservedHBaseMemory = 0
  if (hbaseEnabled):
    reservedHBaseMemory = getReservedHBaseMem(memory)
  reservedMem = reservedStackMemory + reservedHBaseMemory
  usableMem = memory - reservedMem
  memory -= (reservedMem)
  if (memory < 2):
    memory = 2
    reservedMem = max(0, memory - reservedMem)
    
  memory *= GB
  
  containers = int (min(2 * cores,
                         min(math.ceil(1.8 * float(disks)),
                              memory/minContainerSize)))
  if (containers <= 2):
    containers = 3

  log.info("Profile: cores=" + str(cores) + " memory=" + str(memory) + "MB"
           + " reserved=" + str(reservedMem) + "GB" + " usableMem="
           + str(usableMem) + "GB" + " disks=" + str(disks))
    
  container_ram = abs(memory/containers)
  if (container_ram > GB):
    container_ram = int(math.floor(container_ram / 512)) * 512
  log.info("Num Container=" + str(containers))
  log.info("Container Ram=" + str(container_ram) + "MB")
  log.info("Used Ram=" + str(int (containers*container_ram/float(GB))) + "GB")
  log.info("Unused Ram=" + str(reservedMem) + "GB")
  log.info("yarn.scheduler.minimum-allocation-mb=" + str(container_ram))
  log.info("yarn.scheduler.maximum-allocation-mb=" + str(containers*container_ram))
  log.info("yarn.nodemanager.resource.memory-mb=" + str(containers*container_ram))
  map_memory = container_ram
  reduce_memory = 2*container_ram if (container_ram <= 2048) else container_ram
  am_memory = max(map_memory, reduce_memory)
  log.info("mapreduce.map.memory.mb=" + str(map_memory))
  log.info("mapreduce.map.java.opts=-Xmx" + str(int(0.8 * map_memory)) +"m")
  log.info("mapreduce.reduce.memory.mb=" + str(reduce_memory))
  log.info("mapreduce.reduce.java.opts=-Xmx" + str(int(0.8 * reduce_memory)) + "m")
  log.info("yarn.app.mapreduce.am.resource.mb=" + str(am_memory))
  log.info("yarn.app.mapreduce.am.command-opts=-Xmx" + str(int(0.8*am_memory)) + "m")
  log.info("mapreduce.task.io.sort.mb=" + str(int(0.4 * map_memory)))
  pass

if __name__ == '__main__':
  try:
    main()
  except(KeyboardInterrupt, EOFError):
    print("\nAborting ... Keyboard Interrupt.")
    sys.exit(1)
python yarn-utils.py -c 32 -m 128 -d 7 -k False
返回结果如下：
点击(此处)折叠或打开
Using cores=32 memory=128GB disks=7 hbase=False
 Profile: cores=32 memory=106496MB reserved=24GB usableMem=104GB disks=7
 Num Container=13
 Container Ram=8192MB
 Used Ram=104GB
 Unused Ram=24GB
 yarn.scheduler.minimum-allocation-mb=8192
 yarn.scheduler.maximum-allocation-mb=106496
 yarn.nodemanager.resource.memory-mb=106496
 mapreduce.map.memory.mb=8192
 mapreduce.map.java.opts=-Xmx6553m
 mapreduce.reduce.memory.mb=8192
 mapreduce.reduce.java.opts=-Xmx6553m
 yarn.app.mapreduce.am.resource.mb=8192
 yarn.app.mapreduce.am.command-opts=-Xmx6553m
 mapreduce.task.io.sort.mb=3276

<property>
      <name>yarn.nodemanager.resource.memory-mb</name>
      <value>106496</value>
  </property>
  <property>
      <name>yarn.scheduler.minimum-allocation-mb</name>
      <value>2048</value>
  </property>
  <property>
      <name>yarn.scheduler.maximum-allocation-mb</name>
      <value>106496</value>
  </property>
  <property>
      <name>yarn.app.mapreduce.am.resource.mb</name>
      <value>4096</value>
  </property>
  <property>
      <name>yarn.app.mapreduce.am.command-opts</name>
      <value>-Xmx3276m</value>
  </property>
另外，还有一下几个参数：
yarn.nodemanager.vmem-pmem-ratio：任务每使用1MB物理内存，最多可使用虚拟内存量，默认是2.1。
yarn.nodemanager.pmem-check-enabled：是否启动一个线程检查每个任务正使用的物理内存量，如果任务超出分配值，则直接将其杀掉，默认是true。
yarn.nodemanager.vmem-pmem-ratio：是否启动一个线程检查每个任务正使用的虚拟内存量，如果任务超出分配值，则直接将其杀掉，默认是true。
第一个参数的意思是当一个map任务总共分配的物理内存为2G的时候，该任务的container最多内分配的堆内存为1.6G，可以分配的虚拟内存上限为2*2.1=4.2G。另外，照这样算下去，每个节点上YARN可以启动的Map数为104/2=52个。
CPU配置
YARN中目前的CPU被划分成虚拟CPU（CPU virtual Core），这里的虚拟CPU是YARN自己引入的概念，初衷是，考虑到不同节点的CPU性能可能不同，每个CPU具有的计算能力也是不一样的，比如某个物理CPU的计算能力可能是另外一个物理CPU的2倍，这时候，你可以通过为第一个物理CPU多配置几个虚拟CPU弥补这种差异。用户提交作业时，可以指定每个任务需要的虚拟CPU个数。
在YARN中，CPU相关配置参数如下：
yarn.nodemanager.resource.cpu-vcores：表示该节点上YARN可使用的虚拟CPU个数，默认是8，注意，目前推荐将该值设值为与物理CPU核数数目相同。如果你的节点CPU核数不够8个，则需要调减小这个值，而YARN不会智能的探测节点的物理CPU总数。
yarn.scheduler.minimum-allocation-vcores：单个任务可申请的最小虚拟CPU个数，默认是1，如果一个任务申请的CPU个数少于该数，则该对应的值改为这个数。
yarn.scheduler.maximum-allocation-vcores：单个任务可申请的最多虚拟CPU个数，默认是32。
 

对于一个CPU核数较多的集群来说，上面的默认配置显然是不合适的，在我的测试集群中，4个节点每个机器CPU核数为31，留一个给操作系统，可以配置为：

<property>
      <name>yarn.nodemanager.resource.cpu-vcores</name>
      <value>31</value>
  </property>
  <property>
      <name>yarn.scheduler.maximum-allocation-vcores</name>
      <value>124</value>
  </property>