Spark-submit模式yarn-cluster和yarn-client的区别

yarn,Yet Another Resource Negotiator ，是 Hadoop 自 0.23.0 版本后新的 map-reduce 框架

旧的MapReduce架构 、 在Hadoop2.0中, YARN负责管理MapReduce中的资源(内存, CPU等)并且将其打包成Container. 这样可以精简MapReduce, 使之专注于其擅长的数据处理任务, 将无需考虑资源调度. YARN会管理集群中所有机器的可用计算资源. 基于这些资源YARN会调度应用(比如MapReduce)发来的资源请求, 然后YARN会通过分配Container来给每个应用提供处理能力 在Hadoop集群中，平衡内存（RAM）、处理器（CPU核心）和磁盘的使用是至关重要的，合理规划以免某一项引起瓶颈制约。一般的建议是，一块磁盘和一个CPU核心上配置两个Container会达到集群利用率的最佳平衡,Container是YARN中处理能力的基本单元, 是对内存, CPU等的封装 从可用的硬件资源角度看，要调整群集每个节点Yarn和MapReduce的内存配置到合适的数据，应注意以下几个重要的元素： 保留内存=保留系统内存+保留HBase内存（如果HBase是在同一个节点） 下面的计算是确定每个节点的Container允许的最大数量。 Container数量=min (2 CORES, 1.8 DISKS, (可用内存)/最低Container的大小) 最低Container的大小 这个值是依赖于可用的RAM数量——在较小的存储节点，最小的Container的大小也应较小。下面的表列出了推荐值： 最后计算的每个Container的内存大小是 每个Container的内存大小 = max(最小Container内存大小, (总可用内存) /Container数)) YARN 的核心就是将jobTracker的功能进行拆解，分成了资源管理和任务调度监控两个进程，一个全局的资源管理和每个作业的管理。ResourceManager和Nodemanager提供了计算资源的分配和管理，ApplicationMaster负责完成程序的运行.YARN架构下形成了一个通用的资源管理平台和一个通用的应用计算平，避免了旧架构的单点问题和资源利用率问题，同时也让在其上运行的应用不再局限于MapReduce形式 理想情况下，我们应用对 Yarn 资源的请求应该立刻得到满足，但现实情况资源往往是 有限的，特别是在一个很繁忙的集群，一个应用资源的请求经常需要等待一段时间才能的到 相应的资源。在Yarn中，负责给应用分配资源的就是Scheduler。其实调度本身就是一个 难题，很难找到一个完美的策略可以解决所有的应用场景。为此Yarn提供了多种调度器 和可配置的策略供我们选择。在 Yarn 中有三种调度器可以选择：FIFO Scheduler ，Capacity Scheduler，Fair Scheduler。

linux配置yarn 1.配置mapred-site.xml cd /opt/hadoop/hadoop-2.8.5/etc/hadoop/ cp mapred-site.xml.template mapred-site.xml vim mapred-site.xml <configuration> <!--通知框架M

yarn的组成可以从两个角度看待： 其中，在master node上运行 ResourceManager 。 每个datanode上运行一个 NodeManager 。 并把该dataNode上的所有计算资源（CPU、内存）视为一个/多个 Container ，而Container可以被分配执行一个task(ApplicationMaster、map task、reduce task等)。 具体可看下图： 可结合上文的图片理解 Container是Yarn框架的计算单元，是具体执行应用task（如map task、reduce task）的基本单位。 Container和集群节点的关系是： 一个节点会运行多个Container，但一个Container不会跨节点 。 一个Container就是一组分配的系统资源，现阶段只包含两种系统资源（之后可能会增加磁盘、网络等资源）： 既然一个Container指的是具体节点上的计算资源，这就意味着Container中必定含有计算资源的位置信息：计算资源位于哪个机架的哪台机器上。 所以我们在请求某个Container时，其实是向某台机器发起的请求，请求的是这台机器上的CPU和内存资源 。 任何一个job或application必须运行在一个或多个Container中 。在Yarn框架中，ResourceManager只负责告诉ApplicationMaster哪些Containers可以用，ApplicationMaster还需要去找NodeManager请求分配具体的Container。 NodeManager进程运行在集群中的节点上，每个节点都会有自己的NodeManager。NodeManager是一个slave服务： 通过和ResourceManager配合，NodeManager负责整个Hadoop集群中的资源分配工作。 NodeManager只负责管理自身的Container，它并不知道运行在它上面应用的信息。负责管理应用信息的组件是ApplicationMaster，在后面会讲到。 ResourceManager主要有两个组件：Scheduler和ApplicationManager。 另一个组件ApplicationManager的功能如下： ApplicationMaster运行在Container中。 ApplicationMaster的主要作用是 向ResourceManager申请资源并和NodeManager协同工作来运行应用的各个任务 然后跟踪它们状态及监控各个任务的执行，遇到失败的任务还负责重启它。 1.client向yarn提交job，首先找ResourceManager分配资源， 2.ResourceManager开启一个Container,在Container中运行一个Application manager 3.Application manager找一台nodemanager启动Application master，计算任务所需的计算 4.Application master向Application manager（Yarn）申请运行任务所需的资源 5.Resource scheduler将资源封装发给Application master 6.Application master将获取到的资源分配给各个nodemanager 7.各个nodemanager得到任务和资源开始执行map task 8.map task执行结束后，开始执行reduce task 9.map task和 reduce task将执行结果反馈给Application master 10.Application master将任务执行的结果反馈pplication manager。 各个组件的功能 一个Job的提交过程 https://www.cnblogs.com/yangsy0915/p/5559969.html 功能与运行过程 https://blog.csdn.net/yu0_zhang0/article/details/78907178 ResourceManager详解 http://dongxicheng.org/mapreduce-nextgen/yarnmrv2-resource-manager-infrastructure/ namenode与dataNode关系 https://blog.csdn.net/u011414200/article/details/50350154 解析Partition https://www.cnblogs.com/xwdreamer/archive/2011/10/27/2296943.html

这个词语第一次听,我网上找了下拉毛纱是不是就是马海毛.是的话,英文就是mohair

u2003u2003Yarn 是 Hadoop 的资源管理系统，用于取代 MapReduce1 的资源调度，改善 MapReduce 的实现，并且有足够的通用性，可以支持其他的分布式计算模式 u2003u2003一般情况下，应用不直接使用 Yarn 的API，而是通过一些分布式计算框架（MapReduce、Spark等）来间接实现资源调度管理，使用这些框架的 Yarn 应用运行在集群计算层（Yarn）和集群存储层（HDFS、HBase）上。 u2003u2003Yarn 主要由两部分组成：resource manager、node manager。 u2003u2003资源管理器（resource manager）管理集群上资源的使用，节点管理器（node manager）运行在集群中所有节点上且能够启动和监控容器（container）。容器用于执行特定应用程序的进程，每个容器都有资源限制（内存、CPU）。 u2003u2003在 Yarn 上运行一个应用的步骤如图所示： u2003u2003在 MapReduce1中，有两类守护进程控制作业执行过程： jobtracker、tasktracker 。 u2003u2003jobtracker 通过调度 tasktracker 上运行的任务来协调所有运行在系统上的作业，记录每项作业任务的整体进度情况，若有任务失败，则在另一个 tasktracker 节点上重新调度该任务。 u2003u2003tasktracker 在运行任务的同时将运行进度报告发送给 job tracker。 u2003u2003MapReduce1 的 jobtracker 既要负责资源管理（作业的调度分配），将任务分配给不同的 tasktracker；又要负责任务进度的监控。如果集群非常繁忙，每时每刻都有大量的作业，每个作业下又有很多任务，jobtracker 需要面面俱到了解每个任务的执行情况，负担很重。 u2003u2003在 MapReduce2 对 Yarn 的应用中，一般是会先让 RM 启动容器运行一个 Application Master 的进程，然后该进程负责创建和监控所有的 map task 和 reduce task，了解每个 task 的执行进度，每个 task 都会运行在一个单独的 container 中，这些 container 都是 Application Master 统一调度负责向 RM 申请的，这样就把资源分配和作业运行调度监控解耦，让 Yarn 专注于资源调度。 u2003u2003FIFO 调度器将应用放置在一个队列中，然后按照提交的顺序（先入先出）运行应用。 【优点】简单易懂，不需要任何配置。 【缺点】不适合共享集群。大的应用会占用集群的所有资源，每个应用必须等待直到轮到自己运行，作业平均等待时间较长。 u2003u2003为了避免小作业被大作业阻塞，容量调度器会创建几个队列，其中会有专门队列给小作业执行，保证一提交就可以启动。 u2003u2003每个队列都被分配了一定比例容量的资源，保证大作业不会占用整个集群的所有资源。一般每个队列对应一个组织，这样就允许了多个组织共享一个 Hadoop 集群，每个组织可以分配到集群资源的一部分。队列可以进一步按层次划分，这样每个组织内的不同用户能够共享该组织队列所分配的资源。 u2003u2003在一个队列内，使用 FIFO 调度策略对应用进行调度，但是一个job可能使用不了整个队列的资源。然而如果这个队列中运行多个job，如果这个队列的资源够用，那么就分配给这些job。 u2003u2003官方文档： https://hadoop.apache.org/docs/r2.7.3/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html 。 u2003u2003容量调度器是 Hadoop2.7 默认的调度器，在 yarn-site.xml 中通过以下参数配置： u2003u2003 "弹性队列" ：如果队列 queue 资源不够用了，而其他队列可能是有空闲可用的资源，那么容量调度器可能会将空余的资源分配给队列 queue 中的队列，这种特性称为 "弹性队列"。可以通过 yarn.scheduler.capacity.<queue-path>.maximum-capacity 参数来控制队列最大占用集群资源容量的比例。 u2003u2003示例： u2003u2003在 root 队列下定义两个队列：prod、dev。分别占用集群 40%、60% 的容量。 u2003u2003prod 没有设置最大容量限制，所以当 dev 队列空闲，prod 资源不足时，可能会占用整个集群 100% 的资源。 u2003u2003dev 队列设置了最大容量显示为 75%，也就是及时另外 25% 的资源空闲，dev 最大也只能占用整个集群 75% 的资源。dev 队列下还有子队列 eng、science，容量都是 dev 容量的 50%，没有为子队列设置最大容量，所以每个子队列最大都可能占用 dev 队列 100% 的资源，所以占用的整个集群的绝对资源大小为 30%~75%。 u2003u2003将上述示例的配置添加到 hadoop 配置文件目录下的 capacity-scheduler.xml 中，启动 Yarn，上控制台（ http://192.168.190.111:8088/cluster/scheduler ）可以看到配置的队列容量限制。 u2003u2003查看配置的每个队列的容量限制是否生效。 u2003u2003可以看到 prod 队列容量限制是 40%，最大容量限制不设置则默认为 100%。 u2003u2003dev 的两个子队列，占用 dev 队列的相对容量大小为 50%~100%，占用整个集群的绝对容量大小为 30%~100%。 u2003u2003默认的容量调度器配置 u2003u2003公平调度器就是在队列内，所有的作业平等地分配资源，如果队列中只有一个作业，可以占用 100% 的资源；此时进来一个新的作业，则会调度到每个作业占用 50% 的资源，以此类推。 u2003u2003公平调度器不仅实现了队列内部的公平，还实现了队列之间的公平。 u2003u2003现在有两个队列 A、B。当 A 执行第一个作业，而 B 没有作业时，A可以占用整个集群的资源；当 A 作业还没完成，B 执行一个作业，则经过一段时间之后，两个作业各占用集群一半的资源；当 B 启动第二个作业时，队列内部的两个队列共享队列 B 的资源，经过一段时间，各占用集群 1/4 的资源，A 继续占用一半的集群资源。最终结果就是资源在用户之间实现了公平共享。 u2003u2003官方文档： https://hadoop.apache.org/docs/r2.7.3/hadoop-yarn/hadoop-yarn-site/FairScheduler.html 。 u2003u2003启用公平调度器，在 yarn-site.xml 中添加以下配置： u2003u2003创建公平调度配置文件 fair-scheduler.xml，内容如下： u2003u2003公平调度器使用一个规则列表来确定应用应该放到哪个队列，可配置的值和含义如下： u2003u2003将上述的配置配置好，启用 Yarn，web console 上看到的调度器如下：

什么是YARN？ Apache Hadoop YARN 是一种新的 Hadoop 资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的 资源管理和调度 ，它的引入为集群在 利用率 、 资源统一管理 和 数据共享 等方面带来了巨大好处。也就是说 YARN 在 Hadoop 集群中充当 资源管理 和 任务调度 的框架 负责资源管理和调度的组件：全局的资源管理器 ResourceManager（RM）和每个应用程序的 ApplicationMaster（AM）。应用程序可以是单个作业，也可以是 DAG 作业。ResourceManager 和 NodeManager 组成数据计算框架。 ResourceManager 负责集群资源的统一管理和调度； NodeManager 负责单节点资源管理和使用，处理来自 ResourceManager/ApplicationMaster 的命令; ApplicationMaster 负责应用程序的管理; Container 是对任务运行环境的抽象，描述任务运行资源（节点、内存、CPU）, 启动命令以及环境 我们都希望自己提交的作业能够很快被调度并且拿到足够的资源保证 job 进行顺畅。对于共享型集群来说，保证每个作业可以被合理的调度并分配相应的资源，同时考虑成本问题，变得更加困难。但是通过不断的探索 Yarn 的调度策略与可配置方案也可以逐渐接近目标。 Yarn 提供了三种可用资源调度器 (直接从 MRv1 基础上修改而来的)： FIFO Scheduler ， Capacity Scheduler ， Fair Scheduler FIFO Scheduler ：从字面不难看出就是先进先出策略，所有的任务都放在 一个队列 中，只有 执行完一个任务后 ， 才会进行下一个 。这种调度方式最简单，但真实场景中并不推荐，因为会有很多问题，比如如果有大任务独占资源，会导致其他任务一直处于 pending 状态等。 Capacity Scheduler ：也就是所谓的容量调度，这种方案更适合 多租户安全地共享大型集群 ，以便在分配的 容量限制下 及 时分配资源 。采用队列的概念，任务提交到队列， 队列 可以设置 资源的占比 ，并且支持层级队列、访问控制、用户限制、预定等等配置。不过对于资源占用比需要不断的摸索与权衡 Fair Scheduler ：就是公平调度器，能够 公平地共享大型集群中的资源 ，Fair 调度器会为所有运行的 job 动态的调整系统资源。当只有一个 job 在运行时，该应用程序最多可获取所有资源，再提交其他 job 时，资源将会被重新分配分配给目前的 job，这可以让 大量 job 在合理的时间内完成，减少作业 pending 的情况 。可见 Fair Schedule 比较适用于多用户共享的大集群 随着 Hadoop 版本逐渐演化，Fair Scheduler 和 Capacity Scheduler 的功能越来越完善，因此两个调度器的功能也逐渐趋近，由于 Fair Scheduler 支持多种调度策略，因此可以认为 Fair Scheduler 具备了 Capacity Scheduler 的所有功能 实践与探索 通过分析常见的几种调度器，选用 Fair Schedule 调度器更适合共享型大集群，那么怎样的配置方案更适合多团队多用户呢？资源该按照什么比例分配给队列？用户的不同作业类型该如何区分？每个用户都希望自己可以享用更大的资源，又该如何保证成本问题？...... 实际情况下遇到的问题不计其数，不同的集群规模和应用场景也有不同阶段的问题，都是需要经过探索与实践去逐一攻破。 Fair Scheduler 支持的自定义配置项 minResource：最小资源保证 maxResource：最多可以使用的资源 maxRunningApps：最多同时运行作业数量 minSharePreemptionTimeout：最小共享量抢占时间 schedulingMode/schedulingPolicy：队列采用的调度模式 aclSubmitApps：可在队列中提交作业的用户列表 aclAdministerApps：队列的管理员列表 userMaxJobsDefault：用户的 maxRunningJobs 属性默认值 defaultMinSharePreemptionTimeout：队列 minSharePreemptionTimeout 属性默认值 defaultPoolSchedulingMode：队列 schedulerMode 属性默认值 fairSharePreemptionTimeout：公平共享量抢占时间 fairSharePreemptionThreshold：队列的公平份额抢占阈值，默认值是 0.5f allowPreemptionFrom：确定是否允许调度程序抢占队列中的资源，默认为 true （另外通过配置 yarn-site.xml 的 yarn.scheduler.fair.preemption 可以控制集群是否开启抢占功能） 抢占：当某个队列中有剩余资源，调度器会将这些资源共享给其他队列，而当该队列中有新的应用程序提交时，调度器会为它回收资源。那些超额使用的行为即为超发。 划分队列组织结构 合理的队列组织方案也十分重要，如下图就是小米的队列组织模型： 一级队列 ：root 队列下面分为三大队列 离线分析 MR/Spark 作业队列：默认开启抢占，大量离线作业比较耗费资源，但是作业等级不算高，因此为了提高资源的利用率，可以允许在集群资源空闲的时候尽可能的超发资源，当然也意味着超发的资源会被回收; 在线计算流式作业队列：针对于作业等级较高的服务，为了保证资源需要设置不支持抢占，当然也需要设置最大超发限制，避免出现集群大作业独占集群资源； 资源池 reserved 队列：预留资源来保证新队列增加，或者其他队列的资源增配相当于资源池的概念，当然也可用于作业超发使用。 二级 / 三级 / 四级队列： 资源与成本优化 总结 可能资源调度并没有最优解，需要不断探索实践去寻找适合目前现状的方案；在发展的不同阶段遇到不同的问题，通过解决问题逐渐去优化和完善。 参考自 https://mp.weixin.qq.com/s/8_1qC0LL_Q8Xf9YIWAa1Zg

