Hadoop中Yarn架构是什么样的

这篇文章主要介绍Hadoop中Yarn架构是什么样的,文中介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们一定要看完!

先来看看Yarn平台的基本架构:

    Hadoop中Yarn架构是什么样的

    在Yarn的结构中,把原来JobTracker管的事儿(资源管理、任务调度)拆开了,资源调度让ResourceManager干,任务调度让ApplicationMaster管,这样的好处就是能够让各个模块各司其职,专一干一件事,就好比一个大领导每天如果不专心管理管队,老跑去敲代码,最后这个团队必然存在问题。言归正传,既然要了解Yarn的架构,在这里有必要先解释一下用户提交一个任务都走了哪些流程:

Hadoop中Yarn架构是什么样的

    NodeManager启动的时候,会向ResourceManager注册自己的内存、CPU使用率等资源信息,供NodeManager调度。

    2. ApplicationMaster

    ApplicationMaster 负责管理应用程序的整个生命周期,每个应用程序都对应一个AM,主要功能有:

    (1) 与RM的调度器通讯,协商管理资源分配。

    (2) 与NM合作,在合适的容器中运行对应的task,并监控这些task执行。

    (3) 如果container出现故障,AM会重新向调度器申请资源。

    (4) 计算应用程序所需的资源量,并转化成调度器可识别的协议。

    (5) AM出现故障后,ASM会重启它,而由AM自己从之前保存的应用程序执行状态中恢复应用程序。 

    3. NodeManager

    NodeManager替代了Hadoop v1版本中的TaskTracker,每个节点都会有一个NM,主要功能有:

    (1) 为应用程序启动容器,同时确保申请的容器使用的资源不会超过节点上的总资源。

    (2) 为task构建容器环境,包括二进制可执行文件,jars等。

    (3) 为所在的节点提供了一个管理本地存储资源的简单服务,应用程序可以继续使用本地存储资源即使他没有从RM那申请。比如:MapReduce可以使用该服务程序存储map task的中间输出结果。

    一个NodeManager上面可以运行多个Container,Container之间的资源互相隔离,类似于虚拟机的多个系统一样,各自使用自己分配的资源。NodeManager会启动一个监控进行用来对运行在它上面的Container进行监控,当某个Container占用的资源超过约定的阈值后,NodeManager就会将其杀死。

    4. Container

    Container可以说是一个对Application使用资源描述的集合(或容器),可以看做一个可序列化的java对象,封装了一些描述信息,例如:

    message ContainerProto {

    optional ContainerIdProto id = 1; //container id

    optional NodeIdProto nodeId = 2; //container(资源)所在节点

    optional string node_http_address = 3;

    optional ResourceProto resource = 4; //container资源量

    optional PriorityProto priority = 5; //container优先级

    optional hadoop.common.TokenProto container_token = 6; //container token,用于安全认证

    }

    Container的一些基本概念和工作流程如下:

    (1) Container是YARN中资源的抽象,它封装了某个节点上一定量的资源(CPU和内存两类资源)。它跟Linux Container没有任何关系,仅仅是YARN提出的一个概念(从实现上看,可看做一个可序列化/反序列化的Java类)。

    (2) Container由ApplicationMaster向ResourceManager申请的,由ResouceManager中的资源调度器异步分配给ApplicationMaster;
    (3) Container的运行是由ApplicationMaster向资源所在的NodeManager发起的,Container运行时需提供内部执行的任务命令(可以使任何命令,比如java、Python、C++进程启动命令均可)以及该命令执行所需的环境变量和外部资源(比如词典文件、可执行文件、jar包等)。

    另外,一个应用程序所需的Container分为两大类,如下:

    (1) 运行ApplicationMaster的Container:这是由ResourceManager(向内部的资源调度器)申请和启动的,用户提交应用程序时,可指定唯一的ApplicationMaster所需的资源;
    (2) 运行各类任务的Container:这是由ApplicationMaster向ResourceManager申请的,并由ApplicationMaster与NodeManager通信以启动之。

以上两类Container可能在任意节点上,它们的位置通常而言是随机的,即ApplicationMaster可能与它管理的任务运行在一个节点上。

    5. YARN平台的资源管理方案

    在YARN中,用户以队列的形式组织,每个用户可属于一个或多个队列,且只能向这些队列中提交application。每个队列被划分了一定比例的资源。
    YARN的资源分配过程是异步的,也就是说,资源调度器将资源分配给一个application后,不会立刻push给对应的ApplicaitonMaster,而是暂时放到一个缓冲区中,等待ApplicationMaster通过周期性的RPC函数主动来取,也就是说,采用了pull-based模型,而不是push-based模型,这个与MRv1是一致的。

    相比于MRv1中的资源调度器,尽管YANR的调度器也是插拔式的,但由于YARN采用了事件驱动的模型,因此编写起来更加复杂,难度也远远大于MRv1。
    同MRv1一样,YARN也自带了三种常用的调度器,分别是FIFO,Capacity Scheduler和Fair Scheduler,其中,第一个是默认的调度器,它属于批处理调度器,而后两个属于多租户调度器,它采用树形多队列的形式组织资源,更适合公司应用场景。需要注意的是,这三种调度器采用的算法与MRv1中的完全一致,只不过是根据YARN中资源调度器的对外接口重新实现了一遍,在此不再赘述。 

以上是“Hadoop中Yarn架构是什么样的”这篇文章的所有内容,感谢各位的阅读!希望分享的内容对大家有帮助,更多相关知识,欢迎关注行业资讯频道!