Storm概念、原理详解及其应用(二)Storm Cluster

前述:

本章内容借鉴官文和一些资料,有问题的地方希望大家指出。同样,内容中不会给出部署Storm集群的方法和步骤,因为部署只是我们使用它的基础,个人认为集群部署维护属于运维层面;也不会详解Command line client;更不会贴出yaml配置文件。所以不包含上述内容,希望不会浪费到大家时间。


那文章内容会有什么呢?

在完成上述工作以后,却不理解Storm是如何通过storm.yaml这个文件进行工作,集群之间是如何运行、每个守护进程都做了什么、代码怎么分配到每个节点、Storm的代码逻辑怎么写才会符合Stream、如何Storm集成到其他系统中、甚至想要重编译Storm;通过了解以下内容,可以理解并解决刚才的问题,举一反三。

当然这个必须自己部署一遍,熟悉过程,因为后期的topology结构定义可以不用写入代码内,而走flux配置来完成。这意味这什么呢?


概念:
特点介绍:
Storm 采用云计算框架中最实用的master/slave结构,静态设置。
主节点为nimbus,半容错;从节点supervisor;中间关系通过Zookeeper维护。
半容错:由于Nimbus不参与数据处理过程,且topology不会自动停止。所以只能对topology初始化、任务分发和监控,不会影响任务处理过程。但如果supervisor挂掉,nimbus不能再重新指派任务。

当然,可以使用HA nimbus,这个我们以后谈###############。

进程组件:

如果大家还记得上一章的Storm框架吗?本章就是围绕该架构来分析机理,首先,来看下每个进程组件的功能。

Nimbus:
Nimbus守护进程主要负责管理(类似于namenode+ResourceManager,因为Storm不需要hdfs),协调+监控 = topology的发布、任务指派、失败重新指派等。
Nimbus会记录所有supervisor节点的状态和分配给它们的task;如果supervisor没有heartbeat或不可达,它会将故障supervisor中的task重新分配到其他节点。

Supervisor:
Supervisor守护进程等待nimbus分配任务后,生成并监控workers(JVM进程)的执行。
Supervisor和worker都是运行在不同的JVM进程上(一个节点上可以运行多个JVM,每个JVM为一个进程,即worker),worker失败是由supervisor重启。
保障传输机制:当打开了可靠传输选项,传输到故障节点的tuple将不会收到应答确认,spout会因为超时而重新发射原始tuple(问题5),直到topology从故障中回复开始正常处理数据。

Zookeeper:
Storm 主要使用ZooKeeper 来协调一个集群中的状态信息,比如任务的分配情况, worker 的状态, supervisor 之间的 nimbus 的拓扑度量。 nimbus 和supervisor节点之间的通信主要是结合 ZooKeeper 的状态变更通知和监控通知来处理的(Zookeeper的在集群中最重要的应用!)

Thrift:
对于重量级 的数据传输操作,比如发布topology 时传输jar 包,Storm 依赖Thirft 进行通信。(在以后的源码分析中会有详解)


在理解每个守护进程后,我们来看看他们之间是如何工作的。


集群运行机制:

Storm的集群主要由三部分组成:nimbus、zookeeper、supervisor。

master是不会与每个slaver直接通信,他们之间的交流是通过zk,其中包括:代码下载、心跳机制、任务分配、同步集群等等。

这里简单提一下zk的主要功能:1、同步少量数据。2、有监听触发机制。

感兴趣的朋友可以自行学习zk,这里默认大家使用过zk。


nimbus的元数据存储在zk中,由于supervisor并不会直接与其通信,所以才会有半容错的存在。

1、实际上,nimbus在获取代码后运行代码,解析配置和topology结构,得到需要分配多少worker、executor、task等等,topology运行时需要的资源。

2、把相关信息提交给zk。这里其实就是修改zk中的tree文件内容,至于zk中的Storm tree是什么样的接下来会讲到。

3、zk作为中间服务系统,会触发消息到对应的supervisor。

4、每个supervisor得到信息后,会根据信息分配资源,首先是worker的建立、开启多少个executor、提交对应的tasks。

至于并发度、并行度,这些在提交代码、配置时已经定义好了,不用多说


zookeeper:

    Storm在zookeeper中生成的树型目录结构如下图:


可以看出,根目录为/storm,其下的每一个叶子目录都是Storm存储元数据的地方。

下面分别介绍ZooKeeper中每项数据的具体含义:

/storm/workerbeats/<topology-id>/node-port:它存储由node和port指定的Worker的运行状态和一些统计信息,主要包括storm-id(也即topology-id)、当前Worker上所有Executor的统计信息(如发送的消息数目、接收的消息数目等)、当前Worker的启动时间以及最后一次更新这些信息的时间。在一个topology-id下面,可能有多个node-port节点。它的内容在运行过程中会被更新。

/storm/storms/<topology-id>:它存储Topology本身的信息,包括它的名字、启动时间、运行状态、要使用的Worker数目以及每个组件的并行度设置。它的内容在运行过程中是不变的。

/storm/assignments/<topology-id>:它存储了Nimbus为每个Topology分配的任务信息,包括该Topology在Nimbus机器本地的存储目录、被分配到的Supervisor机器到主机名的映射关系、每个Executor运行在哪个Worker上以及每个Executor的启动时间。该节点的数据在运行过程中会被更新。

/storm/supervisors/<supervisor-id>:它存储Supervisor机器本身的运行统计信息,主要包括最近一次更新时间、主机名、supervisor-id、已经使用的端口列表、所有的端口列表以及运行时间。该节点的数据在运行过程中也会被更新。

/storm/errors/<topology-id>/<component-id>/e<sequential-id>:它存储运行过程中每个组件上发生的错误信息。<sequential-id>是一个递增的序列号,每一个组件最多只会保留最近的10条错误信息。它的内容在运行过程中是不变的(但是有可能被删除)。

相关文章

相关标签/搜索