大家好，今天来介绍yarn安装及环境配置(yarn不是内部或外部命令,也不是可运行的程序)的问题，以下是渲大师小编对此问题的归纳和整理，感兴趣的来一起看看吧！

yarn 配置全局安装位置到D盘解决tsc找不到问题。

通常遇到这种问题，一般是建议把yarn的安装位置换到非系统盘（c盘），所以这里我准备迁移。

查看yarn 配置指令

yarn config list  

yarn global dir      ——yarn 全局安装的位置

yarn global bin     ——bin目录的位置

把c盘原来的yarn文件删除，保留.yarnrc 文件。并修改对亮信族应的D盘文件如下图

通过cmd输入下列指令   路径可以自己重新定义

cache-folder “D:\software\yarn\cache”           ——yarn 缓存位置

global-folder “D:\software\yarn\global”           ——yarn 全局安装位置

prefix “D:\software\yarn\global\node_modules\.bin”  ——yarn bin位置     
bin的位置 记得配置环境变量 到path  举例  D:\software\yarn\global\node_modules\.bin

注意文件敬弊夹要自己好，这里 prefix可以后面再添加，

也可以通过指令修改。

1.全局安装位置配置   yarn config  set global-folder “你的磁盘路径”
2.yarn 缓存位置    yarn config set cache-folder “你的磁盘路径”
3.yarn bin位置    yarn config set prefix  D:\software\yarn\global坦袭node_modules\.bin   
这里的路径不需要带引号哈！！~

然后可以尝试全局安装  yarn global add typescript  ，这时候看下目录结构

如果还有遇到什么问题的话，可以私信我。    环境变量大家不要忘记配置哈！！！

yarn安装及环境配置(yarn全局安装包)

yarn不是内部或外部命令

3、御灶悄配置环辩乱境变量，安装地址不同会需要修改：

4、yarn -v    查看版镇渣本   安装成功。

注意:系统和运行脚本在启动时解析配置.对配置文件的更改需要重新启动Flink JobManager和TaskManagers

Flink on Yarn模式安装部署要做的其实不多，正常的步骤：
1、上传二进制包 ===》2、解压缩 ===》 3、更改文件名称 ===》 4、配置环境变量。Flink on yarn的job运行模式大致分为两类：

第一种巧知模式分为两步：yarn-session.sh(开辟资源)—>flink run（提交任务）

另外，jobmanager和taskmanager分别占有容器，示例：
./bin/yarn-session.sh -n 10 -tm 8192 -s 32
上面的例子将冲让会启动11个容器(即使仅请求10个容器)，因为有一个额外的容器来启动ApplicationMaster 和 job manager,一旦flink在你的yarn集群上部署，它将会显示job manager的连接详细信息。

第二种模式其实也孝判消分为两个部分，依然是开辟资源和提交任务，但是在Job模式下，这两步都合成一个命令了。
这里，我们直接执行命令

在job结束后就会关闭flink yarn-session的集群

sudo /usr/lib/flink/bin/flink run -m yarn-cluster -yn 1 -yjm 1024 -ytm 1024 -ys 1 -p 1 xz-flink-examples-1.0.jar
• “run” 操作参数:

注意：client必须要设置YARN_CONF_DIR或者HADOOP_CONF_DIR环境变量，通过这个环境变量来读取YARN和HDFS的配置信息，否则启动会失败。
经试验发现，其实如果配置的有HADOOP_HOME环境变量的话也是可以的。HADOOP_HOME ，YARN_CONF_DIR，HADOOP_CONF_DIR 只要配置的有任何一个即可。
独立job模式客户端命令行参数参考： flink独立Job命令

Flink 的 YARN 客户端具有以下配置参数来控制容器故障时的行为方式。这些参数可以从 conf/flink-conf.yaml 中设置，或者在启动会话时使用-D参数设置
如：

参考： flink中文官网关于参数的解释

linux (centos)安装卸载升级node npm yarn

4.配置软连接察告，使全局都可以使用node命令

5.配置node文件安装路径 进入/usr/local/node/路径下:

2.卸载node

4.更新版本命令

解决：
a. 查看系统node的安装路径
n模块的默认路径为 ‘/usr/local’

b. 通过N_PREFIX变量来修改 n 的默认node安装路径
1.编辑环境配置文件

按i键使编辑器进入到插入模式
2.添加模乎配置语败码明句

https://yarn.bootcss.com/docs/install/#centos-stable

YARN 生产详解

前言：