Yarn，又名MRv2，由于Hadoop1的MR计算框架的缺陷应运而生。 1.首先了解下MRv1的体系，主要分为JobTraker和TaskTracker，其中，每当有新的job提交时该job的相关信息就会提交到JobTraker，然后JobTraker就要全程管理这个job，包括启动，失败时重启和针对任务数量分配在合适的TaskTracker中(每个task占用一个对应slot的资源)，另外，TaskTracker还需要周期性反馈这些task的完成情况以及节点的资源状况。也就是说JobTraker既要负责管理所有job的执行(比如失败了需要JobTraker来命令其重启)，还要负责所有job的资源调度(包括分配和监听资源变化)，这给JobTraker带来了很大压力和资源消耗。 而具体的资源分配是：JobTraker会根据各个节点(每个节点管理一个TaskTracker)上的资源状况(maptask slot和reduce slot有多少个)来进行将job的maptask和reducetask分配到合适的位置，这样的TaskTracker也非常的死板，有如下两个缺点： ①生硬的把资源分成map和reduce两种类型，不能灵活转换，如果一个节点上只剩下reduce slot的资源，就无法执行maptask，浪费了这些资源 ②slot的资源过于固定，不灵活，没有考虑每个(map or reduce)task的区别，前面MR我们也有讲到，虽然每个maptask都是处理一个split分片，但是map的运算逻辑不同可能导致所需要的资源差异很大，比如有些内存消耗很大的maptask都分配到了同一个TaskTracker，就会造成内存溢出 于是，我们来看下Yarn做了什么变化吧： 1.将JobTraker分成 全局资源 管理层面的ResourceManager(RM，全局一个)和作业执行层面的Application Master(AM,一个job对应一个，负责每个作业的具体执行，以及资源调度，比如根据具体的job拆分成多个maptask和reducetask，然后和RM去申请资源，RM根据S)。 2.将TaskTraker改为NodeManager(NM，定期向RM汇报资源状况，维护该节点中container的状态)，且资源单位不再是死板的map/reduce slop，而是可以动态变化的Container，Container即可以给map用也可以给reduce使用，是按需分配的(只有两种需求：CPU和内存)，比如内存型就分配多些内存资源 接下来，具体介绍下流程：

您好，很高兴能帮助您，本文介绍YARN自带的一个非常简单的应用程序实例—distributedshell的使用方法。它可以看做YARN编程中的“hello world”，主要功能是并行执行用户提供的shell命令或者shell脚本。（1）运行参数介绍DistributedShell的基本运行参数如下：（2）运行方法DistributedShell的运行方法如下：在YARN安装目录下，执行以下命令：bin/hadoop jarshare/hadoop/yarn/hadoop-yarn-applications-distributedshell-2.0.0-cdh4.1.1.jarorg.apache.hadoop.yarn.applications.distributedshell.Client–jar share/hadoop/yarn/hadoop-yarn-applications-distributedshell-2.0.0-cdh4.1.1.jar–shell_command ls–shell_script ignore.sh–num_containers 10–container_memory 350–master_memory 350–priority 10需要注意的是，在hadoop-2.0.3-alpha（不包括该版本）和CDH 4.1.2版本（包括该版本）之前，DistributedShell存在BUG，具体如下：1） 必须使用–shell_command参数2） 当只有shell_command参数而没有shell_script参数时，在分布式模式下（伪分布式下可以）不能执行成功，具体说明和修复方法见： https //issues apache org/jira/browse/YARN-253在这个实例中，ignore.sh中的内容就是“ls”3） 内存设置一定要正确，不然会出现以下提示的错误：Container [pid=4424,containerID=container_1359629844156_0004_01_000001] is running beyond virtual memory limits. Current usage: 90.1mb of 128.0mb physical memory used; 593.0mb of 268.8mb virtual memory used. Killing container.【附】DistributedShell运行日志：13/02/01 13:43:11 INFO distributedshell.Client: Initializing Client 13/02/01 13:43:11 INFO distributedshell.Client: Starting Client 13/02/01 13:43:11 INFO distributedshell.Client: Connecting to ResourceManager at c2-23/10.1.1.98:8032 13/02/01 13:43:12 INFO distributedshell.Client: Got Cluster metric info from ASM, numNodeManagers=3 13/02/01 13:43:12 INFO distributedshell.Client: Got Cluster node info from ASM 13/02/01 13:43:12 INFO distributedshell.Client: Got node report from ASM for, nodeId=c2-23:36594, nodeAddressc2-23:8042, nodeRackName/default-rack, nodeNumContainers0, nodeHealthStatusis_node_healthy: true, health_report: “”, last_health_report_time: 1359697377337, 13/02/01 13:43:12 INFO distributedshell.Client: Got node report from ASM for, nodeId=c2-25:41070, nodeAddressc2-25:8042, nodeRackName/default-rack, nodeNumContainers0, nodeHealthStatusis_node_healthy: true, health_report: “”, last_health_report_time: 1359697367180, 13/02/01 13:43:12 INFO distributedshell.Client: Got node report from ASM for, nodeId=c2-24:48383, nodeAddressc2-24:8042, nodeRackName/default-rack, nodeNumContainers0, nodeHealthStatusis_node_healthy: true, health_report: “”, last_health_report_time: 1359699033102, 13/02/01 13:43:12 INFO distributedshell.Client: Queue info, queueName=default, queueCurrentCapacity=0.0, queueMaxCapacity=1.0, queueApplicationCount=0, queueChildQueueCount=0 13/02/01 13:43:12 INFO distributedshell.Client: User ACL Info for Queue, queueName=default, userAcl=SUBMIT_APPLICATIONS 13/02/01 13:43:12 INFO distributedshell.Client: User ACL Info for Queue, queueName=default, userAcl=ADMINISTER_QUEUE 13/02/01 13:43:12 INFO distributedshell.Client: Got new application id=application_1359695803957_0003 13/02/01 13:43:12 INFO distributedshell.Client: Min mem capabililty of resources in this cluster 128 13/02/01 13:43:12 INFO distributedshell.Client: Max mem capabililty of resources in this cluster 10240 13/02/01 13:43:12 INFO distributedshell.Client: Setting up application submission context for ASM 13/02/01 13:43:12 INFO distributedshell.Client: Copy App Master jar from local filesystem and add to local environment 13/02/01 13:43:13 INFO distributedshell.Client: Set the environment for the application master 13/02/01 13:43:13 INFO distributedshell.Client: Trying to generate classpath for app master from current thread"s classpath 13/02/01 13:43:13 INFO distributedshell.Client: Readable bytes from stream=9006 13/02/01 13:43:13 INFO distributedshell.Client: Setting up app master command 13/02/01 13:43:13 INFO distributedshell.Client: Completed setting up app master command ${JAVA_HOME}/bin/java -Xmx350m org.apache.hadoop.yarn.applications.distributedshell.ApplicationMaster –container_memory 350 –num_containers 10 –priority 0 –shell_command ls 1>/AppMaster.stdout 2>/AppMaster.stderr 13/02/01 13:43:13 INFO distributedshell.Client: Submitting application to ASM 13/02/01 13:43:14 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=N/A, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=ACCEPTED, distributedFinalState=UNDEFINED, appTrackingUrl=c2-23:8088/proxy/application_1359695803957_0003/, appUser=rmss 13/02/01 13:43:15 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=RUNNING, distributedFinalState=UNDEFINED, appTrackingUrl=, appUser=rmss 13/02/01 13:43:16 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=RUNNING, distributedFinalState=UNDEFINED, appTrackingUrl=, appUser=rmss 13/02/01 13:43:17 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=RUNNING, distributedFinalState=UNDEFINED, appTrackingUrl=, appUser=rmss 13/02/01 13:43:18 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=RUNNING, distributedFinalState=UNDEFINED, appTrackingUrl=, appUser=rmss 13/02/01 13:43:19 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=FINISHED, distributedFinalState=SUCCEEDED, appTrackingUrl=, appUser=rmss 13/02/01 13:43:19 INFO distributedshell.Client: Application has completed successfully. Breaking monitoring loop 13/02/01 13:43:19 INFO distributedshell.Client: Application completed successfully你的采纳是我前进的动力，还有不懂的地方，请你继续“追问”！如你还有别的问题，可另外向我求助；答题不易，互相理解，互相帮助！

yarn是为了提高资源利用率，也就是多类程序的资源分配。而zookeeper是分布式程序的协调服务，可以说是某一类程序。zookeeper是相对多台机器同一分布式程序来说的，yarn可以针对一台服务器多个程序资源进行协调

在实际系统中，资源本身是多维度的，包括CPU、内存、网络I/O和磁盘I/O等，因此，如果想精确控制资源分配，不能再有slot的概念，最直接的方法就是是让任务直接向调度器申请自己需要的资源（比如某个任务可申请1GB 内存和1个CPU），而调度器则按照任务实际需求为其精细地分配对应的资源量，不再简单的将一个Slot分配给它，Hadoop 2.0正式采用了这种基于真实资源量的资源分配方案。 Hadoop 2.0最基本的设计思想是将JobTracker的两个主要功能，即资源管理和作业调度/监控分成两个独立的进程。全局的ResourceManager（RM）和与每个应用相关的ApplicationMaster（AM）。 ResourceManager(RM) ：负责对各NM上的资源进行统一管理和调度。对AM申请的资源请求分配相应的空闲Container。将AM分配空闲的Container运行并监控其运行状态。主要由两个组件构成：调度器和应用程序管理器。 调度器(Scheduler) ：调度器根据容量、队列等限制条件，将系统中的资源分配给各个正在运行的应用程序。调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位是Container，从而限定每个任务使用的资源量。Shceduler不负责监控或者跟踪应用程序的状态，也不负责任务因为各种原因而需要的重启（由ApplicationMaster负责）。 调度器是可插拔的，例如CapacityScheduler、FairScheduler。 应用程序管理器(Applications Manager) ：应用程序管理器负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动AM、监控AM运行状态并在失败时重新启动等，跟踪分给的Container的进度、状态也是其职责。 NodeManager(NM) ：NM是每个节点上的资源和任务管理器。它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态；同时会接收并处理来自AM的Container 启动/停止等请求。 ApplicationMaster(AM) ：用户提交的应用程序均包含一个AM，负责应用的监控，跟踪应用执行状态，重启失败任务等。AM是应用框架，它负责向RM协调资源，并且与NM协同工作完成Task的执行和监控。MapReduce就是原生支持的一种框架，可以在YARN上运行Mapreduce作业。有很多分布式应用都开发了对应的应用程序框架，用于在YARN上运行任务，例如Spark，Storm等。 Container ：是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container 表示的。YARN会为每个任务分配一个Container且该任务只能使用该Container中描述的资源。 1）用户向YARN中提交应用程序，其中包括ApplicationMaster程序、启动AM的命令、用户程序等。 2）ResourceManager为该应用程序分配第一个Container，并与对应的Node Manager通信，要求它在这个Container中启动应用程序的AM。 3）AM首先向RM注册，这样用户可以直接通过RM查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤4~7。 4）AM采用轮询的方式通过RPC协议向RM申请和领取资源。 5）一旦AM申请到资源后，便与对应的NM通信，要求它启动任务。 6）NM为任务设置好运行环境（包括环境变量、JAR包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。 7）各个任务通过某个RPC协议向AM汇报自己的状态和进度，以让AM随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可随时通过RPC向AM查询应用程序的当前运行状态。 8）应用程序运行完成后，AM向RM注销并关闭自己。 当用户向YARN中提交一个应用程序后，YARN将分两个阶段运行该应用程序：第一个阶段是启动AM；第二个阶段是由AM创建应用程序，为它申请资源，并监控它的整个运行过程，直到运行完成。 ResourceManager将某个NodeManager上资源分配给任务（资源调度）后，NodeManager需按照要求为任务提供相应的资源，甚至保证这些资源应具有独占性，为任务运行提供基础的保证（资源隔离）。 内存资源 1）yarn.nodemanager.resource.memory-mb 该节点上YARN可使用的物理内存总量： 假设我的这个节点上的内存有48G，其中25%是要给Linux的，而剩余的75%给大数据进程。其中，一般把DN和NM放置在同一个机器上(数据本地化)。默认的DN是给到4个G，而NM是给到3个G。（这两个参数分别是在hadoop-env.sh和yarn-env.sh两个shell脚本当中设置)。 我们的contanier最多也就可以用29个G了， yarn.nodemanager.resource.memory-mb，当这个参数设置成剩余全部内存时意味着我们的NM在执行tasks的时候可以使用到29个G。 2）yarn.scheduler.minimum-allocation-mb 单个任务可申请的最少物理内存量： 一个contnaier最小将分配多少的G，我们生产上一般是设置成2个G，要是机器上剩余的内存达不到2个G，就不再在这个机器上开启container。 3）yarn.scheduler.maximum-allocation-mb 单个任务可申请的最多物理内存量 当一个container开启以后，在上面放置的task不是一下子就使用到最大内存极限的，一般会先个2个G(就是最小内存限制)，如果不够了就是继续增加，直到最大内存限制，还不够就报错。所以最大内存设置一般和整个节点的contanier可用内存设置是一样大。 4.2. CPU资源 vcore：虚拟cpu，yarn自己引入的新概念，因为不同的物理core的性能不同，所以为了每个core的计算能力能一致点，这个时候设置了一个vcore。一般1个物理core对应2个vcore，也有公司是1:1的。 cpu同样也有三组参数： yarn.nodemanager.resource.cpu-vcores yarn.scheduler.minimum-allocation-vcores yarn.scheduler.maximum-allocation-vcores 三组默认值分别是8，1，8。假如物理core是8个话，要考虑究竟要个多少个core给大数据使用。如果是给了6个core预留2个core给其他进程，这样的vcore将有12个。 FIFO Scheduler把应用按提交的顺序排成一个队列，这是一个 先进先出队列，在进行资源分配的时候，先给队列中最头上的应用进行分配资源，待最头上的应用需求满足后再给下一个分配，以此类推。 FIFO Scheduler是最简单也是最容易理解的调度器，也不需要任何配置，但它并不适用于共享集群。大的应用可能会占用所有集群资源，这就导致其它应用被阻塞。在共享集群中，更适合采用Capacity Scheduler或Fair Scheduler，这两个调度器都允许大任务和小任务在提交的同时获得一定的系统资源。 从图中可以看出，在FIFO 调度器中，小任务会被大任务阻塞。 而对于Capacity调度器，有一个专门的队列用来运行小任务，但是为小任务专门设置一个队列会预先占用一定的集群资源，这就导致大任务的执行时间会落后于使用FIFO调度器时的时间。 在Fair调度器中，我们不需要预先占用一定的系统资源，Fair调度器会为所有运行的job动态的调整系统资源。如图所示，当第一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。 需要注意的是，在图Fair调度器中，从第二个任务提交到获得资源会有一定的延迟，因为它需要等待第一个任务释放占用的Container。小任务执行完成之后也会释放自己占用的资源，大任务又获得了全部的系统资源。最终的效果就是Fair调度器即得到了高的资源利用率又能保证小任务及时完成。 调度器的使用是通过yarn-site.xml配置文件中的 yarn.resourcemanager.scheduler.class 参数进行配置的，默认采用Capacity Scheduler调度器。如果我们要使用Fair调度器，需要在这个参数上配置FairScheduler类的全限定名： org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler 。

