Hadoop源代码点滴-系统结构（HDFS+YARN）

Hadoop建立起HDFS和YARN两个字系统，前者是文件系统，管数据存储；后者是计算框架，管数据处理。

如果只有HDFS而没有YARN，那么Hadoop集群可以被用作容错哦的文件服务器，别的就没有什么应用可言了。虽然HDFS是个分布式的文件系统，但是对服务器的用户来说那只是他的内部实现，从外部看与一般的Raid结构的文件服务器并无多大的区别。

从功能和层次上看，YARN是HDFS的用户，是HDFS的上一层，YARN的功能是建立在HDFS基础上的，HDFS提供数据供YARN字系统处理和计算。

 

YARN代表中一种新的计算模式，在传统的“客户/服务”模式中，计算在哪里，就把数据（通过网络）搬运到哪里。而YARN所实现的模式却是“数据在哪里，计算就在哪里进行”YARN子系统里的计算就好像溶化在HDFS所在的集群中一样。传统的“客户/服务”模式是哑铃状的集中存储加集中计算，而Hadoop的模式是“溶化”式的、“打成一片”的分布存储家分布计算。显然，对于大数据处理，后者的效率（从而其价值）比前者要大得多。

 

这两个子系统都是分布式的，但都是主从式分布。HDFS、YARN都有主节点、从节点。客户只能跟YARN的主系统打交道，而不直接跟任何一个从节点打交道；即使他正在某个从节点上，也只是借由这个从节点跟主节点打交道。同样，如果用户要将一个文件复制到HDFS中也首先要跟HDFS主节点打交道，而后在主节点的安排和指引下将文件内容传递到某些从节点上。

 

YARN和HDFS是同一个集群上的两个子系统，但和并不意味着把集群中的节点机器划分为两个集合，分别用于两个字系统；而是集群中 的每个节点及其都扮演着两种角色，打折两份工。所以，当我们说某台节点是HDFS的话一个从节点时，他也许（多半）又是YARN的从节点，但也不排除恰巧是YARN的主节点的可能。

 

HDFS主从节点分别是NameNode的JVM进程、DataNode的JVM进程。

YARN主从节点分别是ResourceManager的JVM进程、NodeManager的JVM进程。

假定某个节点是从节点，则其上可能运行着NodeManager的JVM、DataNode的JVM、Mapper的JVM。

 

用户眼中的Hadoop，更多的是指YARN。

 

在早期的Hadoop系统中（2.0之前的版本），在主节点上扮演“中央政府”角色的是JobTracker的JVM进程，子节点运行的是TaskTracker，TaskTracker负责将作用（如mapper、Reducer）的JVM进程投入运行。JobTracker负责跟踪TaskTracker的运行，TaskTracker负责跟踪Mapper、Reducer的运行。

 

主节点上的RM掌管着集群内各个节点上资源的分配使用，记录着个节点的资源时候情况。这里的所谓的资源就是存储和CPU。存储其实质虚存空间，CPU也是指“虚核”，即VCore。什么叫VCore呢，一个进程，一个线程，一台JVM都可以占用一个VCore，但是一个线程绝对不会需要两个VCore。

 

一个作业被提交到RM，其申请材料首先会被保存起来，排入一个等待调度的队列。然后RM通过一个YARN调度模块进行调度，首先在它的账本中选出一个具有足够空闲的节点，让其担任“项目组长”的角色，并将一个操作系统层面的Shell命令行连同分配的资源配额等信息打包作为一个容器发送给这个节点，使其就地启动一个进程作为这个作业的“应用主管”，即Application Master,缩写为AM，这就好比“中央”（主节点）在收到作业请求后就立项（排队调度），并指定一个“地方政府”（子节点）作为该项目的牵头单位，在当地成立一个项目组，组长的角色成为AM（一个JVM进程）。

注意，这里所的是AM，而不是“Job Master"。从从前的JobTracker不同，现在主节点上的RM已经把视野从“作业”扩展到了“应用”，意思是可以在YARN框架中运行的不再限于原来的Java作业，也可以是普通的任何“应用”，可以不是Java类，还可以不是MapReduce。

此外，交由“牵头单位”用来启动的AM进程的shell命令也并非固定不变的，而是取决于所提交的具体应用。

所以，AM不限于java，Task也不限于java。

AM是一个独立的进程，独立的JVM，而不是与当地NodeManager在一个模块中，与NodeManager不在同一个JVM上。

 

 一个应用一旦有了AM，就开始分析，如分解成16个Mapper和1个Reducer，那么至少再需要17个容器（不算AM本身所占的容器），即17个进程，如果完成任务的是java，即17个JVM进程。17个容器是要想RM申请的，AM无权自行发放，所以AM需要就具体应用所含的任务逐一向RM申请容器，申请通过后，RM将容器发送给AM（而不是直接发送给指派的节点）。

AM得到RM分配下来的容器之后，就要与该容器所指派的节点联系，将容器转发给这个节点，以“发动launch”这个容器所包含的任务在目标节点上运行。指定的节点拿到这个任务后，启动一个进程来运行这个任务。

 

为什么要把容器中的任务作为进程运行，（对于java）而不是放在NodeManager（jvm）中作为一个模块来运行呢？这里有几个原因。1、安全考虑，防止Task的Bug把整个NodeManager拖垮。2、灵活性的考虑，Task可能不是java体系的，肯呢个是c++、shell。3、另外一个NodeMange可能承担多个应用的任务，如果不把task作为独立的进程，就会给管理带来困难。

 

发动了容器所含的任务在所指派节点上运行之后，AM和RM并非就袖手旁观，而是通过心跳密切注视和管理者这些任务的运行，必要时kill