关于Strom on Yarn的问题

问题导读：

为什么要将storm运行在yarn上？

如何将storm运行在yarn上？
Strom on yarn需要注意哪些问题？






   1. 背景知识

（1）Storm：一个实时计算框架，与MapReduce离线计算框架互补，分别用于解决不同场景下的问题，Storm的官方网站是：http://storm-project.net/，如果想快速了解，推荐阅读淘宝的这篇文章：总体认识storm包括概念，场景，组成。

（2）YARN：YARN是Hadoop 2.0中新引入的资源管理系统，可看做Hadoop操作系统中的资源管理组件，所有应用程序和框架，比如MapReduce、Storm和Spark等，均可运行在YARN之上，关于YARN，可阅读 yarn详解。

（3）Storm On YARN：尝试将Storm运行在YARN上，这将来众多好处，具体本文将详细介绍。Storm On YARN最有名是Yahoo！的开源实现，具体参考：Storm On YARN。将Storm运行在YARN上并不是一件难事，但重要的是，它给我们开了一扇窗，我们可通过该项目实现HBaseOn YARN, Spark On YARN，Kafka On YARN等有意义的工作，具体参考这篇文章：汇总运行在Hadoop YARN上的开源系统。

2. Storm On YARN带来的好处

相比于将Storm部署到一个独立的集群中，Storm On YARN带来的好处很多，主要有以下几个：

(1)  弹性计算资源。 将Storm运行到YARN上后，Storm可与其他应用程序（比如MapReduce批处理应用程序）共享整个集群中的资源，这样，当Storm负载骤增时，可动态为它增加计算资源，而当负载减小时，可释放部分资源，从而将这些资源暂时分配给负载更重的批处理应用程序。

(2) 共享底层存储。 Storm可与运行在YARN上的其他框架共享底层的一个HDFS存储系统，可避免多个集群带来的维护成本，同时避免数据跨集群拷贝带来的网络开销和时间延迟。

(3)  支持多版本。可同时将多个Storm版本运行YARN上，避免一个版本一个集群带来的维护成本。

3. Storm On YARN架构

   通常而言，需要开发两个组件，分别是客户端和ApplicationMaster，其中，客户端的主要作用是将应用程序提交到YARN上，并与YARN和ApplicationMaster交互，完成用户发送的一些指令；而ApplicationMaster则负责向YARN申请资源，并与NodeManager通信，以启动任务。

为了不修改Storm任何源代码的情况下，让Storm运行在YARN上，最简单的实现方法是将Storm的各个服务组件（包括Nimbus和Supervisor），作为单独的任务运行在YARN上，而Zookeeper则作为一个公共的服务运行在YARN集群之外的几个节点上。

当前比较有名的“StormOn YARN”，它基本实现了上述描述的功能，下面具体进行说明：

（1） YARN-Storm Client

提供了一系列Shell命令供用户控制YARN上的Storm服务，比如构建一个Storm集群命令如下：

storm-yarn launch <storm-yarn-config>

Shell命令	参数含义	说明
setStormConfig	重置storm集群配置	整个集群将重新启动
getStormConfig	获取当前storm集群配置	所有配置数据将以json数据返回
addSupervisors	增加supervisor个数	ApplicationMaster向ResourceManager申请资源 以启动新增的supervisor
startNimbus/stopNimbus	启动/停止Nimbus服务	Nimbus服务运行在ApplicationMaster中
startUI/stopUI	停止或启动UI服务	webUI服务运行在ApplicationMaster中
startSupervisors/ stopSupervisors	启动或停止所有Supervisors服务	Supervisor服务运行在ApplicationMaster向ResourceManager申请的Container中
shutdown	销毁整个storm集群	所有服务将被杀死，资源将归还给ResourceManager

其中，<storm-yarn-config>是Storm配置信息，包括启动的Supervisor个数、Storm ApplicationMaster占用的内存等。

启动Storm之后，用户可通过以下命令控制Storm：

storm-yarn [command] –appId [appId] –output[file] [–supervisors [n]]

其中，Command为具体命令，具体见下表，参数“-appId”为启动的Storm的应用程序Id，“-supervisors”为需增加的Supervisor服务个数，该参数只对命令“addSupervisors”有效。

结合使用startNimbus/stopNimbus、startUI/stopUI和startSupervisors/ stopSupervisors等命令，可完成对Storm集群的升级。

（2） YARN-Storm ApplicationMaster

Storm ApplicationMaster初始化时，将在同一个Container中启动Storm Nimbus和Storm Web UI两个服务，然后根据待启动的Supervisor数目向ResourceManager申请资源，在目前实现中，ApplicationMaster将请求一个节点上所有资源然后启动Supervisor服务，也就是说，当前Supervisor将独占节点而不会与其他服务共享节点资源，这种情况下可避免其他服务对Storm集群的干扰。

除了运行StormNimbus和Web UI外，Storm ApplicationMaster还会启动一个Thrift Server以处理来自YARN-Storm Client端的各种请求，在此不再赘述。

4. 当前Storm On YARN存在的问题

由于YARN本身的不完善，导致Storm On YARN设计存在诸多缺陷，以下是几个典型问题：

（1）难以将所有Storm服务运行在相邻的节点上，比如同一个机架上，这是由于YARN自身不支持资源组调度，只能实现指定一个rack，然后增量获取资源，以期望所有资源来自这个rack，但是当该rack空闲资源不足时，YARN也无能为力。

（2）由于Nimbus服务运行在ApplicationMaster上，而一旦ApplicationMaster失败后，YARN会将它运行在另外一个节点上，这意味着Nimbus服务可能神不知鬼不觉的在另一个节点上启动了，这给用户使用带来诸多不便，YARN需要提供一个ApplicationMaster或Nimbus位置获取服务，客户端直接通过该服务获取Nimbus位置即可。社区目前正在推荐一个基于Zookeeper的方案，你可以使用最新开源项目Weave完成该功能。

（3）NodeManager本身无法支持动态升级，这意味着，如果NodeManager升级，则它上面运行的服务将全部被杀死，这将给运行在YARN上的服务带来诸多不稳定因素。如果能够将更广泛的服务，比如Webserver、Mysql等，运行在YARN上，需要让NodeManager支持动态升级，像YARN的同质项目Mesos那样。

   

楼主，您好，请问下，我写了一个wordcount的例子，放在集群上面跑，集群是5个节点，输出结果写入到HDFS上面,写过写到HDFS上面的数据是5份，而且貌似是一个节点一份，请问下楼主如何才能实现分布式呢？是不是还需要做其他的设置？