YARN的编程模型1：保证编程模型的向下兼容性，MRv2重用了MRv1的编程模型和数据处理引擎，但运行环境被重写。2：编程模型与数据处理引擎mapreduce应用程序编程接口有两套：新的API（mapred)和旧的API（mapreduce）采用MRv1旧的API编写的程序可直接运行在MRv2上采用MRv1新的API编写的程序需要使用MRv2编程库重新编译并修改不兼容的参数 和返回值 3：运行时环境MRv1:Jobracker和TasktrackerMRv2:YARN和ApplicationMasterYARN的组成yarn主要由ResourceManager，NodeManager，ApplicationMaster和Container等几个组件组成。ResourceManager（RM）RM是全局资源管理器，负责整个系统的资源管理和分配。主要由两个组件组成：调度器和应用 程序管理器（ASM）调度器调度器根据容量，队列等限制条件，将系统中的资源分配给各个正在运行的应用程序不负责具体应用程序的相关工作，比如监控或跟踪状态不负责重新启动失败任务资源分配单位用“资源容器”resource Container表示Container是一个动态资源分配单位，它将内存，CPU,磁盘，网络等资源封装在一起，从而限定每个任务的资源量调度器是一个可插拔的组件，用户可以自行设计YARN提供了多种直接可用的调度器，比如fair Scheduler和Capacity Scheduler等。应用程序管理器负责管理整个系统中所有应用程序ApplicationMaster(AM)用户提交的每个应用程序均包含一个AMAM的主要功能与RM调度器协商以获取资源（用Container表示）将得到的任务进一步分配给内部的任务与NM通信以自动/停止任务监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务当前YARN自带了两个AM实现一个用于演示AM编写方法的实例程序distributedshell一个用于Mapreduce程序---MRAppMaster其他的计算框架对应的AM正在开发中，比如spark等。Nodemanager（NM）和ContainerNM是每个节点上的资源和任务管理器定时向RM汇报本节点上的资源使用情况和各个Container的运行状态接收并处理来自AM的Container启动/停止等各种要求Container是YARN中的资源抽象，它封装了某个节点上的多维度资源YARN会为每个任务分配一个Container，且改任务只能使用该Container中描述的资源Container不同于MRv1的slot，它是一个动态资源划分单位，是根据应用程序的需求动态产生的YARN主要由以下几个协议组成ApplicationClientProtocolJobclient通过该RPC协议提交应用才程序，查询应用程序状态等ResourceManagerAdministrationProtocolAdmin通过该协议更新系统配置文件，比如节点黑名单，用户队列权限等。ApplicationMasterProtocolAM通过该RPC协议想RM注册和撤销自己，并为各个任务申请资源ContainerManagementProtocolAM通过要求NM启动或者停止Container，获取各个Container的使用状态等信息ResourceTrackerNM通过该RPC协议向RM注册，并定时发送心跳信息汇报当前节点的资源使用情况和Container运行状况YARN的工作流程文字描述一下这个过程：1：由客户端提交一个应用，由RM的ASM接受应用请求提交过来的应用程序包括哪些内容：a:ApplicationMasterb:启动Applicationmaster的命令c:本身应用程序的内容2:提交了三部分内容给RM，然后RM找NodeManager,然后Nodemanager就启用Applicationmaster，并分配Container接下来我们就要执行这个任务了，3:但是执行任务需要资源，所以我们得向RM的ASM申请执行任务的资源（它会在RM这儿注册一下，说我已经启动了，注册了以后就可以通过RM的来管理，我们用户也可以通过RM的web客户端来监控任务的状态）ASM只是负责APplicationMaster的启用4::我们注册好了后，得申请资源，申请资源是通过第四步，向ResourceScheduler申请的5:申请并领取资源后，它会找Nodemanager，告诉他我应经申请到了，然后Nodemanager判断一下，6:知道他申请到了以后就会启动任务，当前启动之前会准备好环境，7:任务启动以后会跟APplicationmaster进行通信，不断的心跳进行任务的汇报。8:完成以后会给RM进行汇报，让RSM撤销注册。然后RSM就会回收资源。当然了，我们是分布式的，所以我们不会只跟自己的Nodemanager通信。也会跟其他的节点通信。

一、调度器的选择在Yarn中有三种调度器可以选择：FIFO Scheduler，Capacity Scheduler，FairS cheduler。 FIFO Scheduler把应用按提交的顺序排成一个队列，这是一个先进先出队列，在进行资源分配的时候，先给队列中最头上的应用进行分配资源，待最头上的应用需求满足后再给下一个分配，以此类推。 FIFO Scheduler是最简单也是最容易理解的调度器，也不需要任何配置，但它并不适用于共享集群。大的应用可能会占用所有集群资源，这就导致其它应用被阻塞。在共享集群中，更适合采用Capacity Scheduler或Fair Scheduler，这两个调度器都允许大任务和小任务在提交的同时获得一定的系统资源。 下面 “Yarn调度器对比图” 展示了这几个调度器的区别，从图中可以看出，在FIFO 调度器中，小任务会被大任务阻塞。 而对于Capacity调度器，有一个专门的队列用来运行小任务，但是为小任务专门设置一个队列会预先占用一定的集群资源，这就导致大任务的执行时间会落后于使用FIFO调度器时的时间。 在Fair调度器中，我们不需要预先占用一定的系统资源，Fair调度器会为所有运行的job动态的调整系统资源。如下图所示，当第一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。 需要注意的是，在下图Fair调度器中，从第二个任务提交到获得资源会有一定的延迟，因为它需要等待第一个任务释放占用的Container。小任务执行完成之后也会释放自己占用的资源，大任务又获得了全部的系统资源。最终的效果就是Fair调度器即得到了高的资源利用率又能保证小任务及时完成。 Yarn调度器对比图: 二、Capacity Scheduler（容器调度器）的配置 2.1 容器调度介绍 Capacity 调度器允许多个组织共享整个集群，每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列，然后再为每个队列分配一定的集群资源，这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。除此之外，队列内部又可以垂直划分，这样一个组织内部的多个成员就可以共享这个队列资源了，在一个队列内部，资源的调度是采用的是先进先出(FIFO)策略。 通过上面那幅图，我们已经知道一个job可能使用不了整个队列的资源。然而如果这个队列中运行多个job，如果这个队列的资源够用，那么就分配给这些job，如果这个队列的资源不够用了呢？其实Capacity调度器仍可能分配额外的资源给这个队列，这就是 “弹性队列”(queue elasticity) 的概念。 在正常的操作中，Capacity调度器不会强制释放Container，当一个队列资源不够用时，这个队列只能获得其它队列释放后的Container资源。当然，我们可以为队列设置一个最大资源使用量，以免这个队列过多的占用空闲资源，导致其它队列无法使用这些空闲资源，这就是”弹性队列”需要权衡的地方。 2.2 容器调度的配置 假设我们有如下层次的队列： root ├── prod └── dev ├── eng └── science 下面是一个简单的Capacity调度器的配置文件，文件名为capacity-scheduler.xml。在这个配置中，在root队列下面定义了两个子队列prod和dev，分别占40%和60%的容量。需要注意，一个队列的配置是通过属性yarn.sheduler.capacity..指定的，代表的是队列的继承树，如root.prod队列，一般指capacity和maximum-capacity。 我们可以看到，dev队列又被分成了eng和science两个相同容量的子队列。dev的maximum-capacity属性被设置成了75%，所以即使prod队列完全空闲dev也不会占用全部集群资源，也就是说，prod队列仍有25%的可用资源用来应急。我们注意到，eng和science两个队列没有设置maximum-capacity属性，也就是说eng或science队列中的job可能会用到整个dev队列的所有资源（最多为集群的75%）。而类似的，prod由于没有设置maximum-capacity属性，它有可能会占用集群全部资源。 Capacity容器除了可以配置队列及其容量外，我们还可以配置一个用户或应用可以分配的最大资源数量、可以同时运行多少应用、队列的ACL认证等。 2.3 队列的设置 关于队列的设置，这取决于我们具体的应用。比如，在MapReduce中，我们可以通过mapreduce.job.queuename属性指定要用的队列。如果队列不存在，我们在提交任务时就会收到错误。如果我们没有定义任何队列，所有的应用将会放在一个default队列中。 注意：对于Capacity调度器，我们的队列名必须是队列树中的最后一部分，如果我们使用队列树则不会被识别。比如，在上面配置中，我们使用prod和eng作为队列名是可以的，但是如果我们用root.dev.eng或者dev.eng是无效的。 三、Fair Scheduler（公平调度器）的配置 3.1 公平调度 Fair调度器的设计目标是为所有的应用分配公平的资源（对公平的定义可以通过参数来设置）。在上面的 “Yarn调度器对比图” 展示了一个队列中两个应用的公平调度；当然，公平调度在也可以在多个队列间工作。举个例子，假设有两个用户A和B，他们分别拥有一个队列。当A启动一个job而B没有任务时，A会获得全部集群资源；当B启动一个job后，A的job会继续运行，不过一会儿之后两个任务会各自获得一半的集群资源。如果此时B再启动第二个job并且其它job还在运行，则它将会和B的第一个job共享B这个队列的资源，也就是B的两个job会用于四分之一的集群资源，而A的job仍然用于集群一半的资源，结果就是资源最终在两个用户之间平等的共享。过程如下图所示： 3.2 启用Fair Scheduler 调度器的使用是通过yarn-site.xml配置文件中的yarn.resourcemanager.scheduler.class参数进行配置的，默认采用Capacity Scheduler调度器。如果我们要使用Fair调度器，需要在这个参数上配置FairScheduler类的全限定名：org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler。 3.3 队列的配置 Fair调度器的配置文件位于类路径下的fair-scheduler.xml文件中，这个路径可以通过yarn.scheduler.fair.allocation.file属性进行修改。若没有这个配置文件，Fair调度器采用的分配策略，这个策略和3.1节介绍的类似：调度器会在用户提交第一个应用时为其自动创建一个队列，队列的名字就是用户名，所有的应用都会被分配到相应的用户队列中。 我们可以在配置文件中配置每一个队列，并且可以像Capacity 调度器一样分层次配置队列。比如，参考capacity-scheduler.xml来配置fair-scheduler： 队列的层次是通过嵌套元素实现的。所有的队列都是root队列的孩子，即使我们没有配到元素里。在这个配置中，我们把dev队列有分成了eng和science两个队列。 Fair调度器中的队列有一个权重属性（这个权重就是对公平的定义），并把这个属性作为公平调度的依据。在这个例子中，当调度器分配集群40:60资源给prod和dev时便视作公平，eng和science队列没有定义权重，则会被平均分配。这里的权重并不是百分比，我们把上面的40和60分别替换成2和3，效果也是一样的。注意，对于在没有配置文件时按用户自动创建的队列，它们仍有权重并且权重值为1。 每个队列内部仍可以有不同的调度策略。队列的默认调度策略可以通过顶级元素进行配置，如果没有配置，默认采用公平调度。 尽管是Fair调度器，其仍支持在队列级别进行FIFO调度。每个队列的调度策略可以被其内部的元素覆盖，在上面这个例子中，prod队列就被指定采用FIFO进行调度，所以，对于提交到prod队列的任务就可以按照FIFO规则顺序的执行了。需要注意，prod和dev之间的调度仍然是公平调度，同样eng和science也是公平调度。 尽管上面的配置中没有展示，每个队列仍可配置最大、最小资源占用数和最大可运行的应用的数量。 3.4 队列的设置 Fair调度器采用了一套基于规则的系统来确定应用应该放到哪个队列。在上面的例子中，元素定义了一个规则列表，其中的每个规则会被逐个尝试直到匹配成功。例如，上例第一个规则specified，则会把应用放到它指定的队列中，若这个应用没有指定队列名或队列名不存在，则说明不匹配这个规则，然后尝试下一个规则。primaryGroup规则会尝试把应用放在以 用户所在的Unix组名 命名的队列中，如果没有这个队列，不创建队列转而尝试下一个规则。当前面所有规则不满足时，则触发default规则，把应用放在dev.eng队列中。 当然，我们可以不配置queuePlacementPolicy规则，调度器则默认采用如下规则：上面规则可以归结成一句话，除非队列被准确的定义，否则会以用户名为队列名创建队列。 还有一个简单的配置策略可以使得所有的应用放入同一个队列（default），这样就可以让所有应用之间平等共享集群而不是在用户之间。这个配置的定义如下：实现上面功能我们还可以不使用配置文件，直接设置yarn.scheduler.fair.user-as-default-queue=false，这样应用便会被放入default 队列，而不是各个用户名队列。另外，我们还可以设置yarn.scheduler.fair.allow-undeclared-pools=false，这样用户就无法创建队列了。 3.5 抢占（Preemption） 当一个job提交到一个繁忙集群中的空队列时，job并不会马上执行，而是阻塞直到正在运行的job释放系统资源。为了使提交job的执行时间更具预测性（可以设置等待的超时时间），Fair调度器支持抢占。 抢占就是允许调度器杀掉占用超过其应占份额资源队列的containers，这些containers资源便可被分配到应该享有这些份额资源的队列中。需要注意抢占会降低集群的执行效率，因为被终止的containers需要被重新执行。 可以通过设置一个全局的参数yarn.scheduler.fair.preemption=true来启用抢占功能。此外，还有两个参数用来控制抢占的过期时间（这两个参数默认没有配置，需要至少配置一个来允许抢占Container）： - minimum share preemption timeout - fair share preemption timeout 如果队列在minimum share preemption timeout指定的时间内未获得最小的资源保障，调度器就会抢占containers。我们可以通过配置文件中的顶级元素为所有队列配置这个超时时间；我们还可以在元素内配置元素来为某个队列指定超时时间。 与之类似，如果队列在fair share preemption timeout指定时间内未获得平等的资源的一半（这个比例可以配置），调度器则会进行抢占containers。这个超时时间可以通过顶级元素和元素级元素分别配置所有队列和某个队列的超时时间。上面提到的比例可以通过(配置所有队列)和(配置某个队列)进行配置，默认是0.5。

