Hadoop运维工程师专家之路--第二章Hadoop架构简介

第二章Hadoop架构简介

本章包括

l  Hadoop架构

l  分布式集群

l  HDFS架构

l  YARN架构

本章介绍Hadoop架构。在你学习管理Hadoop集群之前，有必要先了解下Hadoop的集群架构。Hadoop包括两个基础层：存储层HDFS，处理层YARN。

本章非常关键，因为它引入了几个关键术语，以及相关的守护进程和进程相互配合，完成hadoop数据库的存储和计算。

 

分布式计算和Hadoop

正如第一章‘Hadoop及其运行环境简介’所描述的，Hadoop拥有一个分布式计算模型—将大量的数据块分布到一系列集群节点上，每个节点计算一部分数据。在进入Hadoop架构本身的细节之前,让我们花点时间了解下分布式计算带来的挑战以及Hadoop如何解决这些挑战的。

本质上讲,分布式计算需符合以下要求：

l  扩展性：通过增加机器，可以线性扩展集群的处理能力和存储能力；

l  容错性：如果集群中的一个节点down掉了，主要的计算任务本身不应该失败或受到不利影响。

l  可恢复性：如果一个job整体失败或者部分失败了，不应该丢失任何数据。

Hadoop已经通过精心设计满足了这些分布式计算的基本要求。Hadoop架构中通过以下策略和原则解决了分布式计算带来的挑战：

l  数据存储在集群中的大部分(所有)节点上。通过数据不动代码动的原则，提高大数据处理的效率。

l  Hadoop只需关注数据本身及算法逻辑，Hadoop负责底层的分布式计算的细节；

l  Job具有高容错性。如果集群中一个或者多个节点down掉，或者Job中的某个task失败，Job本身将继续执行，直至完成。

 

Hadoop架构

为了更好的使用Hadoop，了解其关键的组件是非常重要的：HDFS—存储组件；YARN---处理组件(资源调度组件)。

网页排名和搜索社交网络和社交网站是两个例子你处理很常规的数据流,这使得它容易挖掘数据通过数据并行。为了有效地处理这些类型的大型数据集,一个新的编程范式使用不同类型的软件堆栈的演变。而传统的数据处理都集中在越来越大的电脑,导致超级计算机的诞生,这种新方法采用集群互联便宜的电脑。

新的软件堆栈,如由Hadoop分布式文件系统作为基础。与传统的数据库中,这个文件系统通常使用非常大的数据块为了迅速处理大量的数据。另一个关键特性是内置冗余的数据,因为文件系统使用廉价的计算节点,随时都可能会失败。提供的冗余是复制所有数据跨多个服务器,通常三个副本。图2.1显示了Hadoop的分布式计算体系结构。

在下面几节中,我们将讨论Hadoop的两个主要组件：HDFS和YARN。HDFS为所有的Hadoop操作提供了数据存储功能。存储在Hadoop中的数据，实际上存储在了HDFS上面，HDFS基于底层的(Linux/Windows)文件系统来存储数据。YARN为运行在Hadoop之上的MapReduce和Spark等计算框架提供了资源调度功能。

在深入讨论Hadoop之前，我们先来了解下什么是Hadoop集群,集群中节点的不同类型和在一个集群中运行的不同类型的服务。

 

Hadoop集群

在第一章中，我解释了什么是Hadoop集群。概括来讲，一个Hadoop集群就是安装了Hadoop软件(包括HDFS和YARN两个组件)的机器的集合。只要多于一台机器安装了Hadoop软件都可以成为Hadoop集群。你可以运行由少量机器组成的Hadoop集群，一些组织如Yahoo，运行的Hadoop集群由上万台机器组成。无论集群的大小，工作原理是一样的。

实际上，Hadoop通过运行一系列的后台进程实现了数据存储和资源调度功能。用户不需要与这些进程直接交互，这些后台进程主要用来通过网络进行输入/输出。在一个Linux系统中，这些后台进程运行在一个独立的JVM中。

Master和Worker节点

Hadoop集群中的节点分为两种基本类型：

l  Master节点：这些节点上运行的服务，用来协调集群运行的工作。客户端Client连接Master节点来执行计算任务。在每个集群中, 都有少量的Master主节点，Master节点的个数取决于集群的规模。

l  Worker节点：这些节点按Master节点中进程的指令要求，执行相应的操作。集群中大部分的节点都是worker节点，数据的存储和计算任务的执行都发生在worker节点上。

 

