Storm yarn

名称缩写：RM（ResourceManager）,AM(ApplicationManager),NM(NodeManager),C(Client)

 

使用yarn场景

需同时采用多种计算平台

 

MR1——> MR2

JT,TT——>YARN,AM

 

设计改进：

资源管理和应用程序管理分离，以满足多计算平台同时运行

 

RM:

调度，应用程序管理（应用程序提交，启动AM等）

AM：

1，向RM申请资源

2，分发资源

3，与NM通信启动/停止任务

4，监控所有任务运行状态

 

YARN中的主要接口

ApplicationClientProtocol：Client通过该协议将应用程序提交到RM上,查询应用程序的运行状态或者杀死应用程序等功能

ApplicationMasterProtocol:AM使用该协议向RM注册，申请资源，获取各个任务运行情况等

ContainerManagementProtocol:AM使用该协议要求NM启动/撤销Container或者查询Container的运行状态

 

 

如果将一个新的应用程序运行在YARN上，需要编写两个组件

Client，AM

Client设计

1，Client从RM获取唯一的app_ID

2，Client将应用程序提交到RM上

AM设计

AM的编写流程包括两部分：AM—RM,AM—NM

AM-RM通信主要过程：注册，申请资源，应用执行完毕后报告完成

AM-NM通信主要过程：分发资源给其他的NM，启动NM内部的container，一旦一个container运行完成后，AM释放之

 

Storm  VS  Storm on yarn

Storm弊端：

1，资源无法动态分配（用户提交任务时，需要手动指定需要的资源数，而任务一旦提交，需要用户显示的Kill，否则任务永远运行，无法根据数据量的大小动态分配资源）

2，nimbus负责管理任务，分配资源和调度，此调度能力弱，无法考虑到当前CPU和内存的运行情况

瓶颈：受制于Zookeeper，Nimbus调度的瓶颈是单个集群的规模在超过300台之后无法线性扩展（解决：stormon yarn）

 

Storm on yarn：

好处：

1，共享底层存储，让storm访问基于hadoop的数据存储，

2，弹性计算资源，与其他应用程序共享集群资源，可以共享资源管理/调度

3，支持多版本，避免一个版本一个集群带来的维护问题

 

总体设计思路：

独立的AppMaster负责资源管理，Container做任务资源隔离，资源池做权限管理，增加各个计算模块的容灾机制，实现任务根据CPU,内存大小自动扩容和缩容

 

系统流程：

 

1，通过storm-YARN客户端将Topology提交到RM

2，Storm-YARN对每一个提交的Topology启动一个AppMaster，同时在AppMaster中启动对应storm集群的Nimbus和UI进程

3，根据Topology指定的Worker数目来确定需要申请的supervisor数目，通过AppMaster向YARN申请对应数目的Container

4，AppMaster拿到指定的Container资源在对应的机器上启动Supervisor进程，用户的Topology提交到Nimbus，整个任务提交的过程结束，后续的操作交给storm处理