对的。Yarn Dyed FabricWhen a fabric is yarn dyed the color is placed in the yarn or threads before weaving as opposed to the color being printed on the fabric after being woven.

通过 yarn 局部卸载 xxx 包。 注意，此时你的电脑上实际上是有 2 个 @vue/cli ： 虽然可以，但是为了避免不必要的混淆和麻烦，我们可以『 将 npm 安装的 @vue/cli 卸载掉 』： <div style="display: none;"> 虽然现在你的 @vue/cli 是通过 yarn 安装的<small>（npm 安装的那个已经被你卸载了）</small>，但是 @vue/cli 『 默认使用 NPM 作为包管理器 』。 ::: tip 如何知道我的 vue-cli 是使用 NPM 作为包管理器的？ 当你使用 vue create xxx 创建 vue 项目结束后看到如下信息，那么毫无疑问 vue-cli 使用的就是 NPM： ::: 如果有需要，你可以通过设置，去提前『 告知 』@vue/cli 创建的 vue 项目使用 Yarn 作为包管理器。 无论是通过 npm 还是通过 Yarn 全局安装 @vue/cli，@vue/cli 会在你的用户的『 家目录 』下创建一个名为 .vuerc 的文件<small>（一开始可能没有，在你第一次执行 vue create 命令后就会被 @vue/cli 创建）</small>。在 Windows 环境中，这个文件在 C:Users<用户名> 目录下，即， %homepath% 目录。 用编辑器打开这个文件，你会发现其内容是一个 JSON 格式数据： 很显然 packageManager 项就是用来设置 @vue/cli 的包管理器的，将它从 npm 改为 yarn 。 修改完成后，使用 vue create xxx 创建 vue 项目，创建过程结束后，你看到的将是： 注意 ，这里的设置对命令行有效，而对 IDEA『 无影响 』 ，因为在 IDEA 里通过 @vue/cli 创建 vue 项目，它们读取的配置文件是 IDEA 自己的配置文件，并不是这里的这个配置文件，是另外单独的配置。 </div>

在理想状态下，我们对yarn的资源请求，应该是立即得到相应，但是实际情况往往资源是有限的，如果集群很繁忙的话，一个应用的资源请求需要等待一段时间才能得到资源。为此yarn提供了三种调度器供我们选择 FIFO Scheduler 把应用按照提交的顺序拍成一个队列，上图是一个先进先出的队列，但是他并不适合共享集群，上图中job1在0点提交任务，资源使用率为100%，那么job2任务在1点提交的任务，只能等job1在5点钟执行完任务后释放资源，job2才开始执行任务，所以小任务会被大任务阻塞 而对于Capacity Scheduler，提前预留一个专门的通道给小任务执行，但是这样会预先占用一些资源，大任务只能利用80%的资源，就导致大任务的运行时间要大于FIFO的大任务的运行时间；如上图，而且小任务前后会造成资源浪费 在Fair Scheduler调度器中，我们不需要预留资源，Fair调度器会动态运行所有job的资源，如上图，一开始0点的时候，job1占用所有集群的资源，当job2提交的时候，Fair调度器会分配一半资源给job2，让job1和job2并行的运行任务 当job2在1点钟提交任务的时候，获取资源会有 一定的延时 ，因为需要job1关闭掉一些container，释放一些资源；小任务完成后，释放自己的资源，然后大任务又获取所有集群的资源 最终Fair调度器提高了资源利用率，又保证了小任务的及时完成 在企业中并不是只有一个人来执行MapReduce程序单独使用Yarn的资源，实际开发中，会有很多人一起使用Yarn这个资源，如果每个人都提交了job，这个时候Yarn就需要进行调度去分配资源给job， 下面三种调度机制，默认的是FIFO机制，这种机制是先进先出队列机制，在企业中基本不会使用，第二种机制Capacity机制是使用最多的，它是开辟出两个队列分给不同的组来执行job，但相同的组还是要按照先进先出的队列机制，第三种机制也常有使用。

yarn [jɑ:n] n. (毛、丝、亚麻、棉、尼龙、玻璃等的)纱、纱线。生产布匹的原材料。sewing thread 缝纫线，缝纫丝。生产服装的辅料

YARN(Yet Another Resource Negotiator，另一种资源协调者)是一个通用的资源管理系统和调度平台，它的基本设计思想是将MRv1(Hadoop1.0中的MapReduce)中的JobTracker拆分为两个独立的任务，这两个任务分别是全局的资源管理器ResourceManager和每个应用程序特有的ApplicationMaster。其中，ResourceManager负责整个系统的资源管理和分配，而ApplicationMaster负责单个应用程序的管理。接下来，我们通过一张图来描述YARN的体系结构，具体如图1所示。 图1 YARN体系结构 在图1中，YARN体系结构的核心组件有三个，具体介绍如下： 1. ResourceManager ResourceManager是一个全局的资源管理系统，它负责的是整个Yarn集群资源的监控、分配和管理工作，具体工作如下： (1) 负责处理客户端请求 (2) 接收和监控NodeManager(NM)的资源情况 (3) 启动和监控ApplicationMaster(AM) (4) 资源的分配和调度 值得一提的是，在ResourceManager内部包含了两个组件，分别是调度器(Scheduler)和应用程序管理器(Application Manager)，其中调度器根据容量、队列等限制条件(如每个队列分配一定的资源，最多执行一定数量的作业等)，将系统中的资源分配给各个正在运行的应用程序。该调度器是一个“纯调度器”，它不再从事任何与具体应用程序相关的工作;而应用程序管理器(Applications Manager)负责管理整个系统中所有的应用程序，包括应用程序的提交、调度协调资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动。 2.NodeManager NodeManager是每个节点上的资源和任务管理器，一方面，它会定时的向ResourceManager汇报所在节点的资源使用情况 ， ;另一方面，它会接收并处理来自ApplicationMaster的启动停止容器(Container)的各种请求。 3.ApplicationMaster 用户提交的每个应用程序都包含一个ApplicationMaster，它负责协调来自ResourceManager的资源，把获得的资源进一步分配给内部的各个任务，从而实现“二次分配”。除此之外，ApplicationMaster还会通过NodeManager监控容器的执行和资源使用情况，并在任务运行失败时重新为任务申请资源以重启任务。当前的YARN自带了两个ApplicationMaster的实现，一个是用于演示ApplicationMaster编写方法的实例程序DistributedShell，它可以申请一定数目的Container以并行方式运行一个Shell命令或者Shell脚本;另一个则是运行MapReduce应用程序的ApplicationMaster-MRAppMaster。 需要注意的是，ResourceManager负责监控ApplicationMaster，并在ApplicationMaster运行失败的时候重启它，大大提高集群的拓展性。ResourceManager不负责ApplicationMaster内部任务的容错，任务的容错由ApplicationMaster完成，总体来说，ApplicationMaster的主要功能是资源的调度、监控与容错。

这段时间抠vue3的源码，在开始时，就碰到了yarn的安装问题 拿到源码：npm install，很好，报错： 接下来安装yarn： 在vscode里面安装yarn的时候，npm install -g yarn 执行成功， 但是在查看版本yarn -version的时候报错，如下： 最后是需要在环境变量里面配置系统变量，地址就是npm install -g yarn的时候返回的路径，我的如下： 下图是其他人一次执行成功的截图圈出来的是环境变量配置地址

1. MapReduce On YARN：YARN天生支持，目前已非常完善（从YARN将要发布2.1.0-beta版可看出，较之前版本，这一块基本没有修改）。2. Tez On YARN：一个DAG计算框架，直接修改自MapReduce，继承了MapReduce的扩展性好和容错性好等优点3. Storm On YARN：实时计算框架Storm运行在YARN上，，项目状态：开发进行中，已发布一个版本。

Yarn是Yet Another Resource Negotiator的缩写。 Yarn的基本思想是将资源管理和作业调度/监视的功能分解为单独的守护进程。它是一个资源调度平台，负责为运行应用程序提供运算资源，相当于一个分布式的操作系统，而MapReduce则相当于运行于操作系统之上的应用程序。 在Yarn中，ResourceManager和NodeManager构成了数据计算框架。ResourceManager是在系统中对所有应用程序之间要使用的资源进行调度。而NodeManager是每台机器/节点的代理，负责容器，监视其资源使用情况（CPU，内存，磁盘，网络）并将其报告给ResourceManager / Scheduler。 每个应用程序ApplicationMaster实际上是一个特定的框架库，其任务是协调来自ResourceManager的资源，并与NodeManager一起执行和监视任务。 Yarn主要由如下几个组件构成： 资源 ResourceManager

翻译： https://www.cloudera.com/documentation/enterprise/latest/topics/admin_ha_yarn_work_preserving_recovery.html 最低要求的角色： Configurator （也由群集管理员 ，完全管理员 最低要求的角色： 配置器 （也由群集管理员，完全管理员 提供） CDH 5.2引入了YARN ResourceManager和NodeManager的 工作保持恢复 。在启用工作保持恢复的情况下，如果ResourceManager或NodeManager重新启动，则不会丢失任何正在进行的工作。您可以分别为ResourceManager或NodeManager配置工作保留恢复。无论您是否使用ResourceManager High Availability，都可以启用工作保留恢复。 注意： YARN不支持JobHistory服务器（JHS）的高可用性。如果JHS发生故障，Cloudera Manager将自动重启。 注意： 将JobHistory服务器移动到新主机后，ResourceManager Web UI上为JobHistory服务器列出的URL仍指向旧JobHistory服务器。这仅影响现有作业。移动后新开始的工作不受影响。对于任何具有不正确的JobHistory服务器URL的现有作业，除了允许作业逐渐推出历史记录之外，没有别的选择。对于新作业，请确保所有客户端都具有引用正确JobHistory服务器的更新的mapred-site.xml。 如果使用Cloudera Manager并启用 YARN（MRv2）ResourceManager高可用性 ，则缺省情况下会为ResourceManager启用保留工作恢复。 要禁用ResourceManager的工作维护恢复，请执行以下操作： 恢复目录的缺省值是 /var/lib/hadoop-yarn/yarn-nm-recovery. 默认情况下，Cloudera Manager会启用工作保留恢复。 如果需要，以下是为给定NodeManager启用工作保留恢复的步骤： 最低要求的角色： 配置器 （也由群集管理员 提供，完全管理员） 重要： 启用 YARN（MRv2）ResourceManager高可用性后 ，在ResourceManager和所有NodeManagers上的yarn-site.xml添加配置元素。 辅助服务的设计应该支持在NodeManager重新启动后重新加载之前的状态。示例辅助服务（用于MapReduce的ShuffleHandler服务）遵循支持保留NodeManager恢复工作的辅助服务的正确模式。 有关更多信息，请参阅 启动，停止和重新启动服务 。 最低要求的角色： 配置器 （也由群集管理员 ，完全管理员提供） 如果您不使用Cloudera Manager，以下示例配置可与Cloudera Manager高级配置片段一起使用，或者直接添加到yarn-site.xml中。调整配置以适应您的环境。

虽然网上和知乎上有好多文章写 npm 和 yarn 的区别。并且我写的文章中借鉴他人的，但还是希望发出来，自己想看的时候，就立马可以找到。引用的文章也会在底部写出来了。 yarn 是由 Facebook、Google、Exponent 和 Tilde 联合推出了一个新的 JS 包管理工具，yarn 是为了弥补 npm 的一些缺陷而出现的。 1. 速度快：（主要来自一下两个方面） 2. 安装版本统一 4. 多注册来源处理 5. 语义化进行了修改 1.查看版本 2.安装淘宝镜像 3.初始化某个项目 4.默认安装项目依赖 5.安装依赖，并且默认保存到 package 6.卸载依赖 7.更新依赖 8.安装全局项目依赖 9.安装特定版本号的项目依赖 10.发布/登录/登出，一系列NPM Registry操作 11.运行命令

yarn是纱线，测的应该是纱线细度，tex，D。thread应该有前缀的吧，sewing thread 缝纫线，缝纫丝你可以发检测报告看看

yarn一般指代的是纺织纱线，作为纺织的原料，经纬纱一类的thread表示的作为线或者针数，它所指代的是成品线，不是大面积的实用在面料上。

yarn 一般指代的是纺织纱线，作为纺织的原料，经纬纱一类的thread 表示的作为线或者针数，它所指代的是成品线，不是大面积的实用在面料上。

YARN允许用户配置每个节点上可用的物理内存资源，注意，这里是“可用的”，因为一个节点上的内存会被若干个服务共享，比如一部分给YARN，一部分给HDFS，一部分给HBase等，YARN配置的只是自己可以使用的，配置参数如下: (1)yarn.nodemanager.resource.memory-mb 表示该节点上YARN可使用的物理内存总量，默认是8192（MB），注意，如果你的节点内存资源不够8GB，则需要调减小这个值，而YARN不会智能的探测节点的物理内存总量。 (2)yarn.scheduler.minimum-allocation-mb 单个容器可申请的最少物理内存量，默认是1024（MB），如果一个容器申请的物理内存量少于该值，则该对应的值改为这个数。 (3) yarn.scheduler.maximum-allocation-mb 单个容器可申请的最多物理内存量，默认是8192（MB） 目前的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个数，默认是8，注意，目前推荐将该值设值为与物理CPU核数数目相同。如果你的节点CPU核数不够8个，则需要调减小这个值，而YARN不会智能的探测节点的物 理CPU总数。 (2)yarn.scheduler.minimum-allocation-vcores 单个容器可申请的最小虚拟CPU个数，默认是1，如果一个容器申请的CPU个数少于该数，则该对应的值改为这个数 (3)yarn.scheduler.maximum-allocation-vcores 单个容器可申请的最多虚拟CPU个数，默认是4 3.mapreduce---Memory调优 (1)yarn.app.mapreduce.am.resource.mb MR AppMaster需要的内存，默认是1536M (2)yarn.app.mapreduce.am.command-opts MR AppMaster的Java opts ，默认是 -Xmx1024m (3)mapreduce.map.memory.mb 每个map task所需要的内存，默认是1024M。应该是大于或者等于Container的最小内存 (4)mapreduce.reduce.memory.mb 每个reduce task所需要的内存，默认是1024M (5)mapreduce.map.java.opts map task进程的java.opts，默认是 -Xmx200m (6)mapreduce.reduce.java.opts reduce task进程的java.opts，默认是 -Xmx200m 特别注意: mapreduce.map.memory.mb >mapreduce.map.java.opts mapreduce.reduce.memory.mb >mapreduce.reduce.java.opts mapreduce.map.java.opts / mapreduce.map.memory.mb =0.70~0.80 mapreduce.reduce.java.opts / mapreduce.reduce.memory.mb =0.70~0.80 在yarn container这种模式下，JVM进程跑在container中，mapreduce.{map|reduce}.java.opts 能够通过Xmx设置JVM最大的heap的使用， 一般设置为0.75倍的memory.mb， 则预留些空间会存储java,scala code等 4.mapreduce---CPU调优 (1)mapreduce.map.cpu.vcores map task的虚拟核数，默认为1 (2)mapreduce.reduce.cpu.vcores reduce task的虚拟核数，默认为1 (3)yarn.app.mapreduce.am.resource.cpu-vcores am的虚拟核数，默认为1 假设机器的物理配置 64G 16cores 装完系统还剩 62G 预留15~20% 14G:DN 4G + NM 1G=5G 9G DN进程: 生产4G 1000m hadoop-env.sh HADOOP_NAMENODE_OPTS=-Xmx1024m HADOOP_DATANODE_OPTS=-Xmx4096m NM进程: 生产1G yarn-env.sh export YARN_RESOURCEMANAGER_HEAPSIZE=1024 export YARN_NODEMANAGER_HEAPSIZE=1024 部署同一台： 数据本地化 NN RM 经常性部署同一台 说白了 集群节点少 yarn.nodemanager.resource.memory-mb : 48G 计算总内存 固定经验计算值 yarn.nodemanager.resource.cpu-vcores : 24 yarn.scheduler.minimum-allocation-mb : 4G yarn.scheduler.minimum-allocation-vcores： 2 yarn.scheduler.maximum-allocation-mb : 8G yarn.scheduler.maximum-allocation-vcores : 4 固定经验值(不要超过5个) http://blog.itpub.net/30089851/viewspace-2127851/ http://blog.itpub.net/30089851/viewspace-2127850/