上节课我们讲了 MR job的提交YARN的工作流程 与 YARN的架构，本次课程详细讲讲YARN，多多总结。

YARN（主从） 资源  + 作业调度管理

YARN：是一种新的 Hadoop资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。

                 ResourceManager(RM)：主要接收客户端任务请求，接收和监控NodeManager(NM)的侍族资源情况汇报，负责资源的分配与调度，启动和监控ApplicationMaster(AM)。

               ApplicationManager（作业）：应用程序管理，它是负责系统中所有的job，包括job的提交与调度器协商资源来启动ApplicationMaster(AM)和监控(AM)运行状态，并且失败的时候能够重新启动它，更新分配给一个新的Container容器的进度或者状态，除了资源它不管，它就负责job                                             

               Scheduler（调度器）：更具容量队列的限制条件将我们系统中的资源分配给正在运用的一个应用程序先进先出调度器 ：一个作业运行完了，另一个才能运行

yarn的内置调度器：

1.FIFO先进先出，一个的简单调度器，适合低负载集群。（适合任务数量不多的情况下使用）

2.Capacity调度器，给不同队列（即用户或用户组）分配一个预期最小容量，在每个队列内部用层次化的FIFO来调度多个应用程序。（适用于有很多小的任务跑，需要占很多队列，不使用队列，会造成资源的浪费）

3.Fair公平调度器，针对不同的应用（也可以为用户或用户组），每个应用属于一个队列，主旨是让每个应用分配的资源大体相当。（当然可以设置权重），若是只有一个应用，那集群所有资源都是他的。 适用情况：共享大集群、队列之间有较大差别。（生产使用）

capacity调度器的启用：

在ResourceManager节点上的yarn-site.xml设置

Property===>yarn.resourcemanager.scheduler.class

Value=====>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler

capacity调度器的配置:

在目录$HADOOP_HOME/hadoop/etc/hadoop/capacity-scheduler.xml

修改完成后，需要执行下面的命令：

$HADOOP_YARN_HOME/bin/yarn rmadmin -refreshQueues    使功能动态生效。

NodeManager：主要是节点上的资源和作业管理器，启动Container运行task计算，上报资源、container情况给RM和任务处理情况给AM，整个集群有多个。

ApplicationMaster： 它是负责我们作业的监控并跟踪应用执行状态来重启失败任务的，主要是单个Application(Job)的task管理和调度，向RM进行资源的申请，向NM发出launchContainer指令，接收NM的task处理状态信息。一个job只有一个主程序。                                     

Container： 是YARN中资源的抽象，它封装了某个节点上一定量的资源（CPU和内存两类资源）。

Memory：

yarn.nodemanager.resource.memory-mb：64*0.8G=50G  （如果内存是衡清64G，Yarn只能用到内老拦弊存的80%也就是50G）

yarn.scheduler.minimum-allocation-mb: 1G

yarn.scheduler.maximum-allocation-mb: 1G   50/1=50（并行度） 数量是多了，并行度大了  

一个作业200 MapTask 4轮才能结束，速度快了  作业可能挂了

yarn.scheduler.maximum-allocation-mb: 16G (生产设16G)   50/16=3（并行度） 数量是少了，并行度小了  

一个作业200 MapTask 70轮才能结束，速度慢了  作业时间长 稳定不会挂

工作中一个job可以指定 yarn.scheduler.maximum-allocation-mb的值，但一般不指定。

【若泽大数据实战】使用YARN跑一个jar包

先启动Yarn

进入hadoop的bin目录 在hdfs上创建一个新文件夹

创建一个test.log文件

将当前目录中的某个test.log文件复制到hdfs中（注意要确保当前目录中有该文件）

查看hdfs中是否有我们刚复制进去的文件

进入share的上层目录，提交单词统计任务，实验环境下我们的提交差不多在15秒左右

生产环境中，应该是30~50之间，调优可以压到10秒之内

登录网页查看相关信息：http://192.168.137.30:8088/cluste

Yarn的常用命令

客户端提交job给 Applications Manager 连接Node Manager去申请一个Container的容器，这个容器运行作业的App Mstr的主程序，启动后向App Manager进行注册，然后可以访问URL界面，然后App Mastr向 Resource Scheduler申请资源，拿到一个资源的列表，和对应的NodeManager进行通信，去启动对应的Container容器，去运行 Reduce Task 和 Map Task （两个先后运行顺序随机运行），它们是向App Mstr进行汇报它们的运行状态， 当所有作业运行完成后还需要向Applications Manager进行汇报并注销和关闭