Hadoop服务

有几个关键的Hadoop服务你需要熟悉。这些Hadoop服务相互配合，在集群中执行实际的工作。HDFS相关的服务负责存储相关的工作；YARN相关的服务负责计算任务相关的工作。下面简要介绍各种 Hadoop的服务。

HDFS服务

HDFS服务用来管理HDFS存储：

l  NameNode：NameNode服务运行在Master节点上，负责维护HDFS存储相关的元数据，如文件系统目录树和文件的位置。当客户端Client试图读或写HDFS上的数据，它需要先连接NameNode服务，NameNode服务会为Client提供HDFS上面的文件位置信息。

l  Secondary NameNode和Standby NameNode：在集群中的Master节点上，需要运行上述两个服务中的一个。这些服务用来通过执行任务如检查点(更新)元数据文件来减轻NameNode服务的负担。

l  DataNode：集群中的worker节点存储了HDFS数据块。DataNode服务与NameNode服务保持联系，当文件系统发生变化时，会更新NameNode服务。

YARN服务

与HDFS服务类似，有几个YARN服务运行在master节点和worker节点上面：

l  ResourceManager:整个集群中只有一个ResourceManager服务，运行在Master节点上，负责为运行在worker节点上的job分配和调度集群资源。

l  ApplicationMaster:集群中的每一个Application，都对应一个ApplicationMaster服务。ApplicationMaster服务负责协调Application的执行，与ResourceManager服务谈判，申请Application运行所需资源。

l  NodeManager:每一个worker节点上都有一个NodeManager服务，负责运行和管理worker节点上的任务task(task是job或Application的组件)；NodeManager服务会与ResourceManager保持联系，发送心跳信息，汇报健康状态以及运行的task状态。

至此，我们对Hadoop集群有了大概了解。是时候进一步学习Hadoop的两大支柱组件—HDFS和YARN了。理解这两大组件是如何相互配合完成复杂的分布式计算任务的，是非常重要的。先讨论HDFS。

数据存储---HDFS(Hadoop分布式文件系统)

HDFS是一个位于底层服务器存储之上的分布式文件系统，与基础存储系统有很多相似的地方。HDFS分布式文件系统利用在网络上的计算机存储大量的数据，并且内置数据冗余，保护数据。HDFS被设计为快速、容错处理的文件系统，从而可以使用廉价的存储硬件。服务器存储，如Linux系统服务器存储，符合POSIX需求，然而HDFS并不完全符合POSIX需求。这样设计的目的，是为了能够处理大量的数据。

最开始，MapReduce编程模型是Hadoop可以使用的唯一编程引擎，直到现在，此编程模型在Hadoop生态环境中也非常流行。在使用诸如NFS存储系统时，由于存储和网络IO的原因，可能导致数据处理变慢，MapReduce避免了这一点，可以处理大量数据。大量的数据分散到集群的各个节点，但是MapReduce将他看做一个独立文件系统。所以，MapReduce程序以本地的方式读取HDFS上的数据，避免的数据的网络传输---数据不动代码动，数据本地性。

 

HDFS独特的特性

HDFS有几个独特的特性,使它适合大规模分布式处理。在下面几节中，我简要回顾下HDFS是如何支持高效的大数据处理的。

处理大数据集

通常情况下，非Hadoop数据库都比较小，最多存储TB级别的数据和少量的数据文件。Hadoop数据库可以处理PB级别的数据和上千的数据文件。

容错

Hadoop集群拥有大量的服务器,这样就可以利用这些服务器进行并行工作。服务器失败和存储失败是完全有可能的。但是某个服务器和存储的失败不应该影响到整个集群的工作。默认情况下，HDFS上的数据存储了3个副本，也就是说HDFS中的每一个数据块(data block)存储在了三个不同的集群节点上面。你可以增加或者减少默认的副本因子，也可以对不同的数据设置不同的副本数，因为副本数是数据文件级别的。

数据的流访问

传统数据库的主要用于快速访问数据，而不是用于批处理场景。Hadoop最初就为数据集的批处理而设计(最近出现了新的处理范例如交互式SQL,迭代处理,搜索处理和流处理)并且提供了数据集的流式访问功能。

简单的数据一致性模型