周一入职，同事JJ让我熟悉一下基于React的新项目。 按照以往，我的步骤都是： 这时，JJ给我来了下面一段 “咦，yarn是什么鬼？难道npm更高级的替代品？为什么要替代npm？难道有什么好的地方？”，内心一连串的问题冒出来。我就默默的问了一下JJ：“yarn是跟npm一样的东西吗？”，“嗯。”JJ忙碌的敲着键盘，显然这个问题不值得继续问下去了。我也默默的把刚才脑子里一连串的问题记了下来。 “Yarn是由Facebook、Google、Exponent 和 Tilde 联合推出了一个新的 JS 包管理工具 ，正如 官方文档 中写的，Yarn 是为了弥补 npm 的一些缺陷而出现的。”这句话让我想起了使用npm时的坑了： “5.0.3”表示安装指定的5.0.3版本，“～5.0.3”表示安装5.0.X中最新的版本，“^5.0.3”表示安装5.X.X中最新的版本。这就麻烦了，常常会出现同一个项目，有的同事是OK的，有的同事会由于安装的版本不一致出现bug。 带着这些坑，我开始了解Yarn的优势及其解决的问题。 有了yarn的压力之后，npm做了一些类似的改进。 在npm5.0之前，yarn的优势特别明显。但是在npm之后，通过以上一系列对比，我们可以看到 npm5 在速度和使用上确实有了很大提升，值得尝试，不过还没有超过yarn。 综上我个人的建议是如果你已经在个人项目上使用 yarn，并且没有遇到更多问题，目前完全可以继续使用。但如果有兼容 npm 的场景，或者身处在使用 npm，cnpm，tnpm 的团队，以及还没有切到 yarn 的项目，那现在就可以试一试 npm5 了。 simbawu | github | segmentfault | 知乎 | | 掘金

Apache Hadoop YARN （Yet Another Resource Negotiator，另一种资源协调者）是一种新的 Hadoop 资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处 mapreduce1.0回顾 1. client 负责把作业提交到集群 2. ResourceManager 负责集群资源的统一管理和调度，承担了 JobTracker 的角色，整个集群只有“一个”，总的来说，RM有以下作用： 3. NodeManager 管理YARN集群中的每个节点。整个集群可以有多个。负责单个节点上资源的管理和使用（具体点说是负责计算节点上container的启动、监控和管理，防止Application Master使用多于它申请到的计算资源）。NM有以下作用 4. ApplicationMaster 每个应用有一个，负责应用程序整个生命周期的管理 。 ApplicationMaster 负责协调来自 ResourceManager 的资源，并通过 NodeManager 监视容器的执行和资源使用（CPU、内存等的资源分配）。请注意，尽管目前的资源比较传统（CPU 核心、内存），但未来会带来支持的新资源类型（比如图形处理单元或专用处理设备）。AM有以下作用： 5. Container 是 YARN 中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的。YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。Container有以下作用： 剖析MapReduce作业运行机制 1、作业的提交 2、作业的初始化 3、任务的分配 4、任务的执行 5、进度和状态的更新 6、作业的完成 简单版工作流程 详细版工作流程 步骤1：用户向YARN中提交应用程序，其中包括ApplicationMaster程序、启动ApplicationMaster、用户程序等。 步骤2：ResourceManager为该应用程序分配第一个Container，并与对应的NodeManager通信，要求它在这个Container中启动应用程序的ApplicationMaster。 步骤3：ApplicationMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManager查看应用程序的运行状态，然后它将为各个任务申请资源，并监控他的运行状态，直到运行结束，即要重复步骤4-7。 步骤4：ApplicationMaster采用轮询的方式通过RPC协议找ResourceManager申请和领取资源。 步骤5：一旦Application申请到资源后，便与对应的NodeManager通信，要求启动任务。 步骤6：NodeManager为任务设置好运行环境，包括环境变量、JAR包、二进制程序等，然后将任务启动命令写到另一个脚本中，并通过运行该脚本启动任务。 步骤7：各个任务通过RPC协议向ApplicationMaster汇报自己的状态和进度，ApplicationMaster随时掌握各个任务的运行状态，从而可以再任务失败时重新启动任务。在应用程序运行过程中，用户可以随时通过RPC协议ApplicationMaster查询应用程序的当前运行状态。 步骤8：应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭自己。 1.YARN的HA 2.hdfs的HA Namenode和resourcemanager的HA两点最大的不同： 1.ZKFC是作为ResourceManager之中的一个进程，而Hadoop中则是一个外置的守护进程 hadoop1.0到hadoop2.0的变迁 MapReduce对任务执行的更多控制（暂时不明白） 1.调度器基本作用 根据节点资源（slot、container）使用情况和作业的要求，将任务调度到各个节点上执行 2.作业调度器考虑的因素 1、作业优先级。作业的优先级越高，它能够获取的资源（slot数目)也越多。Hadoop 提供了5种作业优先级，分别为 VERY_HIGH、HIGH、NORMAL、 LOW、VERY_LOW，通过mapreduce.job.priority属性来设置，或者用JobClient的setJobPriority()方法来设置。 2、作业提交时间。顾名思义，作业提交的时间越早，就越先执行。 3、作业所在队列的资源限制。调度器可以分为多个队列，不同的产品线放到不同的队列里运行。不同的队列可以设置一个边缘限制，这样不同的队列有自己独立的资源，不会出现抢占和滥用资源的情况 3.Hadoop的自带作业调度器 4.如何配置使用调度器？ 将其JAR文件放到Hadoop的类路（classpath） 然后设置mapred.jobtracker.taskScheduler属性（yarn.resourcemanager.scheduler.class）值为org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler Application Master决定如何运行构成MapReduce作业的各个任务。如果作业很小，就选择在与它同一个JVM上运行任务 什么样的作业称为小作业（又叫Uber任务或小任务）？ 默认情况下，小作业指小于10个mapper且只有一个reducer且输入大小小于HDFS块的任务。 涉及属性配置如下：

　　YARN的编程模型　　1：保证编程模型的向下兼容性，MRv2重用了MRv1的编程模型和数据处理引擎，但运行环境被重写。　　2：编程模型与数据处理引擎　　mapreduce应用程序编程接口有两套：新的API（mapred）和旧的API（mapreduce）　　采用MRv1旧的API编写的程序可直接运行在MRv2上　　采用MRv1新的API编写的程序需要使用MRv2编程库重新编译并修改不兼容的参数 和返回值　　3：运行时环境　　MRv1:Jobracker和Tasktracker　　MRv2:YARN和ApplicationMaster　　YARN的组成　　yarn主要由ResourceManager，NodeManager，ApplicationMaster和Container等几个组件组成。　　ResourceManager（RM）　　RM是全局资源管理器，负责整个系统的资源管理和分配。　　主要由两个组件组成：调度器和应用 程序管理器（ASM）　　调度器　　调度器根据容量，队列等限制条件，将系统中的资源分配给各个正在运行的应用程序　　不负责具体应用程序的相关工作，比如监控或跟踪状态　　不负责重新启动失败任务　　资源分配单位用“资源容器”resource Container表示　　Container是一个动态资源分配单位，它将内存，CPU,磁盘，网络等资源封装在一起，从而限定每个任务的资源量　　调度器是一个可插拔的组件，用户可以自行设计　　YARN提供了多种直接可用的调度器，比如fair Scheduler和Capacity Scheduler等。　　应用程序管理器　　负责管理整个系统中所有应用程序　　ApplicationMaster（AM）　　用户提交的每个应用程序均包含一个AM　　AM的主要功能　　与RM调度器协商以获取资源（用Container表示）　　将得到的任务进一步分配给内部的任务　　与NM通信以自动/停止任务　　监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务　　当前YARN自带了两个AM实现　　一个用于演示AM编写方法的实例程序distributedshell　　一个用于Mapreduce程序---MRAppMaster　　其他的计算框架对应的AM正在开发中，比如spark等。　　Nodemanager（NM）和Container　　NM是每个节点上的资源和任务管理器　　定时向RM汇报本节点上的资源使用情况和各个Container的运行状态　　接收并处理来自AM的Container启动/停止等各种要求　　Container是YARN中的资源抽象，它封装了某个节点上的多维度资源　　YARN会为每个任务分配一个Container，且改任务只能使用该Container中描述的资源　　Container不同于MRv1的slot，它是一个动态资源划分单位，是根据应用程序的需求动态产生的　　YARN主要由以下几个协议组成　　ApplicationClientProtocol　　Jobclient通过该RPC协议提交应用才程序，查询应用程序状态等　　ResourceManagerAdministrationProtocol　　Admin通过该协议更新系统配置文件，比如节点黑名单，用户队列权限等。　　ApplicationMasterProtocol　　AM通过该RPC协议想RM注册和撤销自己，并为各个任务申请资源　　ContainerManagementProtocol　　AM通过要求NM启动或者停止Container，获取各个Container的使用状态等信息　　ResourceTracker　　NM通过该RPC协议向RM注册，并定时发送心跳信息汇报当前节点的资源使用情况和Container运行状况　　YARN的工作流程　　文字描述一下这个过程：　　1：由客户端提交一个应用，由RM的ASM接受应用请求　　提交过来的应用程序包括哪些内容：　　a:ApplicationMaster　　b:启动Applicationmaster的命令　　c:本身应用程序的内容　　2:提交了三部分内容给RM，然后RM找NodeManager,然后　　Nodemanager就启用Applicationmaster，并分配Container　　接下来我们就要执行这个任务了，　　3:但是执行任务需要资源，所以我们得向RM的ASM申请执行任务的资源（它会在RM这儿注册一下，说我已经启动了，注册了以后就可以通过RM的来管理，我们用户也可以通过RM的web客户端来监控任务的状态）ASM只是负责APplicati

本文介绍YARN自带的一个非常简单的应用程序实例—distributedshell的使用方法。它可以看做YARN编程中的“hello world”，主要功能是并行执行用户提供的shell命令或者shell脚本。（1）运行参数介绍DistributedShell的基本运行参数如下：（2）运行方法DistributedShell的运行方法如下：在YARN安装目录下，执行以下命令：bin/hadoop jarshare/hadoop/yarn/hadoop-yarn-applications-distributedshell-2.0.0-cdh4.1.1.jarorg.apache.hadoop.yarn.applications.distributedshell.Client–jar share/hadoop/yarn/hadoop-yarn-applications-distributedshell-2.0.0-cdh4.1.1.jar–shell_command ls–shell_script ignore.sh–num_containers 10–container_memory 350–master_memory 350–priority 10需要注意的是，在hadoop-2.0.3-alpha（不包括该版本）和CDH 4.1.2版本（包括该版本）之前，DistributedShell存在BUG，具体如下：1） 必须使用–shell_command参数2） 当只有shell_command参数而没有shell_script参数时，在分布式模式下（伪分布式下可以）不能执行成功，具体说明和修复方法见： https://issues.apache.org/jira/browse/YARN-253在这个实例中，ignore.sh中的内容就是“ls”3） 内存设置一定要正确，不然会出现以下提示的错误：Container [pid=4424,containerID=container_1359629844156_0004_01_000001] is running beyond virtual memory limits. Current usage: 90.1mb of 128.0mb physical memory used; 593.0mb of 268.8mb virtual memory used. Killing container.【附】DistributedShell运行日志：13/02/01 13:43:11 INFO distributedshell.Client: Initializing Client 13/02/01 13:43:11 INFO distributedshell.Client: Starting Client 13/02/01 13:43:11 INFO distributedshell.Client: Connecting to ResourceManager at c2-23/10.1.1.98:8032 13/02/01 13:43:12 INFO distributedshell.Client: Got Cluster metric info from ASM, numNodeManagers=3 13/02/01 13:43:12 INFO distributedshell.Client: Got Cluster node info from ASM 13/02/01 13:43:12 INFO distributedshell.Client: Got node report from ASM for, nodeId=c2-23:36594, nodeAddressc2-23:8042, nodeRackName/default-rack, nodeNumContainers0, nodeHealthStatusis_node_healthy: true, health_report: “”, last_health_report_time: 1359697377337, 13/02/01 13:43:12 INFO distributedshell.Client: Got node report from ASM for, nodeId=c2-25:41070, nodeAddressc2-25:8042, nodeRackName/default-rack, nodeNumContainers0, nodeHealthStatusis_node_healthy: true, health_report: “”, last_health_report_time: 1359697367180, 13/02/01 13:43:12 INFO distributedshell.Client: Got node report from ASM for, nodeId=c2-24:48383, nodeAddressc2-24:8042, nodeRackName/default-rack, nodeNumContainers0, nodeHealthStatusis_node_healthy: true, health_report: “”, last_health_report_time: 1359699033102, 13/02/01 13:43:12 INFO distributedshell.Client: Queue info, queueName=default, queueCurrentCapacity=0.0, queueMaxCapacity=1.0, queueApplicationCount=0, queueChildQueueCount=0 13/02/01 13:43:12 INFO distributedshell.Client: User ACL Info for Queue, queueName=default, userAcl=SUBMIT_APPLICATIONS 13/02/01 13:43:12 INFO distributedshell.Client: User ACL Info for Queue, queueName=default, userAcl=ADMINISTER_QUEUE 13/02/01 13:43:12 INFO distributedshell.Client: Got new application id=application_1359695803957_0003 13/02/01 13:43:12 INFO distributedshell.Client: Min mem capabililty of resources in this cluster 128 13/02/01 13:43:12 INFO distributedshell.Client: Max mem capabililty of resources in this cluster 10240 13/02/01 13:43:12 INFO distributedshell.Client: Setting up application submission context for ASM 13/02/01 13:43:12 INFO distributedshell.Client: Copy App Master jar from local filesystem and add to local environment 13/02/01 13:43:13 INFO distributedshell.Client: Set the environment for the application master 13/02/01 13:43:13 INFO distributedshell.Client: Trying to generate classpath for app master from current thread"s classpath 13/02/01 13:43:13 INFO distributedshell.Client: Readable bytes from stream=9006 13/02/01 13:43:13 INFO distributedshell.Client: Setting up app master command 13/02/01 13:43:13 INFO distributedshell.Client: Completed setting up app master command ${JAVA_HOME}/bin/java -Xmx350m org.apache.hadoop.yarn.applications.distributedshell.ApplicationMaster –container_memory 350 –num_containers 10 –priority 0 –shell_command ls 1>/AppMaster.stdout 2>/AppMaster.stderr 13/02/01 13:43:13 INFO distributedshell.Client: Submitting application to ASM 13/02/01 13:43:14 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=N/A, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=ACCEPTED, distributedFinalState=UNDEFINED, appTrackingUrl=c2-23:8088/proxy/application_1359695803957_0003/, appUser=rmss 13/02/01 13:43:15 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=RUNNING, distributedFinalState=UNDEFINED, appTrackingUrl=, appUser=rmss 13/02/01 13:43:16 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=RUNNING, distributedFinalState=UNDEFINED, appTrackingUrl=, appUser=rmss 13/02/01 13:43:17 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=RUNNING, distributedFinalState=UNDEFINED, appTrackingUrl=, appUser=rmss 13/02/01 13:43:18 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=RUNNING, distributedFinalState=UNDEFINED, appTrackingUrl=, appUser=rmss 13/02/01 13:43:19 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=FINISHED, distributedFinalState=SUCCEEDED, appTrackingUrl=, appUser=rmss 13/02/01 13:43:19 INFO distributedshell.Client: Application has completed successfully. Breaking monitoring loop 13/02/01 13:43:19 INFO distributedshell.Client: Application completed successfullyz转载仅供参考，版权属于原作者。祝你愉快，满意请采纳哦

