当前位置: 亚洲城ca88 > 计算机网络 > 正文

Hadoop跑满状态下的Yarn能源管理谈,学习笔记【计

时间:2020-03-25 10:59来源:计算机网络
今天我们来聊聊 Hadoop集群的CPU内存管理,更多学习资料可点击文末“阅读原文”,进入笔者的个人专栏。 本部分主要是关于 YARN。Yarn 是在 hadoop 2中引入的资源管理系统。用户代码并不

今天我们来聊聊 Hadoop 集群的CPU内存管理,更多学习资料可点击文末“阅读原文”,进入笔者的个人专栏。

本部分主要是关于 YARN。Yarn 是在 hadoop 2 中引入的资源管理系统。用户代码并不会与其直接交互,但是许多分布式计算框架都是作为一个 Yarn 应用来运行的。

计算机网络 1

本文目录:

计算机网络 2

Paste_Image.png

1、Yarn 的历史和由来

yarn applications

一、V1

2、Yarn 相同的领域,还有哪些产品

还有一些应用如 Pig,Hive,Crunch 等是运行在 MP,Spark 或 Tez 上的,不会与 Yarn 直接交互。

原理

首先用户程序 (JobClient) 提交了一个 job,job 的信息会发送到 Job Tracker 中,Job Tracker 是 Map-reduce 框架的中心,他需要与集群中的机器定时通信 (heartbeat), 需要管理哪些程序应该跑在哪些机器上,需要管理所有 job 失败、重启等操作。
——TaskTracker 是 Map-reduce 集群中每台机器都有的一个部分,他做的事情主要是监视自己所在机器的资源情况。
——TaskTracker 同时监视当前机器的 tasks 运行状况。TaskTracker 需要把这些信息通过 heartbeat 发送给 JobTracker,JobTracker 会搜集这些信息以给新提交的 job 分配运行在哪些机器上。上图虚线箭头就是表示消息的发送 - 接收的过程。

3、设计、多租户APP 队列/标签

Yarn Application 运行

YARN 有两种 daemon 进程:

  1. resource manager 每个集群一个,管理集群资源的使用
  2. node manager 集群中每个 node 都有,启动和监控 containers。

通过 jcmd 可以看到这些 daemon 进程:

hadoop@millions-server:~$ jcmd
22256 org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode
22561 org.apache.hadoop.yarn.server.nodemanager.NodeManager
21973 org.apache.hadoop.hdfs.server.namenode.NameNode
22085 org.apache.hadoop.hdfs.server.datanode.DataNode
20141 sun.tools.jcmd.JCmd
22447 org.apache.hadoop.yarn.server.resourcemanager.ResourceManager

Yarn 应用运行的过程可以用下图描述,容器请求可以表述为容器消耗的计算资源的量(主要包括 CPU 和内存):

计算机网络 3

问题

(1)JobTracker 是 Map-reduce 的集中处理点,存在单点故障。
(2)JobTracker 完成了太多的任务,造成了过多的资源消耗,当 map-reduce job 非常多的时候,会造成很大的内存开销,潜在来说,也增加了 JobTracker fail 的风险,这也是业界普遍总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限。
(3)在 TaskTracker 端,以 map/reduce task 的数目作为资源的表示过于简单,没有考虑到 cpu/ 内存的占用情况,如果两个大内存消耗的 task 被调度到了一块,很容易出现 OOM。
(4)在 TaskTracker 端,把资源强制划分为 map task slot 和 reduce task slot, 如果当系统中只有 map task 或者只有 reduce task 的时候,会造成资源的浪费,也就是前面提过的集群资源利用的问题。
(5)源代码层面分析的时候,会发现代码非常的难读,常常因为一个 class 做了太多的事情,代码量达 3000 多行,,造成 class 的任务不清晰,增加 bug 修复和版本维护的难度。
(6)从操作的角度来看,现在的 Hadoop MapReduce 框架在有任何重要的或者不重要的变化 ( 例如 bug 修复,性能提升和特性化 ) 时,都会强制进行系统级别的升级更新。更糟的是,它不管用户的喜好,强制让分布式集群系统的每一个用户端同时更新。这些更新会让用户为了验证他们之前的应用程序是不是适用新的 Hadoop 版本而浪费大量时间。

计算机网络 4

Paste_Image.png

4、Real World 中 Yarn 的问题

YARN 调度