与传统数据库不同,Hadoop数据文件采用了write-once-read-many访问模型。数据一致性问题不会在Hadoop文件系统中出现，因为在任何时候只能有一个写客户端在写入一个文件。

HDFS架构

HDFS支持以文件的形式存储数据，文件会被分解为多个数据块blocks。因为Hadoop被设计为用来处理大量数据，所以HDFS的数据块大小比传统的关系型数据库大得多。默认的块大小为128M，块的大小可以配置，如可以配置为512M。

注意：

一般情况下，术语NameNode既表示NameNode后台进程，也表示NameNode所运行的集群节点。数据DataNode也是这样的，既表示DataNode后台进程，也表示后台进程所运行的服务器节点。

 

Master Node 和Worker Node

在Hadoop集群中，包括多个节点，这些节点中的一个或者多个会作为Master nodes。Master node上运行着关键的Hadoop服务，如Name Node服务和ResourceManager服务。集群中的其他节点作为worker node，经常称为DataNodes。这些节点用来存储数据块，其上还运行了NodeManager服务(YARN)。大部分情况下，会在每个worker node上运行一个NodeManager，你也可以不这么做。图2.2展示了Master nodes和Worker nodes在Hadoop集群中是如何连接在一起的。实线表示免密码SSH登录。

Hadoop集群中，HDFS文件系统上面存储的数据位于worker nodes上面。HDFS数据以分布式的方式存放在集群中的各个worker nodes节点上面，对用户来说，是一个统一的文件系统，用户可以从任一集群节点来访问文件系统中的数据。用户可以运行一个只包含一个namenode的Hadoop集群。在生产环境下，会使用两个NameNode，一个NameNode处于active状态，另一个NameNode处于standby状态，当处于active状态的Namenode失败时，standby状态的Namenode会变成active状态，接替失败Namenode的工作。NameNode和datanodes服务在HDFS数据写入和读取操作上，相互配合，完成了数据的写入和读取。下面是NameNode和datanodes在数据读取和写入操作中的功能总结。

Namenode的功能

NameNode通过执行以下任务来管理文件系统名称空间：

l 维护文件系统的元数据，如文件的层次结构，每个文件的文件块的位置；

l 管理用户访问数据文件；

l 将数据块映射到集群中的DataNodes上；

l 执行文件系统操作，如打开/关闭文件/目录

l 接收集群中的DataNodes服务注册，处理DataNodes发送的心跳信息

l 确定数据副本存放位置，删除多余的数据副本；

l 处理DataNodes发送的块报告信息，维护数据块的位置信息

虽然NameNode知道所有DataNode上存储的HDFS文件数据块；但是Namenode并不存储数据块的位置----在集群启动时，DataNodes会发送数据块信息给NameNode，NameNode会根据这些信息构建数据块的位置，这些位置信息会存储在内存中，以便于快速存取。

DataNode的功能

根据Namenode发送的指令，DataNodes具有以下功能：

l 提供数据块在本地文件系统中的存储位置；

l 配合完成客户端的文件读/写操作；

l 创建/删除数据块；

l 跨集群复制数据；

l 通过周期性发送块报告和心跳(block reports and heartbeats)的方式与Namenode保持联系。心跳信息用来确认DataNode是否存活和健康状况，块报告信息包括此DataNode上管理的数据块信息。

注意：

需要理解的关键一点是：在任何时候，HDFS数据都不会通过Namenode进行传输。客户端存储数据依赖于DataNode。Namenode只是促进/授权了数据存取。这样做是有道理的，因为在集群中任何时候只有一个Namenode可用，如果Namenode负责大量的数据传输，那么Namenode将会成为数据访问的瓶颈。此外，数据本地化是HDFS的一个很重要的特点---客户端应用会发送到数据所在的节点上处理数据(数据不动代码动)，从而提高数据处理效率。

HDFS文件系统

Hadoop是一个高效处理大数据的框架。了解Hadoop如何存储大数据是非常重要的。

HDFS文件系统与底层系统的文件系统如Linux ext3或ext4是不同的。HDFS采用了一个基于块的文件系统，即大数据文件会被分解为数据块进行存储。

在Hadoop集群中，一个文件和一个集群节点没有一对一的关系。也就是说，一个文件可以有多个数据块组成，这些数据块不一定存储在同一个集群节点上。

