《企业级大数据平台构建：架构与实现》——2.4　YARN

2.4　YARN

2.4.1　概述

随着Hadoop生态的发展，开源社区出现了多种多样的技术组件。有用来构建数据仓库的Hive，也有基于内存的计算框架Spark，还有我们之前介绍过的NoSQL数据库HBase等。这些技术组件的出现，极大地丰富了大数据的生态体系，但同时也引出了一些新的问题。作为一个大数据底层支撑平台，同时部署Hive、HBase和Spark等多种技术组件是一件十分平常的事情。这些为大数据场景设计的技术组件可以说个个都是消耗资源的大户，这些资源包括服务器的CPU和内存。通常这些技术组件都有一套自己的资源调度系统用来管理任务的资源分配，但当它们同时部署在一起的时候就出问题了。这时会有两种情况产生，第一种情况是某些组件可能申请不到服务器资源。比如一台拥有32G内存的服务器同时部署了HBase和Spark，HBase的RegionServer启动时占用了20GB内存，这时Spark开始执行某个任务也需要使用20GB内存，但这时发现没有足够的内存资源使用了。因为从每个组件独立的视角来看他们都认为自己能使用100%的服务器资源，但服务器资源的总量就那么多，不可能同时满足所有组件的需求。第二种是可能会出现资源分配不合理的情况，导致整体资源使用率偏低。我们同样用刚才的场景举例，Spark启动了一个任务申请使用30GB的内存，但是实际上它的程序逻辑并不需要使用这么多资源。这就出现了一种HBase没有资源什么事情也做不了，但Spark占用了资源却没有事情可做的局面。

为了解决类似的问题，我们需要一种通用的资源调度框架，对整个集群的资源进行统筹管理。

YARN就是一款优秀的集群资源调度框架。YARN是Yet Another Resource Negotiator的缩写，它是Hadoop的第二代集群资源调度框架。解决了Hadoop第一代集群资源调度框架上可靠性差、扩展性差等一系列问题，同时YARN从MapReduce中完全独立出来，从专门支撑MapReduce任务调度升级成为了一个支持多种应用类型的通用集群资源调度框架。除了MapReduce之外，Spark、Hive等一系列服务都可以作为应用运行在Yarn之上，统一使用Yarn为整个集群资源进行宏观的调度与分配，如图2-12所示。

图2-12　YARN的逻辑结构