您好，很高兴能帮助您，本文介绍YARN自带的一个非常简单的应用程序实例—distributedshell的使用方法。它可以看做YARN编程中的“hello world”，主要功能是并行执行用户提供的shell命令或者shell脚本。（1）运行参数介绍DistributedShell的基本运行参数如下：（2）运行方法DistributedShell的运行方法如下：在YARN安装目录下，执行以下命令：bin/hadoop jarshare/hadoop/yarn/hadoop-yarn-applications-distributedshell-2.0.0-cdh4.1.1.jarorg.apache.hadoop.yarn.applications.distributedshell.Client–jar share/hadoop/yarn/hadoop-yarn-applications-distributedshell-2.0.0-cdh4.1.1.jar–shell_command ls–shell_script ignore.sh–num_containers 10–container_memory 350–master_memory 350–priority 10需要注意的是，在hadoop-2.0.3-alpha（不包括该版本）和CDH 4.1.2版本（包括该版本）之前，DistributedShell存在BUG，具体如下：1） 必须使用–shell_command参数2） 当只有shell_command参数而没有shell_script参数时，在分布式模式下（伪分布式下可以）不能执行成功，具体说明和修复方法见： https //issues apache org/jira/browse/YARN-253在这个实例中，ignore.sh中的内容就是“ls”3） 内存设置一定要正确，不然会出现以下提示的错误：Container [pid=4424,containerID=container_1359629844156_0004_01_000001] is running beyond virtual memory limits. Current usage: 90.1mb of 128.0mb physical memory used; 593.0mb of 268.8mb virtual memory used. Killing container.【附】DistributedShell运行日志：13/02/01 13:43:11 INFO distributedshell.Client: Initializing Client 13/02/01 13:43:11 INFO distributedshell.Client: Starting Client 13/02/01 13:43:11 INFO distributedshell.Client: Connecting to ResourceManager at c2-23/10.1.1.98:8032 13/02/01 13:43:12 INFO distributedshell.Client: Got Cluster metric info from ASM, numNodeManagers=3 13/02/01 13:43:12 INFO distributedshell.Client: Got Cluster node info from ASM 13/02/01 13:43:12 INFO distributedshell.Client: Got node report from ASM for, nodeId=c2-23:36594, nodeAddressc2-23:8042, nodeRackName/default-rack, nodeNumContainers0, nodeHealthStatusis_node_healthy: true, health_report: “”, last_health_report_time: 1359697377337, 13/02/01 13:43:12 INFO distributedshell.Client: Got node report from ASM for, nodeId=c2-25:41070, nodeAddressc2-25:8042, nodeRackName/default-rack, nodeNumContainers0, nodeHealthStatusis_node_healthy: true, health_report: “”, last_health_report_time: 1359697367180, 13/02/01 13:43:12 INFO distributedshell.Client: Got node report from ASM for, nodeId=c2-24:48383, nodeAddressc2-24:8042, nodeRackName/default-rack, nodeNumContainers0, nodeHealthStatusis_node_healthy: true, health_report: “”, last_health_report_time: 1359699033102, 13/02/01 13:43:12 INFO distributedshell.Client: Queue info, queueName=default, queueCurrentCapacity=0.0, queueMaxCapacity=1.0, queueApplicationCount=0, queueChildQueueCount=0 13/02/01 13:43:12 INFO distributedshell.Client: User ACL Info for Queue, queueName=default, userAcl=SUBMIT_APPLICATIONS 13/02/01 13:43:12 INFO distributedshell.Client: User ACL Info for Queue, queueName=default, userAcl=ADMINISTER_QUEUE 13/02/01 13:43:12 INFO distributedshell.Client: Got new application id=application_1359695803957_0003 13/02/01 13:43:12 INFO distributedshell.Client: Min mem capabililty of resources in this cluster 128 13/02/01 13:43:12 INFO distributedshell.Client: Max mem capabililty of resources in this cluster 10240 13/02/01 13:43:12 INFO distributedshell.Client: Setting up application submission context for ASM 13/02/01 13:43:12 INFO distributedshell.Client: Copy App Master jar from local filesystem and add to local environment 13/02/01 13:43:13 INFO distributedshell.Client: Set the environment for the application master 13/02/01 13:43:13 INFO distributedshell.Client: Trying to generate classpath for app master from current thread"s classpath 13/02/01 13:43:13 INFO distributedshell.Client: Readable bytes from stream=9006 13/02/01 13:43:13 INFO distributedshell.Client: Setting up app master command 13/02/01 13:43:13 INFO distributedshell.Client: Completed setting up app master command ${JAVA_HOME}/bin/java -Xmx350m org.apache.hadoop.yarn.applications.distributedshell.ApplicationMaster –container_memory 350 –num_containers 10 –priority 0 –shell_command ls 1>/AppMaster.stdout 2>/AppMaster.stderr 13/02/01 13:43:13 INFO distributedshell.Client: Submitting application to ASM 13/02/01 13:43:14 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=N/A, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=ACCEPTED, distributedFinalState=UNDEFINED, appTrackingUrl=c2-23:8088/proxy/application_1359695803957_0003/, appUser=rmss 13/02/01 13:43:15 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=RUNNING, distributedFinalState=UNDEFINED, appTrackingUrl=, appUser=rmss 13/02/01 13:43:16 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=RUNNING, distributedFinalState=UNDEFINED, appTrackingUrl=, appUser=rmss 13/02/01 13:43:17 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=RUNNING, distributedFinalState=UNDEFINED, appTrackingUrl=, appUser=rmss 13/02/01 13:43:18 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=RUNNING, distributedFinalState=UNDEFINED, appTrackingUrl=, appUser=rmss 13/02/01 13:43:19 INFO distributedshell.Client: Got application report from ASM for, appId=3, clientToken=null, appDiagnostics=, appMasterHost=, appQueue=default, appMasterRpcPort=0, appStartTime=1359697393467, yarnAppState=FINISHED, distributedFinalState=SUCCEEDED, appTrackingUrl=, appUser=rmss 13/02/01 13:43:19 INFO distributedshell.Client: Application has completed successfully. Breaking monitoring loop 13/02/01 13:43:19 INFO distributedshell.Client: Application completed successfully你的采纳是我前进的动力，还有不懂的地方，请你继续“追问”！如你还有别的问题，可另外向我求助；答题不易，互相理解，互相帮助！

Yarn的优点有（）。 A.大大减少Hadoop集群中的资源消耗B.分布式监控每一个子任务的程序C.用户可编写模型正确答案：ABC

在Yarn中，负责给应用分配资源的是Scheduler，并提供了多种调度器和可配置的策略供选择。 在Yarn中有是三种调度器可以选择：FIFO Scheduler，Capacity Scheduler，Fair Scheduler。 FIFO Scheduler把应用按提交的顺序排成一个队列，这是一个先进先出队列，在进行资源分配的时候，先给队列中最头上的应用分配资源，待最头上的应用需求满足后再给下一个分配，以此类推。 FIFO Scheduler是最简单也是最容易理解的调度器，不需要任何配置，但其不适用于共享集群。大的应用可能会占用所有集群资源，这就导致其它应用被阻塞。在共享集群中，更适合采用Capacity Scheduler或Fair Scheduler，这两种调度器都允许大任务和小任务在提交的同时获得一定的资源。 下面 Yarn调度器对比图 展示了这几个调度器的区别，从图中可以看出，在FIFO调度器中，小任务会被大任务阻塞。 而对于Capacity调度器，有一个专门的队列用来运行小任务，但是为小任务专门设置一个队列会占用一定的集群资源，这就导致大任务的执行时间会落后于使用FIFO调度器时的时间。 在Fair调度器中，我们不需要预先占用一定的系统资源，Fair调度器会为所有运行的job动态的调整系统资源。如下图所示，当第一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。 需要注意的是，在下图Fair调度器中，从第二个任务提交到获得资源会有一定的延迟，因为它需要等待第一个任务释放占用的Container。小任务执行完成以后也会释放自己占用的资源，大任务又获得了全部的系统资源。最终的效果就是Fair调度器既得到了高资源的利用率又能保证小任务的及时执行。 Capacity 调度器允许多个组织共享整个集群，每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列，然后再为每个队列分配一定的集群资源，这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。除此之外，队列内部又可以垂直划分，这样一个组织内部的多个成员就可以共享这个队列资源了，在一个队列内部，资源的调度是采用的是先进先出(FIFO)策略。 通过上面那幅图，我们已经知道一个job可能使用不了整个队列的资源。然而如果这个队列中运行多个job，如果这个队列的资源够用，那么就分配给这些job，如果这个队列的资源不够用了呢？其实Capacity调度器仍可能分配额外的资源给这个队列，这就是“弹性队列”(queue elasticity)的概念。 在正常的操作中，Capacity调度器不会强制释放Container，当一个队列资源不够用时，这个队列只能获得其它队列释放后的Container资源。当然，我们可以为队列设置一个最大资源使用量，以免这个队列过多的占用空闲资源，导致其它队列无法使用这些空闲资源，这就是”弹性队列”需要权衡的地方。 该调度器预定义了一个root队列，所有队里都是该队列的子队列。 在配置root下面的子队列时使用逗号隔开，同时在定义层级队列时使用叫做 queue path 来表明，如 yarn.scheduler.capacity.root.a.queues 。各个子队列都可以使用百分比来表示占用父队列资源的比例，如未配置，则表示可以占用到父队列资源的全部资源。同时还可以配置一个用户可以分配的最大资源数、可以同时运行多少个应用等。 调度器中的配置修改后可以使用admin进行动态刷新。 Fair调度器的设计目标是为所有的应用分配公平的资源（对公平的定义可以通过参数来设置），用户在各自队列运行中逐渐资源变得平分。 Fair调度器的配置文件位于类路径下的fair-scheduler.xml文件中，这个路径可以通过yarn.scheduler.fair.allocation.file属性进行修改。若没有这个配置文件，Fair调度器采用的分配策略，调度器会在用户提交第一个应用时为其自动创建一个队列，队列的名字就是用户名，所有的应用都会被分配到相应的用户队列中。 我们可以在配置文件中配置每一个队列，并且可以像Capacity 调度器一样分层次配置队列。比如，参考capacity-scheduler.xml来配置fair-scheduler： 队列的层次是通过嵌套<queue>元素实现的。所有的队列都是root队列的孩子，即使我们没有配到<root>元素里。在这个配置中，我们把dev队列有分成了eng和science两个队列。 Fair调度器中的队列有一个权重属性（这个权重就是对公平的定义），并把这个属性作为公平调度的依据。在这个例子中，当调度器分配集群40:60资源给prod和dev时便视作公平，eng和science队列没有定义权重，则会被平均分配。这里的权重并不是百分比，我们把上面的40和60分别替换成2和3，效果也是一样的。注意，对于在没有配置文件时按用户自动创建的队列，它们仍有权重并且权重值为1。 每个队列内部仍可以有不同的调度策略。队列的默认调度策略可以通过顶级元素<defaultQueueSchedulingPolicy>进行配置，如果没有配置，默认采用公平调度。 尽管是Fair调度器，其仍支持在队列级别进行FIFO调度。每个队列的调度策略可以被其内部的<schedulingPolicy> 元素覆盖，在上面这个例子中，prod队列就被指定采用FIFO进行调度，所以，对于提交到prod队列的任务就可以按照FIFO规则顺序的执行了。需要注意，prod和dev之间的调度仍然是公平调度，同样eng和science也是公平调度。 同时Fair调度器采用了一套基于规则的系统来确定应用应该放到哪个队列。在上面的例子中，<queuePlacementPolicy> 元素定义了一个规则列表，其中的每个规则会被逐个尝试直到匹配成功。例如，上例第一个规则specified，则会把应用放到它指定的队列中，若这个应用没有指定队列名或队列名不存在，则说明不匹配这个规则，然后尝试下一个规则。primaryGroup规则会尝试把应用放在以用户所在的Unix组名命名的队列中，如果没有这个队列，不创建队列转而尝试下一个规则。当前面所有规则不满足时，则触发default规则，把应用放在dev.eng队列中。 上面规则可以归结成一句话，除非队列被准确的定义，否则会以用户名为队列名创建队列，还有一个简单的配置策略可以使得所有的应用放入同一个队列（default），这样就可以让所有应用之间平等共享集群而不是在用户之间。直接设置yarn.scheduler.fair.user-as-default-queue=false，这样应用便会被放入default 队列，而不是各个用户名队列。另外，我们还可以设置yarn.scheduler.fair.allow-undeclared-pools=false，这样用户就无法创建队列了。 尽管上面的配置中没有展示，每个队列仍可配置最大、最小资源占用数和最大可运行的应用的数量。如下： 当一个job提交到一个繁忙集群中的空队列时，job并不会马上执行，而是阻塞直到正在运行的job释放系统资源。为了使提交job的执行时间更具预测性（可以设置等待的超时时间），Fair调度器支持抢占。 抢占就是允许调度器杀掉占用超过其应占份额资源队列的containers，这些containers资源便可被分配到应该享有这些份额资源的队列中。需要注意抢占会降低集群的执行效率，因为被终止的containers需要被重新执行。 可以通过设置一个全局的参数yarn.scheduler.fair.preemption=true来启用抢占功能。此外，还有两个参数用来控制抢占的过期时间（这两个参数默认没有配置，需要至少配置一个来允许抢占Container）： 如果队列在minimum share preemption timeout指定的时间内未获得最小的资源保障，调度器就会抢占containers。我们可以通过配置文件中的顶级元素<defaultMinSharePreemptionTimeout>为所有队列配置这个超时时间；我们还可以在<queue>元素内配置<minSharePreemptionTimeout>元素来为某个队列指定超时时间。 与之类似，如果队列在fair share preemption timeout指定时间内未获得平等的资源的一半（这个比例可以配置），调度器则会进行抢占containers。这个超时时间可以通过顶级元素 <defaultFairSharePreemptionTimeout> 和元素级元素 <fairSharePreemptionTimeout> 分别配置所有队列和某个队列的超时时间。上面提到的比例可以通过 <defaultFairSharePreemptionThreshold> (配置所有队列)和 <fairSharePreemptionThreshold> (配置某个队列)进行配置，默认是0.5。