一个文件的各个数据块以一种相对随机的方式分布在整个集群的各个节点上。这样做，使得Hadoop 可以存储比单个磁盘存储大得多的文件。如果你存储的文件的数据块分布在多个集群节点上，当其中一个节点down掉了，将会发生什么呢？这会没事的，因为Hadoop对每一个数据块默认情况下存储了3个副本。

注意：

需要理解的关键一点是，Hadoop文件系统架构的底层逻辑是：Hadoop并没有设计成一个通用文件系统。相反，他是为处理较大的批处理job而设计，这些job通常会按顺序读取非常大的文件，从文件开始读到结尾。这与大多数OLTP应用程序形成了鲜明的对比。

HDFS支持用户存储数据到文件中，这些文件会分成多个数据块。因为Hadoop被设计为处理大数据，所以HDFS的数据块的大小比传统的关系型数据库的数据块大小大得多。

传统关系型数据库的数据块大小一般位于4MB-16MB之间，Hadoop使用最小块大小为64 MB，常用的块大小为128MB或者256MB。较大的块有以下优点：

l 相比较小的块，较大的块存储会产生较小的元数据；

l 由于大量数据可以按顺序读取,较快流读取数据更容易执行。

如果数据块较大，数据块的数量会减少，这会导致任务的运行时间增加，因为较大的数据块减少了任务处理的并行度。所以数据块的大小设置要和集群的处理能力相匹配。

图2.3展示了Hadoop如何将一个文件分解为多个数据块，数据块的大小由Hadoop的block size决定，默认大小为128MB。

每一个数据块会有三个副本，分布在集群节点上。正是这种将数据分割成易于消化的块能力，使Hadoop可以使用一组节点并行处理庞大的数据文件,每个节点一次处理一个数据块。

下面简要回顾下HDFS的关键特性。

文件系统组织结构

    HDFS中的文件组织形式与Linux/Unix系统中的文件组织形式类似，都有一个树型目录和文件的层次结构。使用相应的HDFS命令，可以实现Linux/Unix系统中常见的文件操作。

因为HDFS采用了write-once-read-many访问模型，一旦你写一个文件到HDFS, 你不能修改其内容。你也不能用已有名称覆盖现有的文件。您可以执行以下操作，因为它们只是元数据操作，并没有修改文件本身的内容:

l 移动一个文件

l 删除一个文件

l 重命名一个文件

HDFS数据格式

HDFS需要处理存储在非常大的文件中的大量的数据。在处理大型HDFS文件时,MapReduce在记录边界将文件分为多个部分,所以它可以启动多个mapper进程同时从大文件读取数据。可分割的数据格式允许一个文件在记录边界被正确地分割成多个部分。Hadoop生态环境中，倾向于使用二进制格式而不是文本格式存储数据到HDFS上，因为二进制格式防止不完整的记录被写入文件,可以捕捉并忽略错误创建的记录(由于数据损坏或不完整)。这种问题可能出现,例如,当一个集群在写数据时意外耗尽了存储空间。对一个好的HDFS文件格式来说，数据压缩能力也是一个关键需求。一个受欢迎的文件格式是Avro容器文件格式。这种文件格式可分割，可压缩。另一个常见的HDFS数据格式是SequenceFile，一种以键值列表表示的可分割的文件格式。用户还可以使用序列化器自定义数据格式,这让用户可以以任何他们选择格式写入数据。

HDFS文件写入

当一个客户端程序需要向HDFS写入数据，客户端会先执行一个初始化写入，写入数据到客户端机器中的一个本地文件中，一个临时文件。当客户端完成写入并关闭了写入，或者临时文件的大小超过了一个数据块的大小，Hadoop将会创建一个文件，并为这个文件分配数据块。接着临时文件的内容写入到这个新的HDFS文件中，一个数据块接着一个数据块写入。在第一个数据块写入之后，数据块的另两个副本(默认3副本)会写入到集群中另外两个DataNode中，一个接着一个写入。只有当所有数据块的副本都完全写入到了指定的节点中，写入操作才算成功完成。

数据复制

数据复制是Hadoop的特性之一，此特性为Hadoop提供了容错特性。由于Hadoop维护了数据的多个副本，所以集群中的数据丢失情况是很难出现的。

提示

HDFS会自动复制低于副本数的数据块。如果一个磁盘或者服务器坏掉了，你不需要为之失眠。Hadoop将自动做所需要做的!

Hadoop优化数据读取的方式是：选择离读取请求最近(同节点>同机架>不同机架)的副本数据块进行读取。