当集群资源紧缺时,需要按照一些预定的策略来分配给不同的任务资源。有三种调度方式:

  1. FIFO:
    先进先出,但是在共享型集群中不合适
  2. Capacity scheduler(hadoop 默认的):
    (1) 计算能力保证。支持多个队列,某个作业可被提交到某一个队列中。每个队列会配置一定比例的计算资源,且所有提交到队列中的作业共享该队列中的资源。
    (2) 灵活性。空闲资源会被分配给那些未达到资源使用上限的队列,当某个未达到资源的队列需要资源时,一旦出现空闲资源资源,便会分配给他们。
    (3) 支持优先级。队列支持作业优先级调度(默认是FIFO)
    (4) 多重租赁。综合考虑多种约束防止单个作业、用户或者队列独占队列或者集群中的资源。
    (5) 基于资源的调度。 支持资源密集型作业,允许作业使用的资源量高于默认值,进而可容纳不同资源需求的作业。不过,当前仅支持内存资源的调度。
  3. Fair Scheduler
    在多个 Job 间分配资源,如果只有一个 Job 则其享有全部资源,如果加入新的 Job,则资源在2个 Job 间分配。

二、Yarn

5、数据驱动的 Yarn 管理,资源治理

Capacity Scheduler 的配置

对于 Capacity scheduler,会将 Job 提交到若干 Queue中,然后每个 Queue 是 FIFO 的,如果 Queue 中有超过一个 Job,并且有空闲资源,给这个 Queue 分配的资源是可以超过其预定的量的。

一个配置文件的示例(配置文件为 capacity-scheduler.xml),有层次的在各个队列之间分配资源比例:

 <property>
    <name>yarn.scheduler.capacity.root.queues</name>
    <value>dev,prod</value>
    <description>
      The queues at the this level (root is the root queue).
    </description>
  </property>

  <property>
    <name>yarn.scheduler.capacity.root.prod.capacity</name>
    <value>40</value>
  </property>

  <property>
    <name>yarn.scheduler.capacity.root.dev.capacity</name>
    <value>60</value>
  </property>

  <property>
    <name>yarn.scheduler.capacity.root.dev.maximum-capacity</name>
    <value>75</value>
  </property>

  <property>
    <name>yarn.scheduler.capacity.root.science.capacity</name>
    <value>50</value>
  </property>

  <property>
    <name>yarn.scheduler.capacity.root.dev.eng.capacity</name>
    <value>50</value>
  </property>

详细的配置说明在这里官方文档。

在提交 Job 时,可以指定 Queue,对于 MapReduce,可以指定 property mapreduce.job.queuename

1.ResourceManager

(1)调度器Scheduler
——调度器根据容量、队列等限制条件(如每个队列分配一定的资源,最多执行一定数量的作业等),将系统中的资源分配给各个正在运行的应用程序。
——调度器是一个“纯调度器”,它不再从事任何与具体应用程序相关的工作,比如不负责监控或者跟踪应用的执行状态等,也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务,这些均交由应用程序相关的ApplicationMaster完成
——资源分配单位用一个抽象概念“资源容器”(Resource Container,简称Container)表示,Container是一个动态资源分配单位,它将内存、CPU、磁盘、网络等资源封装在一起,从而限定每个任务使用的资源量。此外,该调度器是一个可插拔的组件,用户可根据自己的需要设计新的调度器,YARN提供了多种直接可用的调度器,比如Fair Scheduler和Capacity Scheduler等。
(2) 应用程序管理器
应用程序管理器负责管理整个系统中所有应用程序,包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动它等。

6、分析规律,反哺线上

Fair Scheuler 配置

Fair 调度也有 Queue 的概念,资源在 Queue 之间是公平分配的,对同一个 Queue 中的 Job,资源同样是均匀分配的。比如 2 个 Queue:Queue1 Queue2;Queue1 有 Job1,Queue2 有 Job2 以及 Job3,则 Job1 使用 50% 资源, Job2 和 Job3 各 25% 资源。

在 yarn-site.xml 中 设置 yarn.resourcemanager.scheduler.class 可以修改默认的 scheduler:org.apache.yarn.server.resourcemanager.scheduler.fair.FairScheduler

Fair Scheuler 的配置文件为 fair-scheduler(可以通过 yarn.scheduler.fair.allocation.file 修改):

<?xml version="1.0"?>
<allocations>
  <defaultQueueSchedulingPolicy>fair</defaultQueueSchedulingPolicy>
  <queue name="prod">
    <weight>40</weight>
    <schedulingPolicy>fifo</schedulingPolicy>
  </queue>
  <queue name="dev">
    <queue name="eng">
    <queue name="science">
  </queue>
  <queuePlacementPolicy>
    <rule name="specified" create="false">
    <rule name="primaryGroup" create="false">
    <rule name="default" create="dev.eng">
  </queuePlacementPolicy>