MapReduce v2最基本的设计思想是将JobTracker的两个主要功能，即资源管理和作业调度及监控拆分为两个独立的进程。在该解决方案中包含两个组件：全局的Resource Manager和与每个应用相关的Application Master，ResourceManager和NodeManager（NM，每个节点一个）共同组成整个数据计算框架。 RM负责整个集群的资源管理和分配，是一个全局的资源调度系统。这里是纯调度工作，不再负责监控或者跟踪应用的执行状态，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务，这些工作都交由AM执行。 NM是每个节点上的资源和任务管理器，定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态；同时，它还接收并处理来自AM的Container启动/停止等各种请求。 用户提交的每个应用程序均包含1个AM，主要功能包括： Container是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的。YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。会把程序的jar包也拷贝到容器内存中。 Yarn工作流程 yarn的工作流程如下图所示： Yarn集群默认自带，不需要任何配置，并不适用于共享集群（多租户场景），耗时长的任务会导致后提交的任务一直处于等待状态，如果这个集群是多用户共享的，显然不合适。 [图片上传失败...(image-3635e5-1595569808205)] Capacity Schedule调度器以队列为单位划分资源。一个个队列有独立的资源，队列的结构和资源是可以进行配置的，如下图： default队列占30%资源，analyst和dev分别占40%和30%资源；类似的，analyst和dev各有两个子队列，子队列在父队列的基础上再分配资源。队列以分层方式组织资源，设计了多层级别的资源限制条件以更好的让多用户共享一个Hadoop集群，比如队列资源限制、用户资源限制、用户应用程序数目限制。队列里的应用以FIFO方式调度，每个队列可设定一定比例的资源最低保证和使用上限，同时，每个用户也可以设定一定的资源使用上限以防止资源滥用。而当一个队列的资源有剩余时，可暂时将剩余资源共享给其他队列。 在ResourceManager中配置它要使用的调度器，配置方式是修改conf/yarn-site.xml，设置属性： 调度器的核心就是队列的分配和使用了，修改conf/capacity-scheduler.xml可以配置队列。 Capacity调度器默认有一个预定义的队列——root,所有的队列都是它的子队列。队列的分配支持层次化的配置，使用.来进行分割，比如yarn.scheduler.capacity.<queue-path>.queues 下面是配置的样例，比如root下面有三个子队列: 它是队列的资源容量占比(百分比)。系统繁忙时，每个队列都应该得到设置的量的资源；当系统空闲时，该队列的资源则可以被其他的队列使用。同一层的所有队列加起来必须是100%。 队列资源的使用上限。由于系统空闲时，队列可以使用其他的空闲资源，因此最多使用的资源量则是该参数控制。默认是-1，即禁用。 每个任务占用的最少资源。比如，你设置成了25%。那么如果有两个用户提交任务，那么每个任务资源不超过50%。如果3个用户提交任务，那么每个任务资源不超过33%。如果4个用户提交任务，那么每个任务资源不超过25%。如果5个用户提交任务，那么第五个用户需要等待才能提交。默认是100，即不去做限制。 每个用户最多使用的队列资源占比，如果设置为50.那么每个用户使用的资源最多就是50%。 Fair调度器的设计目标是为所有的应用分配公平的资源（对公平的定义可以通过参数来设置）。公平调度也可以在多个用户间工作。举个例子，假设有两个用户A和B，他们分别拥有一个队列。当A启动一个job而B没有任务时，A会获得全部集群资源；当B启动一个job后，A的job会继续运行，不过一会儿之后两个任务会各自获得一半的集群资源。如果此时B再启动第二个job并且其它job还在运行，则它将会和B的第一个job共享B这个队列的资源，也就是B的两个job会用于四分之一的集群资源，而A的job仍然用于集群一半的资源，结果就是资源最终在两个用户之间平等的共享。 Fair调度器的配置文件位于类路径下的fair-scheduler.xml文件中，这个路径可以通过yarn.scheduler.fair.allocation.file属性进行修改。我们可以在配置文件中配置每一个队列，并且可以像Capacity调度器一样分层次配置队列。比如，参考capacity-scheduler.xml来配置fair-scheduler：

一、npm方式安装yarn，前提是先安装nodejs，并确定npm node命令全局可以用 二、安装yarn 三、建立软连接 将yarn命令软链接到全局

Mesos和YARN之间的主要区别围绕着优先级的设计以及调度任务的方式。Mesos于2007年诞生于UC Berkeley并在Twitter和Airbnb等公司的商用下不断被巩固，它的设计初衷是作为整个数据中心的一个可拓展的全局资源管理器。YARN出于管理Hadoop规模的需求。在YARN出现之前，资源管理（功能）集成在Hadoop MapReduce V1架构中，为了有助于MapReduce的扩展而将其移除（转移到YARN中实现）。MapReduce的Job Tracker并不能在超过上千台的机器中有效调度MapReduce任务。YARN在下一代Hadoop生命周期中被创造，主要围绕着资源拓展。 Mesos：Mesos让framework决定mesos提供的资源是否合适，从而接受或者拒绝这个资源，当framework长期拒绝资源，mesos将跳过该framework，将资源提供给其他framework（mesos本身并不知道各个应用程序资源需求） Yarn：对于yarn来说，决定权在于yarn本身，这对于各种各样的应用程序来说或许就是个错误的决定 从scaling的角度来说，mesos更scalable（Yarn是应用程序的App Mst会把各个任务的资源要求汇报给Yarn，Yarn根据需求为应用程序分配资源） 在Mesos中，各种计算框架是完全融入Mesos中的，也就是说，如果你想在Mesos中添加一个新的计算框架，首先需要在Mesos中部署一套该框架；而在YARN中，各种框架作为client端的library使用，仅仅是你编写的程序的一个库，不需要事先部署一套该框架。从这点上说，YARN运行和使用起来更加方便。 （1）Mesos论文： Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center . B. Hindman, A. Konwinski, M. Zaharia, A. Ghodsi, A.D. Joseph, R. Katz, S. Shenker and I. Stoica, NSDI 2011, March 2011. （2）董的博客： 统一资源管理与调度平台（系统）介绍 （3） Mesos和YARN的区别以及它们如何协同工作

　　（1） Hadoop 1.0　　第一代Hadoop，由分布式存储系统HDFS和分布式计算框架MapReduce组成，其中，HDFS由一个NameNode和多个DataNode组成，MapReduce由一个JobTracker和多个TaskTracker组成，对应Hadoop版本为Hadoop 1.x和0.21.X，0.22.x。　　（2） Hadoop 2.0　　第二代Hadoop，为克服Hadoop 1.0中HDFS和MapReduce存在的各种问题而提出的。针对Hadoop 1.0中的单NameNode制约HDFS的扩展性问题，提出了HDFS Federation，它让多个NameNode分管不同的目录进而实现访问隔离和横向扩展；针对Hadoop 1.0中的MapReduce在扩展性和多框架支持方面的不足，提出了全新的资源管理框架YARN(Yet Another Resource Negotiator)，它将JobTracker中的资源管理和作业控制功能分开，分别由组件ResourceManager和ApplicationMaster实现，其中，ResourceManager负责所有应用程序的资源分配，而ApplicationMaster仅负责管理一个应用程序。对应Hadoop版本为Hadoop 0.23.x和2.x。　　（3） MapReduce 1.0或者MRv1（MapReduceversion 1）　　第一代MapReduce计算框架，它由两部分组成：编程模型（programming model）和运行时环境（runtime environment）。它的基本编程模型是将问题抽象成Map和Reduce两个阶段，其中Map阶段将输入数据解析成key/value，迭代调用map()函数处理后，再以key/value的形式输出到本地目录，而Reduce阶段则将key相同的value进行规约处理，并将最终结果写到HDFS上。它的运行时环境由两类服务组成：JobTracker和TaskTracker，其中，JobTracker负责资源管理和所有作业的控制，而TaskTracker负责接收来自JobTracker的命令并执行它。　　（4）MapReduce 2.0或者MRv2（MapReduce version 2）或者NextGen MapReduc　　MapReduce 2.0或者MRv2具有与MRv1相同的编程模型，唯一不同的是运行时环境。MRv2是在MRv1基础上经加工之后，运行于资源管理框架YARN之上的MRv1，它不再由JobTracker和TaskTracker组成，而是变为一个作业控制进程ApplicationMaster，且ApplicationMaster仅负责一个作业的管理，至于资源的管理，则由YARN完成。　　简而言之，MRv1是一个独立的离线计算框架，而MRv2则是运行于YARN之上的MRv1。　　（5）Hadoop-MapReduce（一个离线计算框架）　　Hadoop是google分布式计算框架MapReduce与分布式存储系统GFS的开源实现，由分布式计算框架MapReduce和分布式存储系统HDFS（Hadoop Distributed File System）组成，具有高容错性，高扩展性和编程接口简单等特点，现已被大部分互联网公司采用。　　（6）Hadoop-YARN(Hadoop 2.0的一个分支，实际上是一个资源管理系统)　　YARN是Hadoop的一个子项目（与MapReduce并列），它实际上是一个资源统一管理系统，可以在上面运行各种计算框架（包括MapReduce、Spark、Storm、MPI等）。　　　　当前Hadoop版本比较混乱，让很多用户不知所措。实际上，当前Hadoop只有两个版本：Hadoop 1.0和Hadoop 2.0，其中，Hadoop 1.0由一个分布式文件系统HDFS和一个离线计算框架MapReduce组成，而Hadoop 2.0则包含一个支持NameNode横向扩展的HDFS，一个资源管理系统YARN和一个运行在YARN上的离线计算框架MapReduce。相比于Hadoop 1.0，Hadoop 2.0功能更加强大，且具有更好的扩展性、性能，并支持多种计算框架。　　　　Borg/YARN/Mesos/Torca/Corona一类系统可以为公司构建一个内部的生态系统，所有应用程序和服务可以“和平而友好”地运行在该生态系统上。有了这类系统之后，你不必忧愁使用Hadoop的哪个版本，是Hadoop 0.20.2还是 Hadoop 1.0，你也不必为选择何种计算模型而苦恼，因此各种软件版本，各种计算模型可以一起运行在一台“超级计算机”上了。　　从开源角度看，YARN的提出，从一定程度上弱化了多计算框架的优劣之争。YARN是在Hadoop MapReduce基础上演化而来的，在MapReduce时代，很多人批评MapReduce不适合迭代计算和流失计算，于是出现了Spark和Storm等计算框架，而这些系统的开发者则在自己的网站上或者论文里与MapReduce对比，鼓吹自己的系统多么先进高效，而出现了YARN之后，则形势变得明朗：MapReduce只是运行在YARN之上的一类应用程序抽象，Spark和Storm本质上也是，他们只是针对不同类型的应用开发的，没有优劣之别，各有所长，合并共处，而且，今后所有计算框架的开发，不出意外的话，也应是在YARN之上。这样，一个以YARN为底层资源管理平台，多种计算框架运行于其上的生态系统诞生了。　　　　目前spark是一个非常流行的内存计算（或者迭代式计算，DAG计算）框架，在MapReduce因效率低下而被广为诟病的今天，spark的出现不禁让大家眼前一亮。　　从架构和应用角度上看，spark是一个仅包含计算逻辑的开发库（尽管它提供个独立运行的master/slave服务，但考虑到稳定后以及与其他类型作业的继承性，通常不会被采用），而不包含任何资源管理和调度相关的实现，这使得spark可以灵活运行在目前比较主流的资源管理系统上，典型的代表是mesos和yarn，我们称之为“spark on mesos”和“spark on yarn”。将spark运行在资源管理系统上将带来非常多的收益，包括：与其他计算框架共享集群资源；资源按需分配，进而提高集群资源利用率等。　　FrameWork On YARN　　运行在YARN上的框架，包括MapReduce-On-YARN, Spark-On-YARN, Storm-On-YARN和Tez-On-YARN。　　（1）MapReduce-On-YARN：YARN上的离线计算；　　（2）Spark-On-YARN：YARN上的内存计算；　　（3）Storm-On-YARN：YARN上的实时/流式计算；　　（4）Tez-On-YARN：YARN上的DAG计算

Yarn 和 MapReduce (MR) 都是 Hadoop 的组件，其中 Yarn 是一个资源管理器，而 MR 是一个分布式计算框架。下面分别介绍它们的编程过程和关系：Yarn 编程过程：1. 编写 Yarn 应用程序的客户端代码，该代码通常由一个提交 Yarn 应用程序的命令和一些相关的配置参数组成。2. 在客户端代码中，需要定义 Yarn 应用程序所需要的资源（如 CPU、内存、磁盘等）以及执行的任务数等。3. 通过客户端代码将应用程序提交给 Yarn，由 Yarn 根据资源需求和调度策略来分配资源，并在集群中启动应用程序的各个任务。MR 编程过程：1. 编写 Map 函数和 Reduce 函数。2. 将数据分割成多个块，并在多个计算节点上开启 Map 任务来处理每个块的数据。3. Reduce 任务将 Map 产生的中间输出结果进行合并，生成最终的结果。Yarn 和 MR 的关系：Yarn 提供了一个资源管理器和调度器，可以将多个 MR 任务分配到不同的计算节点上执行，从而实现了分布式计算的功能。由于 MR 常常需要处理大规模的数据，因此需要 Yarn 这样的分布式计算平台来提供资源调度和管理的支持。因此，两者是密不可分的关系。

如果没有配置的话 能登录集群的话，也可以通过命令来 yarn logs -applicationId 来查看 日志 对于正在进行的任务，打开yarn界面，查看日志在那个节点，登录节点进行查看，如下图所示 进入这个节点后，进入hadoop安装目录的 配置文件目录中，找到yarn-site.xml 查找关键字 yarn.nodemanager.log-dirs 看其指向的路径 然后进入相关的路径查找即可，如下图所示

从YARN的架构图来看，它主要由ResourceManager和ApplicationMaster、NodeManager、ApplicationMaster和Container等组件组成。

查看名称空间 [namespace_id] Cgroups 提供了以下四大功能: 1、资源限制（Resource Limitation）：cgroups 可以对进程组使用的资源总额进行限制。如设定应用运行时使用内存的上限，一旦超过这个配额就发出 OOM（Out of Memory）。 2、优先级分配（Prioritization）：通过分配的 CPU 时间片数量及硬盘 IO 带宽大小，实际上就相当于控制了进程运行的优先级。 3、资源统计（Accounting）： cgroups 可以统计系统的资源使用量，如 CPU 使用时长、内存用量等等，这个功能非常适用于计费。 4、进程控制（Control）：cgroups 可以对进程组执行挂起、恢复等操作。 Docker正是使用cgroup进行资源划分，每个容器都作为一个进程运行起来，每个业务容器都会有一个基础的 pause容器 也就是POD作为基础容器。pause容器提供了划分namespace的内容，并连通同一POD下的所有容器，共享网络资源。 1.CPU:使用调度程序为cgroup任务提供 CPU 的访问。 2.cpuacct:产生cgroup任务的 CPU 资源报告。 3.cpuset：如果是多核心的CPU,这个子系统会为cgroup任务分配单的CPU和内存。 4.devices:允许或拒绝cgroup任务对设备的访问。 5.freezer:暂停和恢复cgroup任务。 6.memory:设置每个cgroup 的内存限制以及产生内存资源报告。 7.net_cls:标记每个网络包以供 cgroup方便使用。 8.ns:命名空间子系统。 9.perf event:增加了对每个group的监测跟踪的能力，可以监测属于某个特定的group 的所有线程以及运行在特定CPU上的线程。 如图所示的 CGroup 层级关系显示，CPU 和 Memory 两个子系统有自己独立的层级系统，而又通过 Task Group 取得关联关系。 资源调度和资源隔离是YARN作为一个资源管理系统，最重要和最基础的两个功能。 1、内存资源隔离 原文链接： https://blog.csdn.net/chen892704067/article/details/76596225 为了避免误杀Container，Hadoop赋予每个进程 年龄 属性，并规定刚启动进程的年龄是1，且MonitoringThread线程每更新一次，各个进程年龄加一 在此基础上，选择被杀死Container的标准如下： 2、cpu资源隔离 Yarn 3.0 版本中，在 Linux 系统环境下，ContainerExecutor 有两种实现： 1、 DefaultContainerExecutor : 简称 DCE , 如其名，是默认的 ContainerExecutor 实现。 如果用户未指定 ContainerExecutor 的具体实现，NM 就会使用它。 DCE 直接使用 bash 来启动 container 进程，所有 container 都使用 NM 进程用户 (yarn) 启动，安全性低且没有任何CPU资源隔离机制。 2、 LinuxContainerExecutor : 简称 LCE，相比于 DCE ，它能提供更多有用的功能，如用户权限隔离，支持使用提交任务用户来启动 container；支持使用 cgroup 进行资源限制； 支持运行 docker container (合并了2.x 版本中的 DockerContainerExecutor)。 LCE 使用可执行的二进制文件 container-executor 来启动 container 进程，container 的用户根据配置可以统一使用默认用户，也可以使用提交任务的用户（需要提前在 NM 上添加所有支持的用户），从而以应用提交者的身份创建文件，运行/销毁 Container，允许用户在启动Container后直接将CPU份额和进程ID写入cgroup路径的方式实现CPU资源隔离。 YARN使用了Cgroups子系统中的CPU和Memory子系统，CPU子系统用于控制Cgroups中所有的进程可以使用的CPU时间片。Memory子系统可用于限定一个进程的内存使用上限，一旦超过该限制，将认为它为OOM，会将其杀死。 对于内存资源隔离，YARN采用了与MRv1这种基于线程监控的资源控制方式，这样做到的主要出发点是：这种方式更加灵活，且能够防止内存骤增骤降导致内存不足而死掉。 对于CPU资源隔离，YARN采用了轻量级的Cgroups。 注:默认情况下，NM未启用任何CPU资源隔离机制，如果想要启用该机制，需使用LinuxContainerExecutor,它能够以应用程序提交者的身份创建文件，运行Container和销毁Container. Linux内核提供namespace完成隔离，Cgroup完成资源限制。namespace+Cgroup构成了容器的底层技术（rootfs是容器文件系统层技术） 参考 https://blog.csdn.net/zhangzhebjut/article/details/37730013 https://www.cnblogs.com/janeysj/p/11274515.html https://www.xiaoheidiannao.com/220959.html https://developer.aliyun.com/article/446778 https://segmentfault.com/a/1190000019016039 https://smarthanwang.github.io/2019/10/12/yarn-container-executor/ https://www.jianshu.com/p/b9245242472b/ https://www.shuzhiduo.com/A/6pdDYYNGzw/ https://www.jianshu.com/p/8f700177d4e4 https://www.cnblogs.com/biyeymyhjob/archive/2012/07/20/2601655.html https://blog.csdn.net/chen892704067/article/details/76596225

