作者介绍

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

本文目录：

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

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

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

资源管理领域：

• Google先有了Borg，后又开源了 Kubernetes

• Hadoop系有了Yarn

• Twitter开源了Mesos

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

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

on－Yarn 应用

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

• Docker on YARN

https://conferences.oreilly.com/strata/strata-ca-2017/public/schedule/detail/55936

• Presto YARN Integratio

https://prestodb.io/presto-yarn/

• prestoDB/presto-yarn

https://github.com/prestodb/presto-yarn

• Introducing Hoya - HBase on YARN - Hortonworks

https://hortonworks.com/blog/introducing-hoya-hbase-on-yarn/

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

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：

http://hadoop.apache.org/docs/r2.7.1/hadoop-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?

https://community.cloudera.com/t5/Hadoop-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?

https://stackoverflow.com/questions/26546613/what-is-the-difference-between-the-fair-and-capacity-schedulers

• 标签

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

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

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

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

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

1. slideshare.net/Hadoop_Summit/node-labels-in-yarn-49792443

   http://link.zhihu.com/?target=https%3A//www.slideshare.net/Hadoop_Summit/node-labels-in-yarn-49792443

2. YARN Node Labels: Label-based scheduling and resource isolation - Hadoop Dev

   https://developer.ibm.com/hadoop/2017/03/10/yarn-node-labels/

3. Node labels configuration on Yarn

   https://community.hortonworks.com/articles/72450/node-labels-configuration-on-yarn.html

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

提交MR作业到Label X：

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。笔者会在下一小节着重讲这部分内容。

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

用户问题