</allocations>

defaultQueueSchedulingPolicy 默认为 fair,也可以指定为 FIFO 等。通过 weight 可以分配 Queue 之间分配资源的比例。更详细的配置细节见官方文档。

如何将 Job 放到指定的 Queue 中去由 queuePlacementPolicy 决定:对每一条 rule 逐一尝试。specified 指由应用自己指定 Queue 的名字,如果没有指定或指定的 Queue 不存在,则进入下一条;primaryGroup 指使用用户的 unix group 作为队列名称;最终默认的队列是 dev.eng,将会处理所有没有被处理的 Job。默认的策略是:

  <queuePlacementPolicy>
    <rule name="specified">
    <rule name="user">
  </queuePlacementPolicy>

2.ApplicationMaster

与RM调度器协商以获取资源(用Container表示);
将得到的任务进一步分配给内部的任务;
与NM通信以启动/停止任务;
监控所有任务运行状态,并在任务运行失败时重新为任务申请资源以重启任务。

一、历史和由来

抢占式

配置 property yarn.scheduler.fair.preemption 设置为 true 可以使 Job 抢占式的获取资源,而不用等别人释放。

3.NodeManager

NM是每个节点上的资源和任务管理器,
一方面,它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态
另一方面,它接收并处理来自AM的Container启动/停止等各种请求

当下Hadoop稳定在了2.x.x版本,3.x版本也基本production stable了,虽然敢用的公司很少。在Hadoop 2.x后,都是用 Yarn 来管理集群的计算资源。

延迟以本地运行

配置 property yarn.scheduler.capacity.node-locality-delay 会使 scheduler 尝试等待一段时间以获取本地执行的机会(本地执行就是在数据所在的 node 运行)。

4.Container

Container是YARN中的资源抽象,它封装了某个节点上的多维度资源,如内存、CPU、磁盘、网络等,当AM向RM申请资源时,RM为AM返回的资源便是用Container表示的。YARN会为每个任务分配一个Container,且该任务只能使用该Container中描述的资源。

随着互联网的发展,互联网公司的业务越来越复杂。早在10年前,一个普通的小网站有个50台机器,能有20个Web服务器20个数据库,公司内有10来个应用系统,也就差不多了。但像Google、BAT这种巨无霸,很早就面临了大规模集群的管理问题,且问题越来越大。随着网络的爆炸发展,网络巨头公司的业务线越来越多,越来越复杂。看看现在的BAT,有多少业务线,内部有多少IT系统在不停歇的运转。倘若应用的维护者,都自己维护自己的物理机,那这些机器出问题后,维护成本简直无法估量。

DRF 主要资源 Fairness

默认情况下占用资源主要指内存,如果打开了 DRF,那么在总资源中占比多的将会成为所谓的 DRF,以其在总资源中的占比来评价其所需资源。比如需要集群 6% 的 cpu 和 3% 的内存,那么 cpu 将成为主要资源。

打开 DRF 的方式:

  1. 对于capacity scheduler,在 capacity-scheduler.xml 中设置 yarn.scheduler.capacity.resource-calculatororg.apache.hadoop.yarn.util.resource.DominantResourceCalculator
  2. 对于 fair scheduler,在 allocation 文件里设置顶层元素 defaultQueueSchedulingPolicy 为 drf。

工作流程

计算机网络 5

Paste_Image.png

步骤1 用户向YARN中提交应用程序,其中包括ApplicationMaster程序、
      启动ApplicationMaster的命令、用户程序等。
步骤2 ResourceManager为该应用程序分配第一个Container,
     并与对应的Node-Manager通信,要求它在这个Container中
     启动应用程序的ApplicationMaster。
步骤3 ApplicationMaster首先向ResourceManager注册,这样用户
     可以直接通过ResourceManager查看应用程序的运行状态,然后它将为各个任务申请资源, 
      并监控它的运行状态,直到运行结束,即重复步骤4~7。
步骤4 ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager
       申请和领取资源。
步骤5 一旦ApplicationMaster申请到资源后,便与对应的NodeManager
         通信,要求它启动任务。
步骤6 NodeManager为任务设置好运行环境(包括环境变量、JAR包、
        二进制程序等)后,将任务启动命令写到一个脚本中,并通过运行该脚本启动任务。
