Hadoop YARN同时支持内存和CPU两种资源的调度
- 在YARN中，资源管理由ResourceManager和NodeManager共同完成，其中ResourceManager中的调度器负责资源的分配，而NodeManager则负责资源的供给和隔离。ResourceManager将某个NodeManager上资源分配给任务（这就是所谓的“资源调度”）后，NodeManager需按照要求为任务提供相应的资源，甚至保证这些资源应具有独占性，为任务运行提供基础的保证，这就是所谓的资源隔离；
- 内存资源决定任务的生死，如果内存不够，任务可能会运行失败；
- CPU资源决定任务运行的快慢，不会对生死产生影响；
总体
NameNode 的 Java 堆栈大小 （2G）
Secondary NameNode 的 Java 堆栈大小 （2G）
DataNode 的 Java 堆栈大小 （1G）
ResourceManager 的 Java 堆栈大小（字节）(1G)
NodeManager 的 Java 堆栈大小（字节）(1G)
一、yarn-site.xml
#1：for RM，该节点可使用的物理内存
yarn.nodemanager.resource.memory-mb=10240
#2：for container，该节点的container最大可使用的物理内存
yarn.scheduler.maximum-allocation-mb=10240
#一个container初始化时默认的大小为2G
yarn.scheduler.minimum-allocation-mb=2048
#3：vcore=physical-core目前推荐将该值设值为与物理CPU核数数目相同
yarn.nodemanager.resource.cpu-vcores=8
# container初始化CPU核数（默认为1核）
yarn.scheduler.minimum-allocation-vcores=8
# container最大CPU核数（默认为32核）
yarn.scheduler.maximum-allocation-vcores=256
#4：任务每使用1MB物理内存，最多可使用虚拟内存量为3.1M
yarn.nodemanager.vmem-pmem-ratio=3.1
#nodemanager物理内存检查，后台一个线程进行监控，如果超出分配值，则kill
yarn.nodemanager.pmem-check-enabled=true
#nodemanager虚拟内存检查，后台一个线程进行监控，如果超出分配值，则kill
yarn.nodemanager.vmem-check-enabled=true
#5：for aplication master mem
#2048*2,Application Master占用的内存量
yarn.app.mapreduce.am.resource.mb=4096
二、mapred-site.xml
#1：map端分配的内存大小
mapreduce.map.memory.mb=2048
#2：reduce端分配的内存大小
mapreduce.reduce.memory.mb=4096
#3：map端的堆内存大小，2048*0.8
mapreduce.map.java.opts=-Xmx1638M
#4：reduce端的堆内存大小，2048*0.8
mapreduce.reduce.java.opts=-Xmx3277M
#5：map端缓冲区所占内存大小，2048*0.4（mapreduce.map.java.opts除以2得出的，所以此处可以优化为819）
mapreduce.task.io.sort.mb=819
#6：排序时，最大合并流的文件的个数
mapreduce.task.io.sort.factor=100
#7：map端虚拟cpu的核数
mapreduce.map.cpu.vcores=2
#8：reduce端虚拟cpu的核数
mapreduce.reduce.cpu.vcores=2
#9：applicationMaster端虚拟cpu的核数
yarn.app.mapreduce.am.resource.cpu-vcores=4
三、数据平衡优化
原理：
每个DataNode的空间使用率(该节点已使用的空间和空间容量之间的百分比值)和hdfs集群的空间使用率(集群中已使用的空间和集群的空间容量之间的百分比值)非常接近，差距不超过均衡时给定的阈值，设置为10%。
设置balance节点，平衡在datanode中的文件块分布
在线上的Hadoop集群运维过程中，hadoop 的balance工具通常用于平衡hadoop集群中各datanode中的文件块分布，以避免出现部分datanode磁盘占用率高的问题（这问题也很有可能导致该节点CPU使用率较其他服务器高）。
命令：
start-balancer.sh -threshold 10%
也就是各个DataNode直接磁盘使用率偏差在10%以内。
注意：
理论上，该参数设置的越小，整个集群就越平衡，但是在线上环境中，hadoop集群在进行balance时，还在并发的进行数据的写入和删除，所以有可能无法到达设定的平衡参数值。
balance工具在运行过程中，迭代的将文件块从高使用率的datanode移动到低使用率的datanode上，每一个迭代过程中移动的数据量不超过下面两个值的较小者：10G或者指定阀值*容量，且每次迭代不超过20分钟。每次迭代结束后，balance工具将更新该datanode的文件块分布情况。
配置：
dfs.balance.bandwidthPerSec 默认设置：1048576（1 M/S），参数含义：设置balance工具在运行中所能占用的带宽，设置的过大可能会造成mr运行缓慢
注意：
1、mv命令很可怕，迁移集群的时候，如果没有迁移成功，文件还是原来的文件
2、cdh中添加balance节点，点击按钮即可进行数据平衡
四、开启uber服务
原理：
Uber模式简单地可以理解成JVM重用，该模式是Hadoop 2.x开始引入的；以Uber模式运行MR作业，所有的Map Tasks和Reduce Tasks将会在ApplicationMaster所在的容器（container）中运行，也就是说整个MR作业运行的过程只会启动AM container，因为不需要启动mapper 和 reducer containers，所以AM不需要和远程containers通信，整个过程简单了。
不是所有的MR作业都可以启用Uber模式，如果我们的MR作业输入的数据量非常小，启动Map container或Reduce container的时间都比处理数据要长，那么这个作业就可以考虑启用Uber模式运行，一般情况下，对小作业启用Uber模式运行会得到2x-3x的性能提升。
启用uber模式的要求非常严格，代码如下：
● uberEnabled：其实就是 mapreduce.job.ubertask.enable 参数的值，默认情况下为 false ；也就是说默认情况不启用Uber模式；
● smallNumReduceTasks：同理，Uber模式的作业Reduce的个数必须小于等于mapreduce.job.ubertask.maxreduces，该值默认为1；也计算说，在默认情况下，如果你想启用Uber模式，作业的Reduce个数必须小于等于1；
● smallMemory：因为作业是在AM所在的container中运行，所以要求我们设置的Map内存（mapreduce.map.memory.mb）和Reduce内存（mapreduce.reduce.memory.mb）必须小于等于AM所在容器内存大小设置（yarn.app.mapreduce.am.resource.mb）；
● notChainJob：此外，处理数据的Map class（mapreduce.job.map.class）和Reduce class（mapreduce.job.reduce.class）必须不是 ChainMapper 或 ChainReducer 才行；
● isValidUberMaxReduces：目前仅当Reduce的个数小于等于1的作业才能启用Uber模式。