使用Hadoop本地类库，你可以存取HDFS上的数据。对应用程序来说，存取HDFS上的数据或者从Hadoop集群中导入导出数据，一般会使用客户端本地类库，而不是Hadoop本地类库。WebHDFS提供了使用HTTP REST API存取HDFS数据的方式。使用WebHDFS，你可以使用多种语言来存取Hadoop数据，而不需要在本地安装Hadoop。通过WebHDFS，你可以使用诸如curl和wget等工具来下载HDFS数据。WebHDFS提供了数据的读写操作，支持所有的ＨＤＦＳ操作。在第十章会详细讨论。

Namenode操作

每一个Hadoop集群都有一个处于激活状态的NameNode。NameNode在内存中存储了所有的元数据(如HDFS的目录结构和文件权限等元数据)，同时会把相同的元数据信息持久化到磁盘上。下面列出的信息会被NameNode存储在磁盘上的fsimage文件中：

l HDFS中所有文件的名称

l HDFS的目录结构

l HDFS中所有文件的权限信息

命名空间namespace以一定层次结构的方式包含了文件目录以及文件列表。每一个namespace都有一个唯一的namespace ID，存储在所有集群节点上，为了防止使用不同的名称空间ID 的datanode偶然加入了错误集群。

    任何时候由于诸如文件创建或删除导致的元数据变化，并不会立即更新到fsimage文件中。这些元数据变化会存储在磁盘上的edits file文件中。默认情况下，每小时，Secondary NameNode会合并edits file和fsimage file,会用合并后的信息刷新fsimage file。此时，NameNode会截取truncates旧的edits file，开始写入新的内容。

    图2.4展示了NameNode和DataNode之间的关系，以及HDFS客户端如何与NameNode和DataNode进行交互的。

当HDFS客户端准备读取或者写入DataNode上的文件时，客户端会先连接NameNode，获取文件的元数据。NameNode使用HDFS元数据来确定哪个DataNode上存储了HDFS文件/users/test.txt的数据块。

    数据文件由数据块组成，并且数据是由副本的(默认3副本)。

NameNode存储HDFS元数据在内存中的唯一原因是为了客户端高效的存取HDFS数据。客户端不能直接访问DataNode，因为客户端不知道哪个DataNode存储了他们需要的数据。客户端访问NameNode，NameNode扮演了客户端和DataNode之间协调员的角色。NameNode会将文件块的块数以及位置返回给客户端。

最初,文件元数据存储在磁盘上的fsimage文件中。当元数据由于文件创建或删除等操作发生了改变，更改信息会写入磁盘上事务日志文件edits file。Secondary NameNode周期性的合并fsimage 和 edits files两个文件，形成一个新的fsimage文件。之后，NameNode就会删除edits file。

当客户端程序向HDFS文件中写数据时，NameNode会更新内存中的HDFS元数据，这些改变会同时更新到edits file中，这么做的原因是为了保护命名空间namespace的修改---如果NameNode down掉了，那么内存中的信息会全部丢失。

如果NameNode因为某种原因停止工作，那么HDFS将对用户或者应用程序不可用。你必须恢复(重启)NameNode的运行之后，HDFS对用户来说才变为可用。当然，如果配置了NameNode的高可用，standby NameNode会自动变为激活状态。这种情况下，NameNode down掉不会影响什么，集群会不间断提供服务。

MapReduce任务中的map进程想读取HDFS上的数据，它首先要连接NameNode。NameNode会将数据块的名称和位置信息发送给map客户端。

类似的，一个reduce进程输出结果到HDFS上面，也会连接NameNode，NameNode将提供块的名称和DataNodes的位置供reducer进程写文件。

也就是说，NameNode客户端会提供一些approved状态的DataNode列表告诉客户端写到哪些地方。NameNode本身是看不到任何数据的---只是扮演了一个引导者的角色。正如你所看到客户端程序的读写操作都会首先与NameNode建立连接---所以，NameNode不可用，意味着集群的基本上不可用。

Secondary NameNode 扮演了一个家政服务的角色，提供周期性的建立fsimage file检查点服务，但是当NameNode不可用时，它不能替代NameNode的角色。此时你需要启用一个Standby NameNode服务(HA),形成高可用。

Secondary NameNode

NameNode 不应该被频繁的重启---当NameNode不可用，意味着集群不可用，也就是说你应该避免这种情况发生。

