关于Storm 中Topology的并发度的理解

来自:http://blog.csdn.net/derekjiang/article/details/9040243

概念理解

原文中用了一张图来说明在一个storm cluster中,topology运行时的并发机制。

其实说白了,当一个topology在storm cluster中运行时,它的并发主要跟3个逻辑实体想过:worker,executor 和task

1. Worker 是运行在工作节点上面,被Supervisor守护进程创建的用来干活的进程。每个Worker对应于一个给定topology的全部执行任务的一个子集。反过来说,一个Worker里面不会运行属于不同的topology的执行任务。

2.

Executor可以理解成一个Worker进程中的工作线程。一个Executor中只能运行隶属于同一个component(spout/bolt)
的task。一个Worker进程中可以有一个或多个Executor线程。在默认情况下,一个Executor运行一个task。

3.

Task则是spout和bolt中具体要干的活了。一个Executor可以负责1个或多个task。每个component(spout/bolt)
的并发度就是这个component对应的task数量。同时,task也是各个节点之间进行grouping(partition)的单位。

并发度的配置

有多种方法可以进行并发度的配置,其优先级如下:

defaults.yaml < storm.yaml <
topology 私有配置 < component level(spout/bolt) 的私有配置

至于具体怎么配置,至今拷贝过来大家看看便知:

设置worker数量

设置executor数量

  • Description: 给指定component创建的executor数量
  • Configuration option: ?
  • How to set in your code (examples):

设置task数量

Here is an example code snippet to show these settings in practice:

topologyBuilder.setBolt("green-bolt", new GreenBolt(), 2)
               .setNumTasks(4)
               .shuffleGrouping(blue-spout);

一个运行时的topology的例子

怎么样在运行过程中修改一个topology的并发度

Storm支持在不restart topology的情况下,
动态的改变(增减)worker processes的数目和executors的数目, 称为rebalancing.

主要有两种方法可以rebalance一个topology:

  1. 使用Storm web UI 来 rebalance topology.
  2. 使用CLI 工具 rebalance topology,一个例子如下:
# Reconfigure the topology "mytopology" to use 5 worker processes,
# the spout "blue-spout" to use 3 executors and
# the bolt "yellow-bolt" to use 10 executors.

storm rebalance mytopology -n 5 -e blue-spout=3 -e yellow-bolt=10
时间: 2024-11-08 07:14:39

关于Storm 中Topology的并发度的理解的相关文章

Storm基本概念以及Topology的并发度

Spouts,流的源头 Spout是Storm里面特有的名词,Stream的源头,通常是从外部数据源读取tuples,并emit到topology Spout可以同时emit多个tupic stream,通过OutputFieldsDeclarer中的declareStream,method来定义 Spout需要实现RichSpout端口,最重要的方法是nextTuple,storm会不断调用接口从spout中取数据,同时需要注意的是Spout分为reliable or unreliable两种

[Storm] 并发度的理解

Tasks & executors relation Q1. However I'm a bit confused by the concept of "task". Is a task an running instance of the component(spout or bolt) ? An executor having multiple tasks actually is saying the same component is executed for multi

Twitter Storm中Topology的状态

Twitter Storm中Topology的状态 状态转换如下,Topology 的持久化状态包括: active, inactive, killed, rebalancing 四个状态. 代码上看到每种状态都可以转换成一些持久化 ( 写入到 zk 中的状态 ) 或者中间状态. Java代码 (defn state-transitions [nimbus storm-id status] {:active {:monitor (reassign-transition nimbus storm-

Storm并发度详解

工作进程(Worker Process) Worker是Spout/Bolt中运行具体处理逻辑的进程.拓扑跨一个或多个Worker进程执行.每个Worker进程是一个物理的JVM和拓扑执行所有任务的一个子集.例如,如果合并并行度的拓扑是300,已经分配50个Worker,然后每个Worker将执行6个任务,Storm会尝试在所有Worker上均匀的发布任务. 执行器(Executor) Executor称为物理线程,每个Worker可以包含多个Executor. 任务(Task) Task是具体

Storm并发度

并发度 一个Topology可以包含一个或多个worker(并行的跑在不同的machine上), 所以worker process就是执行一个topology的子集, 并且worker只能对应于一个top  ology 一个worker可用包含一个或多个executor, 每个component (spout或bolt)至少对应于一个executor, 所以可以说executor执行一个compenent的子集, 同时一个executor只能对应于一个component Task就是具体的处理逻

Storm并发度和Grouping方式

Storm并发度和Grouping方式 .note-content {font-family: "Helvetica Neue",Arial,"Hiragino Sans GB","STHeiti","Microsoft YaHei","WenQuanYi Micro Hei",SimSun,Song,sans-serif;} .note-content h2 {line-height: 1.6; colo

storm中worker、executor、task之间的关系

理清一下worker.executor.task.supervisor.nimbus.zk这几个之间的关系 先来看一张图 (图片来自:http://www.cnblogs.com/foreach-break/p/storm_worker_executor_spout_bolt_simbus_supervisor_mk-assignments.html) 首先从微观上来看:worker即进程,一个worker就是一个进程,进程里面包含一个或多个线程,一个线程就是一个executor,一个线程会处理

storm源码之理解Storm中Worker、Executor、Task关系【转】

[原]storm源码之理解Storm中Worker.Executor.Task关系 Storm在集群上运行一个Topology时,主要通过以下3个实体来完成Topology的执行工作:1. Worker(进程)2. Executor(线程)3. Task 下图简要描述了这3者之间的关系:                                                    1个worker进程执行的是1个topology的子集(注:不会出现1个worker为多个topology服

Storm中Spout使用注意事项小结

Storm中Spout用于读取并向计算拓扑中发送数据源,最近在调试一个topology时遇到了系统qps低,处理速度达不到要求的问题,经过排查后发现是由于对Spout的使用模式不当导致的多线程同步等待.这里罗列几点个人觉得编写Spout代码时需要特别注意的地方: 1. 最常用的模式是使用一个线程安全的queue,如BlockingQueue,spout主线程从queue中读取数据:另外的一个或多个线程负责从数据源(如各种消息中间件.db等)读取数据并放入queue中. 2. 如果不关心数据是否丢