前情摘要： 1、用 npm 装的 yarn 2、自定义了 npm 的全局安装位置和缓存 3、用yarn安装taro脚手架的时候，运行项目报错【文件名、目录名或卷标语法不正确】 原因：可能因为 yarn的命令目录bin 与其 全局安装位置 不在一个文件夹下导致 解决方案： 1、查看yarn的命令目录 2、查看yarn的全局安装目录 3、结果发现两者位置并不一致，所以我们要把yarn的全局安装目录放在和bin的位置一个目录 4、别忘了把yarn的bin目录添加到 系统环境变量path 上 5、然后比较保险的做法是：重启电脑，重装taro，重装项目依赖，就ok啦~

对spark on yarn研究比较多的朋友都应该发现过你明明给executor申请了1GB内存，结果发现该executor占用了yarn的2GB内存。对于spark的driver和executor在申请内存的时候有个计算公式： 由于1GB*0.10才100MB，所以会是1GB+384MB<2GB，不符合预期。实际上这个还依赖于yarn的内存调度粒度。resourcemanager的参数 默认yarn的调度最小单元就是1GB，所以结果就是使你原本申请1GB(+额外内存)的内存变为了2GB。 参数含义就是所有AM占用的总内存数要小于yarn所管理总内存的一定比例，默认是0.1。 也即是yarn所能同时运行的任务数受限于该参数和单个AM的内存。 原文： https://blog.csdn.net/rlnLo2pNEfx9c/article/details/89324824

node 项目中最臭名昭著的莫过于 node_modules 文件夹，这个糟糕的结构动辄使你的文件数目增加几万甚至几十万，无论是安装还是删除，都要消耗大量时间，并且占据大量 inode 结点，我们随便进入一个 react 项目文件夹，看一下由于有 node_modules 会使你的项目中的文件个数变成多少： 仅仅一个项目下面就有多达22万个文件。 现在我们来看一下目前的 yarn 版本号是多少： 嗯，目前 yarn 的版本号是 1.22.11 ，那我们如何安装 yarn 2 呢？答案是不需要安装，只需要设置就可以了。 设置完了之后，我们再来看一下 yarn 的版本号： 不是说好的升级到 yarn 2 吗？怎么变成 3.0 了？不用恐慌，越高越好。 然后我们来看一下项目文件夹下多了这么几个文件，首先就是根目录下多了一个 .yarnrc.yml ，里面只有一句话： 相应的，还多了一个文件夹 .yarn ，里面有一个子文件夹 releases ，里面有一个文件 yarn-berry.cjs ，这几个文件就是全部 yarn 2 增加的内容了，这些内容不要在 .gitignore 里忽略，其它的内容是需要忽略的，现在我们来在 .gitignore 里增加一些需要忽略的内容： 接下来，我们准备利用新版的 yarn 安装我们的依赖文件，在此之前，我们需要先设置一下 yarn 库的镜像服务器以加快整个下载过程： 这时候，你再打开项目根目录下的 .yarnrc.yml 文件，会发现里面多了一行： 所以我们知道其实这个 yarn config 命令也没有什么特别的地方，只是通过它来修改 .yarnrc.yml 文件而已，你也可以通过直接修改 .yarnrc.yml 文件来达到同样的效果。 现在，我们开始删除旧的 node_modules 文件夹和 yarn.lock 文件，并重建整个项目： 整个下载过程应该还是比较顺利的，我们来看一下项目文件夹中多了哪些文件： 没有了 node_modules 文件夹，我们来看一下 .yarn/cache 文件夹下有什么内容，里面有我们之前依赖的 node_modules 文件夹下的所有依赖包，但不再是以目录的形式存在，而是变成了一个个 zip 文件， yarn 2 就是利用项目根目录下的 .pnp.cjs 文件定位到这些 zip 文件以达到取代 node_modules 的作用，这样极大程度地减少了项目中的文件个数。 下面我们开始启动项目： 十有八九你的项目这时候是启动不起来的，不要慌，这篇文章告诉你所有的解决方法。 首先，你遇到错误可能是这样： 具体内容可能不一样，但你要注意这个关键词 Your application ，这说明是你的代码当中的某个位置引用了后面的插件，但你没有在 package.json 文件中显式声明它，那为什么之前用 yarn 1 或者 npm 的时候没有这个问题呢？因为以前是有 node_modules 文件夹的，所有依赖包都被平摊在这个文件夹中，即使是被其它依赖的依赖引入的，它也会被释放在 node_modules 根目录下，所以 node 可以很轻松地找到它，而现在这个文件夹没有了，我们必须显式地在 package.json 文件中引用它，才能引导 yarn 找到这个依赖项。因此，解决这种 Your application 缺乏某个依赖项的方法很简单，我们只需要用 yarn 安装它就可以了： 哦，又出错误了： 这是因为我们在安装的时候没有指定版本，导致安装的插件版本过高，我们在 package.json 里把版本降低一些： 然后重新执行 yarn 进行安装，运行 yarn start 再次启动，终于启动起来了！不过，不要高兴得太早，又遇到了这样的问题： 不要慌，既然还是 Your application 缺乏某个依赖包，那就还是我们的问题，停下来再安装它，然后再启动，直到解决完所有 Your application 引起的问题。 这时候，产生了新的错误： 虽然同样是找不到依赖项，但这次的错误不是由于我们自己的应用导致的，而是由于依赖项自身导致的，这种问题该如何解决呢？不要急，我们打开 .yarnrc.yml 文件，按照错误提示增加以下设置： 缺什么咱们就增加什么，有时候还要注意版本号。同样，这个问题不是由于 yarn 2 导致，而是因为我们的依赖项该增加的依赖没有增加而已，我们这里只是给它补全依赖，使它得以正常运行。 别忘了，每次修改完 .yarnrc.yml 之后，都需要重新执行 yarn ，然后再执行 yarn start 。 至此为止，我们的项目终于能够成功运行了！我们来看一下目前项目文件夹中的文件个数： 现在只有 17000 个文件了，比我们最开始的 22 万个文件减少了 20 多万，运行速度也成倍提升。 怎么样，是不是很值得一试呢？ 文章来源于@ 张京老师， https://segmentfault.com/a/1190000040520326

如果你对 npm、yarn 全局安装路径存疑，很混乱分不清，那么这篇文章应该能帮到你。本文以 macOS 为例，不同操作系统可能略有差异。 其实在安装完 Node 之后，便有类似提示： 可以得知 Node 和 NPM 的默认安装路径是 /usr/local/bin 。如果 /usr/local/bin 路径并不存在于环境变量 PATH 中，需在配置文件中写入。比如： 具体配置文件是 ~/.bash_profile 还是 ~/.zshrc ，取决于你当前使用哪一种 Shell 解析器。 使用 which 命令可查看「可执行文件」的路径，比如： 其中 /usr/local/bin 目录下的可执行文件多是软链接，并非文件真正所在路径。 说明一下，本文将以这种方式安装的 Node 称为系统版本的 Node，用于区别使用 nvm 安装的 Node。 从 npm Docs 官方文档中，对「全局安装」如何存放文件都有比较清晰的描述（ 详看 ），翻译过来就是： 其中 prefix 是 npm 的一个配置项（ 详见 ），它的默认值与 Node 的安装位置有关。在 Unix/Linux/Mac 操作系统中，通常是 /usr/local 。在 Windows 操作系统上通常是 %AppData% pm 。其中「可执行文件」是指 package.json 中 bin 字段的配置项。 使用 npm config 命令可对 prefix 配置进行操作： 也可在配置文件 ~/.npmrc 直接进行修改（ 详见 ）。 因此， 可通过以下命令查看： 可通过 npm ls 命令查看全局安装的依赖包，个人更喜欢使用其别名 npm list ，原因是它跟 yarn list 一致。 其打印结果为树状形式，可配合 --depth=n 参数使用以查看包的依赖信息，其中 n 表示树状深度。上面的 npm list -g 相当于 npm list -g --depth=0 。 插个话，在 v2 版本有着较大的差异，比如在 v2 版本将 yarn global 移除，其替代者是 yarn dlx ，更多 请看 ，这里不展开赘述了。 yarn 全局安装路径与 npm 不同，默认情况下： 可通过以下命令查看： 若要修改以上配置，可通过 yarn config 命令处理： 需要注意的是，修改全局安装路径的配置 key 是 global-folder ，可执行文件的 key 为 prefix 。别跟 npm 混淆了。 也可以在配置文件 ~/.yarnrc 直接修改： 需要注意的是，其中 npm 配置文件使用的是 ini-formatted 格式，也就是 key=value 形式，而 yarn 则是 key "value" 形式。 我们知道 npm（Node Package Manager）是 Node 包管理工具，而 nvm（Node Version Manager）则是 Node 版本管理工具。它可以通过命令行快速安装、使用不同版本的 Node。 假设有多个项目使用了不同版本的 Node，或者需要在不同版本的 Node 下测试我们开发的 npm 包，那么使用 nvm 将会很高效。其安装不展开细说，请看 官方文档 。 第一节已经介绍了，使用「传统」的方法安装其路径如下： 但如果使用 nvm 来管理 Node，这些都将会发生变化。当使用官方指引来安装 nvm，相关内容将会默认存放至 ~/.nvm 目录。 当使用 nvm install 来安装 Node，比如： 它将会存放于 ~/.nvm/versions/node/v16.14.0 目录下。 切换 system Node 与 nvm Node，只要通过以下方式即可： 我们观察一下 prefix 的变化就知道其安装路径了： 因此，在使用 nvm 管理的情况下： 前面提到过， prefix 的默认位置与 Node 的安装路径有关。比如，在 Unix/Linux/Mac 操作系统中， prefix 通常是 Node 安装路径的上一级，也就是 ~/.nvm/versions/node/vX.X.X 目录。因此，当我们在切换 Node 版本中，它总能正确地安装到 /usr/local/lib/node_modules 或 ~/.nvm/versions/node/vX.X.X/lib/node_modules/ 目录。 但是，如果在 ~/.npmrc 中配置了 prefix ，无论你如何切换 Node 版本，它总是被安装至所配置的路径下。 这样就违背了用 nvm 的初心，自定义 prefix 配置与 nvm 不兼容。nvm 在其官方文档中用指出（ 详见 ）： 如果你此刻用着 nvm，同时没有意识到这个问题，建议立刻去检查并将其移除。 目前，我同时使用着 nvm、npm、yarn（v1）三个工具，那么平常是这样管理它们的： 基于这种原则下，全局安装的依赖包将有这些路径： 使用以下命令，可查看全局依赖包所在路径： 使用以下命令，可查看已安装的全局依赖包： 到此，本文结束。以上希望可以帮你厘清个中混淆之处。 The end.

默认值开启proxy代理，rm进程启动就有，无需自启动。如果需要可以独立启动 使用场景 : yarn-site.xml配置的地址必须是真实的代理服务地址 使用场景 ：yarn-site.xml配置的地址必须是nginx的代理服务地址，由nginx转发服务 // yarn server的配置与nm的配置一致，可以在nm直接启动 yarn.web-proxy.address 设置真实的yarn server服务地址 略

1.在纺织里,threads一般指密度,而yarn的意思就是纱线!2.短纤就是指短纤维,就是指每一最小单位的纤维是短的(最长不超过10CM),天然纤维里有棉,毛等,而对应的就是长纤维,理论上可以是无限长的,,如丝,麻等! 而化纤是指一种经过化学品中提取或处理出的纤维,可以做成长纤维,也可以做成短纤维!就是这样了!

一、NPM设置淘宝镜像 1.查询当前配置的镜像 2.设置成淘宝镜像 3.换成原来的 二、Yarn 设置淘宝镜像 1.查询当前配置的镜像 2.设置成淘宝镜像 3.换成原来的 三、常用淘宝镜像

Hadoop　　它是一个分布式系统基础架构，由Apache基金会所开发。　　用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。　　Hadoop的框架最核心的设计就是：HDFS和MapReduce.HDFS为海量的数据提供了存储，则MapReduce为海量的数据提供了计算。　　Yarn　　它是Hadoop2.0的升级版。　　Yarn 的优点：　　这个设计大大减小了 JobTracker（也就是现在的 ResourceManager）的资源消耗，并且让监测每一个 Job 子任务 (tasks) 状态的程序分布式化了，更安全、更优美。　　在新的 Yarn 中，ApplicationMaster 是一个可变更的部分，用户可以对不同的编程模型写自己的 AppMst，让更多类型的编程模型能够跑在 Hadoop 集群中，可以参考 hadoop Yarn 官方配置模板中的 mapred-site.xml 配置。　　对于资源的表示以内存为单位 ( 在目前版本的 Yarn 中，没有考虑 cpu 的占用 )，比之前以剩余 slot 数目更合理。　　老的框架中，JobTracker 一个很大的负担就是监控 job 下的 tasks 的运行状况，现在，这个部分就扔给 ApplicationMaster 做了，而 ResourceManager 中有一个模块叫做 ApplicationsMasters( 注意不是 ApplicationMaster)，它是监测 ApplicationMaster 的运行状况，如果出问题，会将其在其他机器上重启。　　Container 是 Yarn 为了将来作资源隔离而提出的一个框架。这一点应该借鉴了 Mesos 的工作，目前是一个框架，仅仅提供 java 虚拟机内存的隔离 ,hadoop 团队的设计思路应该后续能支持更多的资源调度和控制 , 既然资源表示成内存量，那就没有了之前的 map slot/reduce slot 分开造成集群资源闲置的尴尬情况。