步骤7 各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度,
     以让ApplicationMaster随时掌握各个任务的运行状态,从而可以在
     任务失败时重新启动任务。
     在应用程序运行过程中,用户可随时通过RPC向
      ApplicationMaster查询应用程序的当前运行状态。

步骤8 应用程序运行完成后,ApplicationMaster向ResourceManager
     注销并关闭自己。

于是,分布式操作系统就产生了。因此,现在单台操作系统管理本机的CPU、内存,分布式操作系统就管理整个集群成千上外台机器的CPU、内存、甚至网络。

对比

——这个设计大大减小了 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 分开造成集群资源闲置的尴尬情况。

二、相同的领域、产品

资源管理领域:

Google先有了Borg,后又开源了 KubernetesHadoop系有了YarnTwitter开源了Mesos

因为Hadoop的特点和历史原因,Hadoop集群的资源管控发展到了Yarn这套系统后,基本就是由Yarn来专门跑Hadoop应用,即 Mapreduce/Spark等等计算作业。

那么Yarn上面能否跑一些别的项目呢? 当然可以,需要自己编写一个on Yarn的程序,写自己的Application-Master (Hadoop: Writing Yarn Applications )和资源申请模块等。

on-Yarn 应用

笔者这里找了一些开源者尝试的on-Yarn应用:

Docker on YARN

-ca-2017/public/schedule/detail/55936

Presto YARN Integratio

-yarn/

prestoDB/presto-yarn

-yarn

Introducing Hoya HBase on YARN Hortonworks

Introducing Hoya HBase on YARN

但在实际的应用场景中,大多数规模以上公司光跑Mapreduce/Spark的Job,集群资源就都挤破头了,所以other on-Yarn Application,不在本文的讨论范畴内。本文将讨论竞争激烈且真正跑满了Hadoop Application 的 Yarn Cluster。

三、多租户、并行APP队列/标签

Yarn设计的最大初衷,是多租户,并行APP。

在早版本的 Jobtracker/Tasktracker时期,整个集群是first-in-first-out的调度策略。每个APP都在排队跑,一个APP占不满集群的资源,整个集群的计算资源就浪费了。

到了Yarn时期,可以允许多个APP同时跑,按自己的需求共享集群资源。

队列/标签

队列

在当下稳定的Hadoop版本里,资源的调度都是基于队列的。

队列——标签的映射关系

在一个公司里,不同的Team可以按需求把作业提交到不同的队列里。这就好比银行的门店,不同的窗口(Queue)可以办理不同的业务。

根据业务强度,银行会给不同的窗口分配不同的人,有的窗口分配能力强的人(多CPU),甚至开多个窗口(子队列),有的子队列只服务“军人”/“老人” (Sub-queue)。有的窗口分配普通员工。

Yarn的主流调度器 Hadoop: Fair Scheduler Hadoop: Capacity Scheduler 都是基于队列设计的。对这一块还不了解的朋友,可以点击下方Scheduler链接,读读官网的原版wiki:

-yarn/hadoop-yarn-site/CapacityScheduler.html

CapacityScheduler

FairScheduler

本文的第5部分,将会重点谈谈基于Queue History Data 的分析,笔者这里提供两篇关于调度器的文章:

1.Cloudera Community : Cloudera’s Fair Scheduler vs. Capacity Scheduler, which one is the best option to choose?

-101-Training-Quickstart/Cloudera-s-Fair-Scheduler-vs-Capacity-Scheduler-which-one-is-the/m-p/37645#M2251

2.[StackOverflow]: What is the difference between the fair and capacity schedulers?

-is-the-difference-between-the-fair-and-capacity-schedulers

标签

Node label 是一个为了给相同特点的集群机器分组的解决方案。直白地说就是异构机器分组。这一波机器A,用来跑 map-reduce;另一波机器B,用来跑spark;还有一部分机器C,用来跑AI/Machine-Learning Job。

为什么会产生这种需求呢?

因为Hadoop这个技术栈已经产生了很多年了。在公司集群中,有的机器是3年前、5年前买的,有的是近1年买的。那么随着时间的推移,集群中的机器配置必然会是异构性。

一般来讲,都会用老的机器跑一些“实时性不是很重要”的Batch Job,而让一些新一些的机器,跑一些需要快速处理的Spark/Streaming 甚至OLAP的计算任务。

这里有几篇讲NodeLabel的很好的文章,大家也可以参考看看:

