Storm系列之一——Storm Topology并发

1、是什么构成一个可运行的topology?

worker processes(worker进程),executors(线程)和tasks。

一台Storm集群里面的机器可能运行一个或多个worker进程,一个worker进程运行一个特定topology的executors。

一个worker进程可能运行一个或多个executors。每个executor是一个线程。一个executor运行同一个spout或者bolt的一个或多个task。

一个task完成具体的数据处理。

一个worker进程执行一个topology的子集。一个worker进程属于一个指定topology并且可以运行属于一个topology的一个或多个executors。一个topology由很多这样的worker进程运行在Storm集群的很多机器上。

一个task完成具体的数据处理—一个组件的任务数在整个topology的生命周期内是不变的,但是一个组件的executors数量在topology的生命周期内是可以变的。#threads <= #tasks。默认情况下,tasks的数量被设置成与executors的数量相等。 Storm将会在每个executor里面运行一个task。

2、配置一个topology的parallelism。

Storm里面的"parallelism"指parallelism hint, 它代表一个组件的executor的初始数量。

worker进程的数量:一个topology拥有的worker进程的数量。配置文件里面设置:TOPOLOGY_WORKERS  代码里面设置:Config#setNumWorkers

executors的数量:每个组件拥有的executors数量。 代码里面配置:TopologyBuilder#setSpout()   TopologyBuilder#setBolt()                             parallelism_hint指出一个组件的初始executors的数量。

tasks的数量:每个组件创建多少task。  配置文件里面配置:TOPOLOGY_TASKS       代码里面配置:ConponentConfigurationDeclare#setNumTasks()。

另外,TOPOLOGY_MAX_TASKS_PARALLELISM限定了单个组件可以产生的executors的最大数量。

3、改变一个topology的parallelism。

rebalanceing:这是Storm的一个漂亮的特性。worker进程的数量和executor的数量可以动态增加或减少,而不需要重启集群或者重启topology。

两种方式:1、用Storm web UI       2、CLI工具

## 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-10-07 16:01:07

Storm系列之一——Storm Topology并发的相关文章

【Twitter Storm系列】Storm环境配置及吞吐量测试调优--个人理解

1.硬件配置信息 6台服务器,2个CPU,96G,6核,24线程 2.集群信息 Storm集群:1个nimbus,6个supervisor nimbus:192.168.7.127 supervisor: 192.168.7.128 192.168.7.129 192.168.7.130 192.168.7.131 192.168.7.132 192.168.7.133 Zookeeper集群: 3个节点 192.168.7.127:2181, 192.168.7.128:2181, 192.1

Storm系列(一):搭建dotNet开发Storm拓扑的环境

上篇博客比较了目前流行的计算框架特性,如果你是 Java 开发者,那么根据业务场景选择即可:但是如果你是 .Net 开发者,那么三者都不能拿来即用,至少在这篇文章出现之前是如此.基于上篇文章的比较发现,Storm 应该是对多语言支持比较好的框架了,但即便如此,官方也没有提供 .Net 的适配器,网上也找不到第三方的开源库.So,Storm.Net.Adapter 出现了,一个使用 Csharp 开发的 针对 Apache Storm 的适配器!项目由本人开发,按照Apache License,

Storm 系列(三)Storm 集群部署和配置

Storm 系列(三)Storm 集群部署和配置 本章中主要介绍了 Storm 的部署过程以及相关的配置信息.通过本章内容,帮助读者从零开始搭建一个 Storm 集群.相关的过程和主要的配置选项是 Storm 的运维人员需要重点关注的,对部署和配置选项不感兴趣的读者,可以跳过本章. 在开始 Storm 之旅前,我们先看一下 Storm 部署和配置的相关信息,并提交一个 Topology,了解 Storm 的基本原理.Storm 的部署模式包括单机和集群环境,同时在向 Storm 环境中提交 To

Storm系列二: Storm拓扑设计

Storm系列二: Storm拓扑设计 在本篇中,我们就来根据一个案例,看看如何去设计一个拓扑, 如何分解问题以适应Storm架构,同时对Storm拓扑内部的并行机制会有一个基本的了解. 本章代码都在: [email protected]:zyzdisciple/storm_study.git 项目下的 user_behavior包下. 问题案例 有这样一种场景,在前端存在会话,我们会不断收到来自前端的消息,消息包含消息的发送时间,消息内容,结束标识, 消息的发送者, SessionId等其他信

Storm系列三: Storm消息可靠性保障

Storm系列三: Storm消息可靠性保障 在上一篇 Storm系列二: Storm拓扑设计 中我们已经设计了一个稍微复杂一点的拓扑. 而本篇就是在上一篇的基础上再做出一定的调整. 在这里先大概提一下上一篇的业务逻辑, 我们会不断收到来自前端的消息,消息包含消息的发送时间,消息内容,结束标识, 消息的发送者, SessionId等其他信息, 我们需要做的事情是当接收到消息之后,根据SessionId判断是否属于同一消息, 如果是的话将内容拼接, 如果结束标识为 true, 表示会话已结束,则存

Storm 系列(五)—— Storm 编程模型详解

一.简介 下图为 Strom 的运行流程图,在开发 Storm 流处理程序时,我们需要采用内置或自定义实现 spout(数据源) 和 bolt(处理单元),并通过 TopologyBuilder 将它们之间进行关联,形成 Topology. 二.IComponent接口 IComponent 接口定义了 Topology 中所有组件 (spout/bolt) 的公共方法,自定义的 spout 或 bolt 必须直接或间接实现这个接口. public interface IComponent ex

Storm 系列(六)—— Storm 项目三种打包方式对比分析

一.简介 在将 Storm Topology 提交到服务器集群运行时,需要先将项目进行打包.本文主要对比分析各种打包方式,并将打包过程中需要注意的事项进行说明.主要打包方式有以下三种: 第一种:不加任何插件,直接使用 mvn package 打包: 第二种:使用 maven-assembly-plugin 插件进行打包: 第三种:使用 maven-shade-plugin 进行打包. 以下分别进行详细的说明. 二.mvn package 2.1 mvn package的局限 不在 POM 中配置

Storm系列(二)系统结构及重要概念

在Storm的集群里面有两种节点:控制节点和工作节点,控制节点上面运行Nimbus进程,Nimbus负责在集群里面分配计算任务,并且监控状态.每一个工作节点上面运行Supervisor进程,Supervisor负责监听从Nimbus分配给它执行的任务,Nimbus和Supervisor之间的所有协调工作都是通过Zookeeper集群完成.   Storm集群结构图     Topology 一个实时计算应用程序的逻辑在storm里面被封装到topology对象里面称为计算拓补.storm里面的t

Storm入门(Storm程序)

Storm简介 Storm是一个分布式实时流式框架,大多应用于以下场景:实时分析.在线机器学习.流式计算.分布式RPC ETL(BL分析)等等.同类型的框架有hadoop和spark.hadoop侧重于海量数据的离线计算,spark则更擅长实时迭代计算.要注意的是,storm并不直接处理数据,而是把我们的业务程序(逻辑)放在很多服务器上并发运行,待处理消息被分散到很多服务器上并发处理,以此扩展程序的负载能力. Direction 简单来说的话,Storm框架包含两个部分.一个是Storm程序,一