一、yarn参数调优
同样和上一篇一样，打开Cloudera manager管理软件，yarn页面，点击配置。
1、zookeeper服务
我的这个集群是有其他服务在使用zk为了防止单个组件故障引起的全部故障，我独立了zookeeper服务。
2、启用resource manager acl服务
yarn.acl.enable：指定是否应检查管理 ACL 中指定的用户和组执行管理操作的授权。
yarn.admin.acl：确定哪些用户和组可在任何池中提交和中止应用程序以及可以对 ResourceManager 角色发出命令的 ACL。
你在资源池中打开了ACL，就意味着你打开了yarn.acl.enable，这个时候另外一个配置就生效了：yarn.admin.acl，该配置默认是root，需要把dr.who添加到此列表中即可（逗号分隔）。
队列分配功能参考该博客https://blog.csdn.net/weixin_43255026/article/details/86626149
3、聚合日志
MapReduce 是在各个机器上运行的， 在运行过程中产生的日志存在于各个机器上，为了能够统一查看各个机器的运行日志，将日志集中存放在 HDFS 上， 这个过程就是日志聚集，目前就我接触的集群来说，因为很多加工是离线加工大部分都是跑的mr程序，而且每天的任务量达到几万个左右，所以在job较多的集群上我的聚合日志只保留了1天，在相对较小的集群上我设置了三天的保留周期。
yarn.log-aggregation-enable
参数说明：是否启用日志聚合功能，日志聚合开启后保存到HDFS上。
默认值：false
yarn.log-aggregation.retain-seconds
参数说明：聚合后的日志在HDFS上保存多长时间，单位为s。
默认值：-1（不启用日志聚合），例如设置为86400，24小时
yarn.log-aggregation.retain-check-interval-seconds
参数解释：多长时间检查一次日志，并将满足条件的删除，如果是0或者负数，则为上一个(yarn.log-aggregation.retain-seconds)值的1/10。
默认值：-1
yarn.nodemanager.remote-app-log-di
参数说明：当应用程序运行结束后，日志被转移到的HDFS目录（启用日志聚集功能时有效），修改为保存的日志文件夹。
默认值：/tmp/logs
yarn.nodemanager.remote-app-log-dir-suffix
参数说明：远程日志目录子目录名称（启用日志聚集功能时有效）。
默认值：logs 日志将被转移到目录${yarn.nodemanager.remote-app-log-dir}/${user}/${thisParam}下
4、正常解除授权超时
反正配置了application最大尝试次数，可以随时停掉一个nodemanager，前提是你的集群加工数据不那么实时，总之还是对生产集群有敬畏之心吧。
5、Mapreduce 提交复制
mapreduce任务数据的副本数，默认是10，比普通HDFS文件的默认幅本数大很多，可能也是考虑到把输入数据放到更多的DN上，尽可能实现本地数据计算，但会增大数据量。一般情况下默认即可。
其实这里涉及到了mr的job提交过程
1、客户端，提交MapReduce作业
2、YARN的资源管理器（Resource Manager），协调集群中计算资源的分配
3、YARN的节点管理器（Node Manager），启动并监控集群中的计算容器
4、MapReduce的Application Master，协调MapReduce作业中任务的运行。Application Master和MapReduce任务运行于容器中，这些容器由resourcemanager调度，由nodemanager管理。
5、分布式文件系统（一般是HDFS），在组件之间共享作业数据。
Job对象的submit方法创建了一个内部的JobSubmitter实例并调用该实例的submitJobInternal方法。一旦提交了作业，waitForCompletion方法每秒钟轮询作业的执行进度，如果进度发生了变化，则向控制台报告进度。当作业成功完成，展示作业计数器的数据。否则展示作业失败的错误日志信息。
obSubmitter实现的作业提交的过程有如下几个步骤：
1、向resourcemanager申请一个新的application ID，用于MapReduce作业的ID
2、检查作业的输出。如果没有指定输出或者输出路径已经存在，则不提交作业，MapReduce程序抛异常
3、计算作业的输入切片。如果不能计算切片（比如输入路径不存在等），不提交作业，MR程序抛异常。
4、拷贝执行作业需要的资源到共享文件系统的以作业ID命名的目录中，这些资源包括作业的jar包，配置文件，计算好的输入切片。作业的jar包有一个很高的副本数量（mapreduce.client.submit.file.replication指定，默认值是10），这样当nodemanager如果运行作业中的任务，会有很多副本可以访问。
5、调用resourcemanager的submitApplication方法提交作业。
6、mr作业最大尝试次数
设置2次足够了，默认也是两次，如果还是失败就说明要么集群有问题了，要么这个job参数不合理，需要从新编写。
7、mr的推测执行
mapred.map.tasks.speculative.execution boolean true 如果任务运行变慢，该属性决定了是否要启动一个map任务的另外一个实力
mapred.reduce.tasks.speculative.execution boolean true 如果任务运行变慢，该属性决定这是否需要启动一个reduce任务
推测执行(Speculative Execution)是通过利用更多的资源来换取时间的一种优化策略，但是在资源很紧张的情况下，推测执行也不一定能带来时间上的优化，假设在测试环境中，DataNode总的内存空间是40G，每个Task可申请的内存设置为1G，现在有一个任务的输入数据为5G，HDFS分片为128M，这样Map Task的个数就40个，基本占满了所有的DataNode节点，如果还因为每些Map Task运行过慢，启动了Speculative Task，这样就可能会影响到Reduce Task的执行了，影响了Reduce的执行，自然而然就使整个JOB的执行时间延长。所以是否启用推测执行，如果能根据资源情况来决定，如果在资源本身就不够的情况下，还要跑推测执行的任务，这样会导致后续启动的任务无法获取到资源，以导致无法执行。
8、提前申请reduce资源
mapreduce.job.reduce.slowstart.completedmaps这个参数如果设置的过低，那么reduce就会过早地申请资源，造成资源浪费；如果这个参数设置的过高，比如为1，那么只有当map全部完成后，才为reduce申请资源，开始进行reduce操作，实际上是串行执行，不能采用并行方式充分利用资源。
如果map数量比较多，一般建议提前开始为reduce申请资源。
9、I/O 排序因子
排序文件时要合并的流的数量。也就是说，在 reducer 端合并排序期间要使用的排序头数量。此设置决定打开文件句柄数。并行合并更多文件可减少合并排序迭代次数并通过消除磁盘 I/O 提高运行时间。注意：并行合并更多文件会使用更多的内存。如 'io.sort.factor' 设置太高或最大 JVM 堆栈设置太低，会产生过多地垃圾回收。Hadoop 默认值为 10，建议使用更高值
10、I/O 排序内存缓冲
当排序文件时要使用的内存缓冲总量（以 MB 为单位）。注意：此内存由 JVM 堆栈大小产生（也就是：总用户 JVM 堆栈 - 这些内存 = 总用户可用堆栈空间）。注意：Cloudera 的默认值不同于 Hadoop 的默认值；默认情况下，Cloudera 使用更大的缓冲，因为现代机器通常有更多的 RAM。所有 TaskTrackers 中的最小值将成为生成的客户端配置的一部分。
11、I/O 排序溢出百分比
软限制在缓冲或记录收集缓冲。达到此限制时，线程将开始让内容溢到后台的磁盘中。注意：这不表示要溢出任何数据块。不建议使用小于 0.5 的值。语法使用十进制单位；默认值为 80%，使用 0.8 的格式。将是生成的客户端配置的一部分。
12、ApplicationMaster 最大尝试次数
最大应用程序尝试次数。这是所有 ApplicationMasters 的全局设置。每个 ApplicationMaster 都可以通过 API 指定单独最大值，但如果单独最大值超过全局最大值，ResourceManager 将覆盖单独最大值。
13、容器内存
这个根据你物理机的配置设置，我管理的机器有三种配置，所以设置了三种。
14、容器cpu内核
15、最小容器内存
yarn.scheduler.minimum-allocation-mb
yarn.scheduler.maximum-allocation-mb
单个容器可申请的最小与最大内存，应用在运行申请内存时不能超过最大值，小于最小值则分配最小值，从这个角度看，最小值有点像操作系统中的页。最小值还有另外一种用途，计算一个节点的最大container数目注：这两个值一经设定不能动态改变(此处所说的动态改变是指应用运行时)。
在整理这个文档的时候我发现一个问题，我的集群配置有128g内存的机器，这个集群配置了200g的最大内存容器，如果真有一个200g的container会不会卡死呢？改天研究下。
二、总结
还有些高级代码段的参数，这些也是要看现有集群状态，关于调度器的选择，也是需要业务与实际job运行时间来定，yarn的调优是一个缓慢适应业务的过程。