slideshare.net/Hadoop_Summit/node-labels-in-yarn-49792443?target=://www.slideshare.net/Hadoop_Summit/node-labels-in-yarn-49792443YARN Node Labels: Label-based scheduling and resource isolation Hadoop Dev-node-labels/Node labels configuration on Yarn-labels-configuration-on-yarn.html

总之,Hadoop的Admin可以把一个或多个Label关联到Queue上,一个Hadoop Application只能使用一个Queue下面的一种Label。例子:

提交MR作业到Label X:

提交mr作业到Xlabel: yarn jar /usr/iop/iopversion/hadoop-mapreduce/hadoop-mapreduce-examples.jar wordcount -D mapreduce.map.node-label-expression=X /tmp/source /tmp/result

提交Spark作业到Label Y:

./bin/spark-submit class org.apache.spark.examples.SparkPi master yarn deploy-mode cluster driver-memory 3g executor-memory 2g conf spark.yarn.am.nodeLabelExpression=Y conf spark.yarn.executor.nodeLabelExpression=Y jars/spark-examples.jar 10

Yarn Queue Label

Tip: YARN Node-labels 功能在Apache Hadoop 2.6被开发出来,但并没有被merge到官方版本中,只能通过打Patch的方式使用,因此是有很多Bug的。官方推荐 Hadoop 2.8.x 之后再使用,Fix了很多Bug,而事实上在Apache Hadoop 2.7.3 版本的官方主业里,NnodeLabel功能被正式介绍出来。

Cloudera 把Node-label的Feature打入了,但很多Bug并没有Fix。笔者会在下一小节着重讲这部分内容。

四、Real World 中 Yarn 使用问题

目前,Yarn已经到了一个相对完备的功能阶段,发展到了多Queue 多租户以及成熟的Label管理。下面来讲讲我个人在运维Yarn的工作时碰到的各种问题。

用户问题

YARN resources are always complained insufficiently by big-data users.

big data infrastructure team里有一个内网的聊天Channel。我总是能听到一些Hadoop User抱怨,说他们的job今天跑慢了,Pending太久了,为什么还拿不到资源等。

如果仔细分析产生问题的原因,总结下来大致有以下2种:

资源分配问题

资源分配不均就可能会导致上述问题的产生。如果给某些队列划分了过多的资源,就会导致某些队列的Job卡住很久。当队列资源使用率达到100%时,另一个队列的资源使用还不到50%。 比如下图,Streaming队列明显快满了,而OLAP队列还使用了不到1/4。

应用程序滥用问题

先给大家show几个图。第一个图是一个APP,经过分析,它申请了32GB的内存,但统计后平均使用的内存是514MB 。 what?作为管理员,看到这种用户,是不是很生气呢…

第二个是APP申请的资源,这一个APP申请了740个CPU,3000GB的总内存,这类APP很多。这种APP我认为调优的空间都很大。一个Mapper/Reducer能优化30%的内存占用量,总体看就是一个很客观的数字。

Yarn的管理员问题

我们怎么才能知道队列的资源使用长期情况呢? 拿什么数据来作为调整Yarn队列Queue级别资源的依据呢?每次新加入了一批机器后,我们当然要给机器打Label,Yarn的Shell Cmd中,打Label:Yarnrmadmin—replaceLabelsOnNode“node1[:port]=label1node2=label2如果一次加入100台机器,打Label去输入这么多命令,很容易出问题。怎么能又快速又安全地搞定这个工作呢?用户在Channel不停地问Application的问题,有什么办法能减少Admin人工回复用户的工作,让用户自助解决问题?

Node-Label问题

Bug1

缺乏 Node-Label 资源显示如下图。

cdh-5.7.3-Hadoop-2.6.0的Yarn UI

在稳定版本中,是可以显示出哪种Label、有多少机器、有多少Memory和CPU资源的。

Node-Label稳定版本Hadoop2.8.x

Bug2

Yarn Shell 功能不全,甚至不能使用list all labels功能。

Bug3

Yarn UI没有分Label去显示Queue的资源使用率。

非稳定版

稳定版

五、数据驱动的Yarn管理

为了解决上一节提出来的种种问题,我们做了很多自动化的工具。

我们用搜集“时间序列”的数据,来评估队列的使用情况用UI Tool 来加快运维操作的批量性/安全性用更简洁明了的图表,来给用户展示他能得到的资源等。

Yarn资源调配

趋势图

为了解决Yarn Queue资源调配的公平,我们制作了Yarn Qqueue Level 的 Capacity 占比History 趋势图。