yarn中，它按照实际资源需求为每个任务分配资源，比如一个任务需要1GB内存，1个CPU，则为其分配对应的资源，而资源是用container表示的，container是一个抽象概念，它实际上是一个JAVA对象，里面有资源描述（资源所在节点，资源优先级，资源量，比如CPU量，内存量等）。当一个applicationmaster向RM申请资源时，RM会以container的形式将资源发送给对应的applicationmaster，applicationmaster收到container后，与对应的nodemanager通信，告诉它我要利用这个container运行某个任务。

基于以上考虑，YARN允许用户配置每个节点上可用的物理内存资源，注意，这里是“可用的”，因为一个节点上的内存会被若

干个服务共享，比如一部分给YARN，一部分给HDFS，一部分给HBase等，YARN配置的只是自己可以使用的，配置参数如下：

（1）yarn.nodemanager.resource.memory- – mb

表示该节点上YARN可使用的物理内存总量，默认是8192（MB），注意，如果你的节点内存资源不够8GB，则需要调减小这个值，而

YARN不会智能的探测节点的物理内存总量。

（2）yarn.nodemanager.vmem- – pmem- – ratio

任务每使用1MB物理内存，最多可使用虚拟内存量，默认是2.1。

（3）yarn.nodemanager.pmem- – check- – enabled

是否启动一个线程检查每个任务正使用的物理内存量，如果任务超出分配值，则直接将其杀掉，默认是true。

（4） yarn.nodemanager.vmem- – check- – enabled

是否启动一个线程检查每个任务正使用的虚拟内存量，如果任务超出分配值，则直接将其杀掉，默认是true。

（5）yarn.scheduler.minimum- – allocation- – mb

单个任务可申请的最少物理内存量，默认是1024（MB），如果一个任务申请的物理内存量少于该值，则该对应的值改为这个数。

（6）yarn.scheduler.maximum- – allocation- – mb

单个任务可申请的最多物理内存量，默认是8192（MB）。

默认情况下，YARN采用了线程监控的方法判断任务是否超量使用内存，一旦发现超量，则直接将其杀死。由于Cgroups对内存的控

制缺乏灵活性（即任务任何时刻不能超过内存上限，如果超过，则直接将其杀死或者报OOM），而Java进程在创建瞬间内存将翻

倍，之后骤降到正常值，这种情况下，采用线程监控的方式更加灵活（当发现进程树内存瞬间翻倍超过设定值时，可认为是正常

现象，不会将任务杀死），因此YARN未提供Cgroups内存隔离机制。

CPU资源的调度和隔离：

目前的CPU被划分成虚拟CPU（CPU virtual Core），这里的虚拟CPU是YARN自己引入的概念，

初衷是，考虑到不同节点的CPU性能可能不同，每个CPU具有的计算能力也是不一样的，比如某个物

理CPU的计算能力可能是另外一个物理CPU的2倍，这时候，你可以通过为第一个物理CPU多配置几个

虚拟CPU弥补这种差异。用户提交作业时，可以指定每个任务需要的虚拟CPU个数。在YARN中，CPU

相关配置参数如下：

（1） yarn.nodemanager.resource.cpu- – vcores

表示该节点上YARN可使用的虚拟CPU个数，默认是4，注意，目前推荐将该值设值为与物理CPU核数

数目相同。如果你的节点CPU核数不够8个，则需要调减小这个值，而YARN不会智能的探测节点的物

理CPU总数。

（2）  yarn.scheduler.minimum- – allocation- – vcores

单个任务可申请的最小虚拟CPU个数，默认是1，如果一个任务申请的CPU个数少于该数，则该对应

的值改为这个数。

（3） yarn.scheduler.maximum- – allocation- – vcores

单个任务可申请的最多虚拟CPU个数，默认是32。

默认情况下，YARN是不会对CPU资源进行调度的，你需要配置相应的资源调度器。

【若泽大数据】生产场景：

内存改完参数 Yarn是要重启的

1.计算及时性要求比较高：memory不够，cpu是足够的，作业肯定是要挂掉的，立即手工调整oom，设置大，快速出结果，

2.计算机及时性不高：memory够，cpu不够，计算慢，

需求5分钟出1个job：job运行1分钟的时候，oom了内存不够，shell脚本里面可以改参数，修改脚本内存就自动加，

生产：cpu物理和虚拟的比例是1:2的关系（默认）， 有的生产会设置1:1