NameNode不可用，就没有办法知道一个文件的数据块存储在哪些DataNodes上面，也就是说所有的HDFS文件都丢失了。Edits file(NameNode元数据文件fsimage file的事务日志文件)将会变得很大。当你重启NameNode的时候，会耗费很长的时间。

为了避免这种情况，Hadoop采用了一个Secondary NameNode服务。这个服务会周期性的执行fsimage file的检查点---检查点的意思是合并fsimage file和edits file。Secondary NameNode 有时也称为检查点节点，因为它为NameNode提供了检查点服务。

如果你的集群中没有SecondaryNameNode服务，将无法执行检查点功能。加入集群运行了6个月后因为磁盘空间耗尽而down掉了，此时重启集群将会耗费你几天的时间，期间集群是不可用的。

当一个客户端(如一个mapper进程)需要读取HDFS上的文件，他需要文件的block Ids。通过连接NameNode获取block IDS。NameNode并不是从磁盘上的fsimage file文件中查找出block IDS的，而是从内存中读取到返回给客户端的，因为在启动的时候，fsimage file已经读取到内存中了。

图2.5展示了Secondary NameNode是如何执行fsimage file的检查点的，如何发送给NameNode，使NameNode自身不用关心检查点的问题。Secondary NameNode会周期性的查询NameNode的edits file。这些日志中记录了HDFS元数据的变化。Secondary NameNode会拷贝更新后的fsimage到NameNode上面。

当一个数据块写入ＨＤＦＳ，数据块只包含了文件的一部分数据。一个文件在写入到ＨＤＦＳ之前就被分解为多个数据块。每一个数据块由文件的一部分内容数据文件和与数据块关联的元数据文件，元数据文件内容是校验码数据，读取的时候，用来确认数据块的完整性。ＤａｔａＮｏｄｅ自己并不知道一个数据块数据哪个文件―――这些信息是ＮａｍｅＮｏｄｅ元数据的一部分。

HDFS高可用和Standby NameNode

    由于NameNode用来维护文件系统的命名空间和元数据，对集群来说是必不可少的。Hadoop2弥补了Hadoop1的一个缺陷，提供了NameNode高可用功能。在Hadoop2中，你可以创建一个Standby NameNode服务来提供高可用功能。当提供了StandbyNameNode，就不需要运行Secondary NameNode服务了。

NameNode高可用运行在集群中运行两个NameNode，一个是active NameNode，一个是StandbyNameNode。两个NameNode避免了集群出现单点故障的风险。有了HA，意味着你的集群中的一个NameNode不可用了，整个集群仍然可用。

Apache Zookeeper

NameNode HA 需要用到Zookeeper组件来实现。

潜在的不平衡数据(数据倾斜)

 

数据处理层的资源调度组件YARN

简而言之，YARN是一个框架，用来管理Hadoop集群中运行的分布式应用程序的，用来管理集群中所有的资源，除了支持MapReducev2程序，支持其他分布式处理框架如Impala，Spark等程序的运行调度。所有运行在Hadoop环境中的应用程序，都是用YARN来执行相应的工作。

YARN是Hadoop处理层，包括一个资源管理器和一个job调度器。YARN实现了多个处理框架同时运行在同一个Hadoop集群。如：

l 批处理框架—--Spark或MapReduce

l 交互式SQL框架---Impala

l 高级分析框架----Spark SQL,Spark ML,Impala

l 流处理框架----Spark Streaming

YARN架构

YARN依赖于一个集群范围的ResourceManager来作为Hadoop集群上运行了各种应用的资源仲裁员。ResourceManager与DataNode节点上的NodeManager相互配合工作，两者组成了一个数据计算框架。

运行在YARN上面的每一个Application都有一个ApplicationMaster与之关联。ApplicationMaster的主要作用是与ResourceManager谈判，获取计算资源，与NodeManagers配合，来执行Application中的tasks。

在你深入了解YARN本身的体系结构之前,有必要先了解以下术语：

Client：一个提交YARNjob到集群的应用程序。有时候一个Client是一个客户端程序所运行的网关机器。

JOB，也叫Application，包含一个或多个tasks。如：一个MapReduce JOB包括Mapper、reducer(可选)以及输入列表。

当运行一个MapReduceJOB，一个task可以是Mapper task，也可以是reducer Task。