总揽图:所有子队列的历史资源使用都在这里:大家可以看出哪个队列长期超负荷运转,哪些Queue长期用不满资源。

总揽图主要用来做对比,发现有问题的Queue。

队列图:队列图是针对一个Queue进行详细的分析用的:包括队列里使用哪种Label的机器,队列有多少资源,队列资源的历史使用占比、超负荷占比、Running/Pending APP历史,以及Reserve 的Container历史等。

这样,在user提出质疑时,先让user自己来看是否队列的使用量已经满了、是否队列在Reserve Container,从而满足user的Job等。

级别资源调配

那么,一次Yarn的Queue 级别资源调配应该是这样的:

1.从“总揽图”找到长期相对空闲的队列。

2.把相对“空闲”队列的资源,划归给“超负荷”的队列。

3.等一段时间,再观察“总揽图”,是否“超负荷”队列的资源真的变了。

Yarn运维

在上一节,我们提到了给新加入集群的机器打Label是个漫长的过程。没关系,本着 “让一切人对机器的操作尽可能的自动化”的原则,我们设计给Node批量打Label的UI界面如下。

Yarn Queue 级别资源分配展示的不友好

开源版本的Yarn UI 样式其实很土,很多信息都展示得不够透彻,比如:

Yarn 的Queue资源分配到底占了资源的多少。缺失不同Queue之间的资源对比

像这种文字类的UI,作为使用Hadoop的其它数据团队user,是不够直观的。

我们重绘了Yarn 的Queue Level 资源分配,并着重强调了Node-label在划分资源里的重要性。

解决用户自助排查问题

这一块我们就使用了Linkedin开源的dr.elephant linkedin/dr-elephant.。

这个工具提供了很多针对Hadoop Job的诊断/调休信息,可以帮助用户调优自己的Hadoop Job。我们也基于此做了很多二次开发,比如我们需要这样的功能:

在某个“Queue”下面,按“浪费”的内存数量倒排,分别罗列出所有浪费内存绝对数量/相对数量最多的 Application。

这个工具就好比很多公司的“客服系统”。当遇到简单的问题时,它先让用户自行解决包括查阅文档、语音机器人等;若是遇到用户很难解决的问题时,它会进行人工介入。毕竟公司内是很少Hadoop Admin 的,而每个人的时间资源更是宝贵,不能陷入“运维陷进”。

六、分析规律,反哺线上

如何调整Yarn Queue级别的资源分配,上一章已做了简单的介绍。至于实操,每个公司都不一样,但有一个通用的原则,即Hadoop 运维团队可以按月/季度,设定运维日。所有需要调整Yarn资源的需求,都发给管理员,待管理员在运维日统一调整。另外一个比较有意思的地方是,Yarn 集群资源使用率往往是有高峰期和低谷期。在高峰期时,可能会让集群的使用率持续打满。 而低谷期,使用率往往又可能下降到50%甚至更低。通过之前绘制的集群使用率“总揽图”,以及队列的“队列图”,大家可以分别观察集群总体的规律和每个队列的规律。比如Yarn的总体使用量走势,如下图所示:

分析后得出,Yarn Job最大的来源是来自于作业的调度,即调度系统!

我们可以看到,每一天的凌晨零点左右,资源使用率都会爬上去直到100%,而每一天的早上6点到下午3点,集群资源使用率都会下降,甚至降到50%以下。

很多调度系统都是按天级别来调度作业的,允许用户配置类似Cron语法的Job。很多调度体系还提供简单的 Daily选项,而这个选项就默认把作业的调度时间设置为了0点。这样在0点时,大规模的作业被同时调度出去,互相挤占资源,所以大家都跑得慢。

我们会建议数据团队们,更改不那么重要的Job的Daily运行的小时点,“错峰”运行。

Airflow的Daily调度默认为0点

总结

1.用数据说话,让一切人的决策基于数据;

2.开发灵活方便的Tool ,让一切人对机器的操作尽可能的自动化;

3.谨慎使用开源版本,尤其是非稳定的需要打Patch的功能,做好踩坑填坑的准备。

作者:

汪涉洋,来自美国视频网站hulu的工程师,毕业于北京理工大学计算机专业,目前从事大数据基础架构方面的工作。

原文来自微信公众号:DBAplus社群

编辑:计算机网络 本文来源:Hadoop跑满状态下的Yarn能源管理谈,学习笔记【计

关键词: 亚洲城ca88