1、yarn是一个集群资源管理系统:拥有一个集群一个的资源管理器和运行在集群中的所有节点上的节点管理器来启动和监控容器。 容器使用受限的资源集(内存、CPU等)执行特定于应用程序的流程。
2、管理过程:
要在yarn上运行应用程序,客户端会联系资源管理器,并要求它运行一个应用程序主进程(图4-2中的步骤1)。资源管理器会找到一个节点管理器,它可以在容器中启动应用程序主(步骤2a和2b)。应用程序管理员在运行时所做的完全取决于应用程序。它可以简单地在它正在运行的容器中运行一个计算,并将结果返回给客户端。或者它可以从资源管理器(步骤3)请求更多的容器,并使用它们来运行分布式计算(步骤4a和4b)。后者是MapReduce yarn应用程序所做的,
3、针对spark:采用一次性将所有资源申请完;而MapReduce是map先预先申请资源,reduce在后面,并且任务失败会申请额外的容器来支持。
4、 生命周期:
-
一个应用运行完,就结束。--mapreduce
-
按照workflow或者user seesion执行 --spark
-
长时间运行。 --减少查询时间--impala、slider
5、slider:在yarn上运行现有分布式应用程序,用户可以独立于其他用户在集群上运行他们自己的应用程序实例(比如HBase),这意味着不同的用户可以运行同一个应用程序的不同版本。并提供控制来改变应用程序运行的节点数量,能暂停运行一个正在运行的应用程序。
6、 twill: 似于slider,但除此之外,它还提供了一种简单的编程模型,用于在yarn上开发分布式应用程序。允许你把集群过程定义为Java Runnable的扩展,然后在集群上的yarn容器中运行它们。也提供了支持,包括实时日志记录(来自runnables的日志事件被流回客户端)和命令消息(从客户端发送到runnables)
7、 在MapReduce 1中,有两种类型的守护进程来控制作业执行过程:一个jobtracker和一个或多个tasktracker。jobtracker通过调度任务在任务跟踪器上运行的任务来协调系统上运行的所有作业。任务跟踪器运行任务,并向jobtracker发送进度报告,该跟踪器记录每个作业的总体进展情况。
如果任务失败,jobtracker可以重新安排它在不同的任务跟踪器上。
8、优点:
-
可扩展性:MapReduce 1在4 000个节点和4万个任务中遇到了可伸缩性瓶颈,jobtracker必须同时管理作业和任务。yarn 克服了这些限制:它的设计目的是扩展到10000个节点和10万个任务。
-
高可靠性: 在jobtracker的内存中,大量快速变化的复杂状态(例如,每个任务状态每隔几秒更新一次),就很难将HA改造成jobtracker服务。在yarn中,通过将jobtracker任务分成资源管理和主应用程序,
-
高利用:在MapReduce 1中,每个tasktracker都配置了固定大小槽的静态分配,它们被划分为映射槽,并在配置时减少槽位。地图插槽只能用于运行地图任务,而reduce槽只能用于reduce任务。在纱线中,节点管理器管理资源池,而不是固定数量的指定槽。在纱线上运行的MapReduce不会影响到减少任务必须等待的情况,因为集群上只有map插槽,这在MapReduce 1中可能会发生。如果运行该任务的资源是可用的,那么应用程序将符合它们的条件。此外,纱线中的资源是细粒度的,因此应用程序可以请求它所需要的东西,而不是一个不可分割的槽,它可能太大(这是资源的浪费),或者对于特定的任务来说太小(可能会导致失败)。
-
多租户:在某些方面,多租户的最大好处是,它将Hadoop打开到MapReduce之外的其他类型的分布式应用程序中。MapReduce只是众多的一个yarn应用程序。用户甚至可以在同一个yarn集群上运行不同版本的MapReduce,这使得升级MapReduce的过程更加易于管理。(但是请注意,MapReduce的某些部分,比如作业历史服务器和shuffle处理程序,以及yarn本身,仍然需要在集群中进行升级。)由于Hadoop 2被广泛使用,并且是最新的稳定版本,所以在本书的其余部分中,MapReduce这个术语指的是MapReduce 2,除非另有说明。第7章详细介绍了MapReduce如何在yarn上运行
9、调度方法:
-
FIFO:先进先出, FIFO调度程序将应用程序放置在队列中,并按照提交的顺序运行它们(先进先出)。首先分配队列中第一个应用程序的请求;一旦它的请求得到满足,队列中的下一个应用程序就会被服务,等等。缺点:长时间雨欣的程序会占用资源,而让别的应用程序一致等待。即小作业会被阻塞,直至大作业结束。
-
Capacity,默认为它(配置:capacity-scheduler.xml): 一个单独的专用队列允许小作业在提交时立即启动,尽管这是以总体集群利用率为代价的,因为队列容量是为该队列中的作业保留的。这意味着大型作业的完成时间要比使用FIFO调度程序时要晚。 在组织线上共享Hadoop集群,从而使每个组织被分配到整个集群的某个容量。每个组织都有一个专门的队列,该队列被配置为使用集群容量的给定部分。队列可能以分层方式进一步划分,允许每个组织在组织内不同的用户组之间共享其集群津贴。在队列中,应用程序使用FIFO调度安排。正如我们在图4-3中所看到的,单个作业不使用比其队列容量更多的资源。但是,如果队列中有多个作业,并且有空闲的可用资源,那么容量调度程序可能会将空闲资源分配给队列中的作业,即使这会导致队列的容量被超过。这种行为被称为队列弹性。在正常操作中,容量调度程序不会通过强制杀死容器来抢占容器,因此,如果由于缺少需求而导致队列处于容量不足,然后需求增加,队列只会返回容量,因为随着容器的完成,资源从其他队列中释放出来。可以通过配置最大容量的队列来减轻这一问题,这样它们就不会过多地进入其他队列的容量。当然,这是以队列弹性为代价的,因此,在尝试和错误中应该找到合理的权衡。
-
Fair Schedulers(配置:fair-scheduler.xml): 不需要保留一定数量的容量,因为它将动态地平衡所有正在运行的作业之间的资源。在第一个(大型)工作开始之后,它是唯一运行的作业,所以它获得了集群中的所有资源。当第二个(小的)作业开始时,它将分配一半的集群资源,以便每个作业都使用它的公平资源。 请注意,在第二个作业开始的时间和它获得公平份额的时间之间存在一个延迟,因为它必须等待资源释放,因为第一个作业所使用的容器已经完成。在小作业完成并不再需要资源之后,大作业又回到了使用全部集群容量。总体效果是高集群利用率和及时的小作业完成。 在没有分配文件的情况下,公平调度程序像前面描述的那样运行:每个应用程序都被放置在一个以用户命名的队列中,当用户提交第一个应用程序时动态地创建队列。每个队列配置都在分配文件中指定。这允许配置分级队列,就像容量调度器所支持的那样。
权重与百分比不完全相同,即使这个例子使用的数字加起来是100,为了简单起见。我们可以为刺激和开发队列指定2和3的权重,以达到相同的队列权重。 当设置权重时,请记住考虑默认队列和动态创建的队列(例如以用户命名的队列)。这些不是在分配文件中指定的,但是仍然有权重1。最小资源设置不是一个硬性限制,而是调度程序用来优先分配资源分配。如果两个队列低于其公平份额,那么最低于其最小值的队列将首先分配资源。 queuePlacementPolicy元素包含一个规则列表,每一个规则都将依次尝试,直到匹配发生。 specified 规则:将应用程序放置在它指定的队列中;如果没有指定,或者指定的队列不存在,那么规则就不匹配,下一个规则将被尝试。 primaryGroup规则:尝试将应用程序放置在一个队列中,该队列具有user’s primary Unix group。default规则: 是一个包罗万象的规则,并且总是将应用程序放置在dev.eng队列中。 公平调度程序支持抢占。 抢占允许调度程序为正在运行的队列杀死容器,这些队列的资源超出了它们的公平份额,这样资源就可以分配给一个位于其公平份额之下的队列。这样会降低集群效率。抢占设置方法( yarn.scheduler.fair.preemption to true):1、minimum share : 如果一个队列在没有获得最小保证份额的情况下等待它的最小份额抢占超时,那么调度程序可能会抢占其他容器。2、fair share: 如果一个队列在没有获得最小保证份额的情况下等待它的最小份额抢占超时,那么调度程序可能会抢占其他容器。
10、延迟调度:针对Capacity:yarn.scheduler.capacity.node-locality-delay
针对Fair Schedulers:yarn.scheduler.fair.locality.threshold.node
11、 如果一个用户的应用程序需要大量的CPU,但是内存很少,而另一个s需要很少的CPU和大量的内存,那么这两个应用程序是如何比较的呢?yarn中的调度程序解决这个问题的方法是观察每个用户的主要资源,并将其作为集群使用的度量。这种方法被称为优势资源公平,简称DRF。默认是不使用DFR。
针对Capacity:yarn.scheduler.capacity.resource-calculator to
org.apache.hadoop.yarn.util.resource.DominantResourceCalculator in capacity-
scheduler.xml.
针对Fair Schedulers:by setting the top-level element defaultQueueSchedulingPolicy in the allocation file to drf。