Yarn 源代码分析

光荣复兴

贡献于2014-03-30

字数:3048 关键词: 分布式/云计算/大数据

Yarn源代码分析 自从大四下学期加入新蛋bigdata团队以来,一直利用业余时间学习hadoop生态系统的相关技术,学习的方式主要是跟踪业界大神的博客以及hadoop官方的文档,自己也利用公司淘汰下来的机器搭建了一个简单的hadoop集群来测试。当学习完系统架构后自然要去读hadoop源码,从源码层面了解hadoop的设计。对于hdfs,我主要看的是cdh3u1和cdh4.1.3的namenode实现,已经写过关于cdh3u1版的namenode源码分析以及namenode ha的QJM实现的文章,所以这里我主要yarn的源码分析,包括resourceManager和nodeManager。 一 ResourceManager 再yarn的源代码实现里,大量用到了生命周期模式,事件驱动模型和状态驱动模型(看源码也是一个学习设计模式在大型项目中是怎样应用的机会,不仅仅是单一的使用设计模式,还要学会设计模式的混合使用,从而写出优雅的代码)。Yarn里面所有要实现生命周期模式的组件都会去直接或间接地继承service类,还有一个compositeService类,它里面维护了一组service,所以通过这种组合模式resourcemanager里维护了一个service tree,resourcemanager自己继承自CompositeService作为root service,在resourcemanger里service的嵌套层次还不算太多,不过nodeManager里的service tree嵌套得可就有点多了,看一遍源码肯定是记不住了,我也是调试了几次才理清nodeManager的service tree的层次。要理解ResourceManager的行为,最简单直接的方法就是理解它管理的各个service的行为,所以下面我主要讲一些我认为的重要的service的行为。 1 AsyncDispatcher AsyncDispatcher是yarn里的事件分发服务,它内部维护了一 个事件队列和事件类型与事件处理器的映射,当前它只会启动一个线层来分发事件。当从事件队列里取出一个事件是会把事件分发给对应的事件处理器处理。一种事件类型并不一定只有一个事件处理器处理,它可以分发给多个事件处理器,因为AsyncDispatcher内有一个MultiListenerHandler类,MultiListenerHandler类维护着一组事件处理器。AsyncDispatcher内部还有一个通用的事件处理器类,该事件处理器的行为只是简单的将事件放到事件队列里罢了。在ResourceManager里几乎所有的外部rpc请求都会转化为事件放入事ResourceManager级别(还有一个schedule级别的事件队列)的事件队列里等待分发,在resourceManager类里有四个内部类分别代表application,applicationAttempt,schedule,node的事件分发器,AsyncDispatcher在取出事件后将它们交由对应的事件分发器处理。 2 ResourceScheduler ResourceManager主要负责集群的资源调度,yarn有三种资源调度策略:fifo,capacity和fair,默认使用的是Filo策略。对于三种策略具体是怎样做的,网上有许多讲解,这里我就不讲了;至于代码的实现我也没细看,所以这一部分略过。 3 ResourceTrackerService ResourceTrackerService是RM和NM之间的接口,职责是跟踪集群的资源,了解集群的资源使用情况 ,它提供了一个RPC服务。在集群运行的时候,nodemanager启动时是通过ResourceTrackerService向ResourceManager进行注册的,另外各个nodeManager会每隔一定时间(默认是1s)向ResourceManager发送心跳,心跳包含了在该node上可用的内存的大小等信息。 4 ClientRMService ClientRMService是客户端于ResourceManager之间的接口,它也是一个RPC服务(ResourceManager启动后一共会启4个RPC服务)。通过这个服务,客户端可以提交Application,查看Application的信息以及整个集群的状态信息等。 5 ApplicationMasterService ApplicationMasterService是RM和ApplicationMaster之间的通信接口,在yarn里面,一个应用程序是由一个ApplicationMaster管理的,应用的子任务运行在各个NM所管理的Container中,ApplicationMaster自己也是NM上运行的一个Container。ApplicationMasterService主要处理ApplicationMaster的注册以及完成和ApplicationAttempt的注册与注销等。 6 ApplicationMasterLauncher ApplicationMasterLauncher主要用于启动NM上的ApplicationMaster。另外它也是一个事件处理器,处理ApplicaitonMaster的launch和cleanup事件。当接收到事件时,它会构造用于launch或者cleanup的runnable对象放入内部维护的runnable队列里。会有一个守护线层不断的取出runnable交由 一个线层池去执行,在执行的过程中会通过RPC去访问NM的ContainerManager组件,因为ApplicationMaster是在NM上运行的一个Container。 7 AdminService AdminService也是一个Rpc服务,用于集群管理员对集群的一些管理操作,比如更新ACL等。 除了以上比较重要的service外,RM还有其他一些service,比如applicationToken和containerToken的管理等。 二 NodeManager NM的service tree层次比较复杂,下面主要讲一些NM的重要的Service组件。 1 AsyncDispatcher 与RM里的AsyncDispatcher作用类似,都是用来分发事件的。除了NM级别的AsyncDispatcher外,还有一个ContainerManager级别的AsyncDispatcher, ContainerManager作为NodeManager的子服务存在。 2 ContainerManager ContainerManager是NM里任务最重的一个service,管理本节点上的所有container。ContaninterManager作为一个Composite Service,包含了资源本地化,container监控,container启动停止以及其他自定义的一些辅助服务等。当然了,它内部的事件分发由它内部的AsyncDispatcher完成。ContainerManager也有一个RPC服务,RM要启动一个Container的时候就是通过调用这个RPC来处理的。 除了上述NM比较重要的服务外,当然NM还包含web服务,节点状态检查,以及定期清除cache和log,定期向RM发送心跳等必不可少的Service。

下载文档,方便阅读与编辑

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 5 金币 [ 分享文档获得金币 ]
0 人已下载

下载文档

相关文档