每个Mapper和reducertask都运行在独立的container中，container的大小由管理员配置。Job决定了Mapper和reducer的数量。

图2.6展示了YARN的高层架构以及相关核心组件之间相互配合来处理数据。ResourceManager、NodeManager、ApplicationMaster是yarn工作中用到的关键角色。YARN客户端创建Application并允许他们。RM负责资源调度和资源管理。NodeManager进程负责运行和管理container。每一个job只有一个AM。AM由RM创建，负责请求job运行需要的container。Container是资源的抽象，包括RAM和CPU。

YARN container---YARN如何分配资源

YARN使用container来运行程序，container是一个逻辑结构，代表了特定数量的内存和CPU。例如，一个container可以代表2GB内存和2个CPU core。所有的YARN应用程序的task都运行在container中，每一个Hadoop job包含多个task，每个task运行在自己的container中。当task开始运行时，一个container就形成了，在task完成时，container被杀死，其资源被回收供其他task使用。

Container的配置要综合考虑可用资源和应用处理的需要。Container有默认配置值，你可以更改他们以适合你自己的资源和应用程序。

RM为每一个Application分配资源container。NM管理这些container的生命周期，RM调度这些container。

每一个YARN Application可以有一个或者多个container。默认情况下，每一个container有一定数量的内存，你可以配置它。对map和reduce任务习惯使用内存大小从1 - 4 GB不等的container。作为管理员,您真的不能指定甚至预测一个container用于哪个job,这完全由应用程序层管理。

举个例子，如果一个job分配了200个container，每一个container执行一个task，这意味着这些container将被分布在各个集群节点上，每一个节点会运行一组container。当一个map或reducetask完成了，container会中断，被回收，如果有挂起的map或者reduce task，新的container被启用来重新运行挂起的task。Application相关的AM负责在分配的container中运行job。

在Hadoop集群中，你可以同时运行的YARN Application的数量以及task的数量有container的数量限制。Container的数量由分配给YARN的内存总量和CPU总 核数决定。

ResourceManager

每个集群中只有一个RM，做如下工作：

l 初始化所有YARN应用的启动；

l 管理job的调度和执行；

l 在所有的DataNode上面分配全局资源；

RM由两个关键的组件组成：Scheduler和ApplicationManager(注意：不是ApplicationMaster)。Scheduler为运行的Application分配资源，受限于资源数量和队列。为了分配资源，scheduler使用资源container。ApplicationManager接收客户端提交的job请求，并启动第一个container，用于新AM的执行，同时在AM的container失败时重启。

下面是RM的主要功能：

为Application创建第一个container，这个container用于运行此Application的AM；

l 跟踪NM发送的心跳信息；进而管理DataNodes；

l 运行scheduler进行集群资源调度；

l 管理集群级别的安全；

l 管理AM的资源请求；

l 监控AM的状态并在必要的时候重启AM container；

l 回收container

Scheduler组件的调度算法执行以下功能：

n 使用户以一种可预期的方式共享集群，可以预设调度策略；

n 支持用户负责的多个sla的实现；

n 可以使短任务优先运行，即使他们在长任务之后启动；

n   当有不同大小的JOB一起运行时，减少JOB的延迟；

 

NodeManager

在Hadoop2集群中每一个DataNode节点上都运行了一个NodeManager后台进程，负责执行相应的YARN的功能。DataNode节点上也运行了一个DataNode后台进程，负责执行相应的HDFS功能。每个节点上的NodeManager执行如下功能：

l 通过心跳信息和container状态通知信息与RM交互；

l 注册并启动Application进程；

l 按ApplicationManager的指令，运行AM和其他的应用资源container；

l 监视Applicationcontainer的生命周期；

l 监控，管理和提供container资源消耗相关的信息；

l 跟踪DataNodes的健康状态

l 监控container资源使用和杀死失控的container

l 日志管理，收集job日志存储到HDFS上；

l 为yarnApplication提供辅助服务。用于MapReduce 框架的shuffle和sort操作中；

l 管理节点级别的安全

ApplicationMaster

对于一个Application而言，只有一个AM。AM的主要工作：

l 管理task的调度和执行；

l 为Applicationtask分配本地资源；

与RM和NM不同，AM是应用相关的，负责Application的资源请求。RM和NM需要长时运行，AM只有在Application运行时才存在。

AM如何与RM交互获取资源的？