Twitter Storm: 在生产集群上运行topology
发表于 2011 年 10 月 07 日 由 xumingming
作者: xumingming | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明
网址: http://xumingming.sinaapp.com/185/twitter-storm-在生产集群上运行topology/
本文翻译自: https://github.com/nathanmarz/storm/wiki/Running-topologies-on-a-production-cluster 。
在生产集群上运行topology跟本地模式差不多。下面是步骤:
1)定义topology(如果是java的话, 用TopologyBuilder)
2) 使用StormSubmitter来把topology提交到集群。StormSubmitter的参数有:topology的名字,topology的配置对象,以及topology本身。比如:
1 2 3 4 5 |
|
3) 创建一个包含你的程序代码以及你代码所依赖的依赖包的jar包(有关storm的jar包不用包括, 这些jar包会在工作节点上自动被添加到classpath里面去)。如果你使用maven, 那么插件:Maven Assembly Plugin可以帮你打包,只要把下面的配置加入你的pom.xml。
01 02 03 04 05 06 07 08 09 10 11 12 13 |
|
然后运行mvn assembly:assembly就可以打包了. 再说一下,不用包括storm相关的jar包,它们会自动加到classpath里面。
4)用storm客户端去提交jar包:
1 |
|
storm jar 会把代码提交到集群并且配置StormSubmitter类以让它和正确的集群进行通信。在这个例子里面,上传jar包之后storm jar命令会调用org.me.MyTopology的main函数,参数是 arg1, arg2, arg3。关于如何配置你的storm客户端去和storm集群进行通信可以看下配置storm开发环境。
常见配置
有很多topology级的配置可以设。这里有关于所有配置的清单, 以”TOPOLOGY”打头的配置是topology级别的配置,可以覆盖全局级别的配置。下面是一些比较常见的:
1)Config.TOPOLOGY_WORKERS: 这个设置用多少个工作进程来执行这个topology。比如,如果你把它设置成25, 那么集群里面一共会有25个java进程来执行这个topology的所有task。如果你的这个topology里面所有组件加起来一共有150的并行度,那么每个进程里面会有6个线程(150 / 25 = 6)。
2)Config.TOPOLOGY_ACKERS: 这个配置设置acker线程的数目。Ackers是Storm的可靠性API的一部分,关于storm的可靠性API可以看下:Twitter Storm如何保证消息不丢失。
3)Config.TOPOLOGY_MAX_SPOUT_PENDING: 这个设置一个spout task上面最多有多少个没有处理的tuple(没有ack/failed)回复, 我们推荐你设置这个配置,以防止tuple队列爆掉。
4)Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS: 这个配置storm的tuple的超时时间 – 超过这个时间的tuple被认为处理失败了。这个设置的默认设置是30秒,对于大多数的topology都已经足够了。关于storm的可靠性API可以看看Twitter Storm如何保证消息不丢失。
5)Config.TOPOLOGY_SERIALIZATIONS: 为了在你的tuple里面使用自定义类型,你可以用这个配置注册自定义serializer。
终止一个topology
要终止一个topology, 执行:
1 |
|
其中{stormname}是提交topology给storm集群的时候指定的名字。
storm不会马上终止topology。相反,它会先终止所有的spout,让它们不再发射任何新的tuple, storm会等Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS秒之后才杀掉所有的工作进程。这会给topology足够的时间来完成所有我们执行storm kill命令的时候还没完成的tuple。
更新一个运行中的topology
为了更新一个正在运行的topology, 唯一的选择是杀掉正在运行的topology然后重新提交一个新的。一个计划中的命令是实现一个storm swap命令来运行时更新topology, 并且保证前后两个topology不会同时在运行,同时保证替换所造成的“停机”时间最少。
监控topology
监控topology的最好的方法是使用Storm UI。Storm UI提供有关task里面发生的错误以及topology里面每个组件的吞吐量和性能方面的统计信息。同时你可以看看集群里面工作机器上面的日志。