Storm基本概念

Storm基本概念

Storm是一个分布式的,可靠的,容错的数据流处理系统。
它会把工作任务 委托给不同类型的组件,每个组件负责处理一项简单特定的任务。
Storm集群的输入流由一个被称作spout(数据源)的组件管理,spout把数据传递给bolt(数据处理组件)，bolt要么把数据保存到某种存储器，要么把数据传递给其他的bolt。
一个Storm集群就是在一连串的bolt之间转换spout传过来的数据。

在Storm集群中有两种节点:控制节点(master node)和工作节点(worker node)
控制节点上面运行一个叫nimbus后台程序,它的作用类似Hadoop里面的JobTracker(2.X版本为ResoueceManager和ApplcationMaster)
Nimbus负责在集群里面分发代码，分配计算任务给机器，并且监控状态(负责资源分配和任务调度)。

Storm集群和Hadoop集群表面上看很相似,但是Hadoop上运行的是MapReduce jobs,而在Storm上运行的是拓扑(topology),这两者之间是非常不一样的。
一个关键的区别是:一个MapReduce job最终会结束，而一个topology永远会运行(除非你手动kill掉)。

每一个工作节点上面运行一个叫做Supervisor的节点。Supervisor会监听分配给它那台机器的工作,根据需要启动/关闭工作进程。每一个工作进程执行一个topology的一个子集:一个运行的topology由运行在很多机器上的很多工作进程组成。
Supervisor负责接受nimbus分配的任务,启动和停止属于自己管理的worker进程

Nimbus和Supervisor之间的所有协调工作都是通过Zookeeper集群完成。另外,Nimbus进程和Supervisor进程都是快速失败(fail-fast)和无状态的。
所有的状态要么在Zookeeper里面,要么就在本地磁盘上。这也就意味着你可以用kill -9来杀死Nimbus和Supervisor进程,然后再重启它们，就好像什么都没有发生过。这个设计使得Storm异常的稳定。

Storm各组件的基本概念

topology(拓扑)

Topology是Storm中运行的一个实时应用程序的名称。

Topology是spout和bolts组成的图,通过stream groupings 将图中的spouts和bolts连接起来。

一个topology会一直运行直到你手动kill掉,storm自动重新分配执行失败的任务,并且storm可以保证你不会有数据丢失。
如果一些机器意外停机它上面的所有任务会被转移到其他机器上。

Stream(流)

Stream是以tuple为基本单位组成的一条有向无界的数据流。

消息流Stream是storm里的关键抽象。一个消息流是一个没有边界的tuple序列,而这些tuple序列会以一种分布式的方式并行地创建和处理。

通过对stream中tuple序列中每个字段命名来定义stream。

Spouts(数据源)

消息源spout是storm里面一个topology里面的消息生产者。一般来说消息源会从一个外部源读取数据然后转换为topology内部的源数据tuple(消息)。

Spout可以是可靠的也可以是不可靠的。如果这个tuple没有被storm成功处理,可靠的消息源spouts可以重新发射一个tuple，但是不可靠的消息源spouts一旦发出一个tuple就不能重发了。

消息源可以发射多条消息流stream。使用OutputFieldsDeclarer.declareStream来定义多个stream，然后使用SpoutOutputCollector来发射指定的stream。

Spout类里面最重要的方法是nextTuple。要么发射一个新的tuple到topology里面或者简单的返回如果已经没有新的tuple。

Bolts(数据流处理组件)

所有的消息处理逻辑被封装在bolts里面。Bolts可以做很多事情:过滤，聚合,查询数据库等等。

Bolts可以简单的做消息流的传递。复杂的消息流处理往往需要很多步骤，从而也就需要经过很多bolts。

Bolts的主要方法是execute, 它以一个tuple作为输入，bolts使用OutputCollector来发射tuple，bolts必须要为它处理的每一个tuple调用OutputCollector的ack方法，以通知Storm这个tuple被处理完成了，从而通知这个tuple的发射者spouts。
一般的流程是： bolts处理一个输入tuple, 发射0个或者多个tuple, 然后调用ack通知storm自己已经处理过这个tuple了。storm提供了一个IBasicBolt会自动调用ack。

tuple(消息)

一次消息传递的基本单元,理解为一组消息就是一个tuple。

Stream groupings(数据流分组)

定义一个topology的其中一步是定义每个bolt接收什么样的流作为输入。stream groupings就是用来定义一个stream如果分配数据给bolts上面的多个tasks。

Storm里面有7种类型的stream grouping

  • Shuffle Grouping
    随机分组,随机派发stream里面的tuple，保证每个bolt接收到的tuple数据大致相同
  • Fields Grouping
    按字段分组,比如按userid来分组,具有同样userid的tuple会被分到相同的Bolts里的一个task，而不同的userid则会被分配到不同的bolts里的task。
  • All Grouping
    广播发送,对于每一个tuple，所有的bolts都会收到
  • Global Grouping
    全局分组,这个tuple被分配到storm中的一个bolt的其中一个task,再具体一点就是分配给id值最低的那个task。
  • Non Grouping
    不分组,这个分组的意思是说stream不关心到底谁会收到它的tuple。目前这种分组和Shuffle grouping是一样的效果,有一点不同的是storm会把这个bolt放到这个bolt的订阅者同一个线程里面去执行。
  • Direct Grouping
    接分组， 这是一种比较特别的分组方法，用这种分组意味着消息的发送者指定由消息接收者的哪个task处理这个消息。
    只有被声明为Direct Stream的消息流可以声明这种分组方法。而且这种消息tuple必须使用emitDirect方法来发射。消息处理者可以通过TopologyContext来获取处理它的消息的task的id （OutputCollector.emit方法也会返回task的id）。
  • Local or shuffle grouping
    如果目标bolt有一个或者多个task在同一个工作进程中，tuple将会被随机发生给这些tasks。否则，和普通的Shuffle Grouping行为一致。

Reliability(可靠性)

Tasks(任务)

每一个spout和bolt会被当作很多task在整个集群里执行。每一个executor对应到一个线程，在这个线程上运行多个task，而stream grouping则是定义怎么从一堆task发射tuple到另外一堆task。你可以调用TopologyBuilder类的setSpout和setBolt来设置并行度（也就是有多少个task）。

Workers(工作进程)

一个topology可能会在一个或者多个worker（工作进程）里面执行，每个worker是一个物理JVM并且执行整个topology的一部分。比如，对于并行度是300的topology来说，如果我们使用50个工作进程来执行，那么每个工作进程会处理其中的6个tasks。Storm会尽量均匀的工作分配给所有的worker。

StormAck机制

什么是Ack

为了保证数据能正确的被处理，对于spout产生的每一个tuple，storm都会进行跟踪。

ack机制即，spout发送的每一条消息:
在规定的时间内，spout收到acker的ack响应，即认为该tuple被后续bolt成功处理。
在规定的时间内，没有收到acker的ack响应，就触发fail动作，即认为该tuple处理失败。或者收到Acker发送的fail响应tuple，也认为失败，触发fail动作。

通过Ack机制，spout发送出去的每一条消息，都可以确定是被成功或失败处理，从而可以让开发者采取相应动作。

另外Ack机制还常用于限流作用:为了避免spout发送数据太快，而bolt处理太慢，常常设置pending数，
当spoout有等于或超过pending数的tuple没有收到ack或fail响应时，跳过执行nextTuple，从而限制spout发送数据。

Ack原理

Storm中有个特殊的task名叫acker它们负责跟踪spout发出的每一个tuple的Tuple树(因为一个tuple通过spout发出了，经过每一个bolt处理后，会生成一个新的tuple发送出去)。

当acker(框架自启动的task)发现一个Tuple树已经处理完成了，它会发送一个消息给产生这个Tuple的那个task。

对任意大的一个Tuple树，storm只需要恒定的20字节就可以进行跟踪。acker对于每个spout-tuple保存一个ack-val的校验值，它的初始值是0，然后每发射一个tuple或ack一个tuple时，这个tuple的id就要跟这个校验值异或一下，并且把得到的值更新为acl-val的新值。那么假设每个发射出去的tuple都被ack了，那么最后ack-val的值就一定是0。Acker就根据ack-val是否为0来判断是否完全处理，如果为0则认为已完全处理。

StormUI

Storm ui首页主要分为4块:

Cluster Summary

  • Version
    storm版本号

  • Nimbus uptime
    nimbus的运行时间

  • Supervisors
    storm集群中supervisor的数目

  • Used slots
    使用了的slots数

  • Free slots
    剩余的slots数

  • Total slots
    总的slots数(每个从节点默认4个slot)

  • Executors
    线程数

  • Tasks
    运行的任务数

Topology Summary

  • Name
    topology name

  • Owner
    topology启动用户

  • status
    topology的运行状态,包括(ACTIVE,INACTIVE,KILLED,REBALANCING)

  • Uptime
    topology运行的时间

  • Num workers
    topology运行的workers数

  • Num exectors
    topology运行的线程数

  • Num taasks
    topology运行的任务数

  • Replication Count
    topology副本数

  • Assigned Mem(MB)
    分配的内存,默认是832

Topology Page 查看Topology详细信息

  • Topology Summary 作业的整体概况

    • 同上一级页面Topology Summary

  • Topology actions

    • topology运行状态,可以手动更改状态

  • Topology stats 时间间隔内作业的状态

    • Window
      时间窗口,显示10m、3h、1d、和all time的运行状况
    • Emmitted
      emit tuple数
    • Transferred
      transferred tuple数, 如果一task，emitted一个tuple到2个task中，则transferred tuple数是emitted tuple数的两倍
    • Complete latency
      spout emitting 一个tuple到spout ack这个tuple的平均时间
    • Acked
      成功tuple数
    • Failed
      失败tuple数
      注：
      emitted栏显示的数字表示的是调用OutputCollector的emit方法的次数.

transferred栏显示的数字表示的是实际tuple发送到下一个task的计数.

如果一个bolt A使用all group的方式(每一个bolt都要接收到)向bolt B发射tuple, 此时bolt B启动了5个task, 那么trasferred显示的数量将是emitted的5倍.

如果一个bolt A内部执行了emit操作, 但是没有指定tuple的接受者, 那么transferred将为0.

有的bolt的execture方法中并没有emit tuple, 但是storm ui中依然有显示emitted, 主要是因为它调用了ack方法, 而该方法将emit ack tuple到系统默认的acker bolt. 因此如果anchor方式emit一个tuple, emitted一般会包含向acker bolt发射tuple的数量.

另外collector.emit(new Values(xxx))和collector.emit(tuple, new Values(xxx)) 这两种不同的emit方法也会影响后面bolt的emitted和transferred, 如果是前者, 则后续bolt的emited tuple 和transferred tuple这两个值都是0, 因为前一个emit方法是非安全的, 不再使用acker来进行校验.

  • Spouts 采集组件信息

    • Id
      Spout Id

    • Executors
      线程数

    • Task
      任务数

    • Emitted
      emit tuple数

    • Transferred
      transferred tuple数

    • Complete latency(ms)
      spout emitting 一个 tuple 到 spout ack 这个tuple的平均时间

    • Acked
      成功tuple数

    • Failed
      失败tuple数

    • Error Host
      发生错误的机器

    • Error Port
      发生错误的端口号

    • Last error
      最近的错误数

    • Error Time
      错误发生时间

  • Bolts 处理组件信息

    • Id
      bolt Id

    • Executors
      线程数

    • Task
      任务数

    • Emitted
      emit tuple数

    • Transferred
      transferred tuple数

    • Capacity(last 10m)

    • Execute latency(ms)
      bolt执行execute方法的平均时间

    • Executed
      tuple处理数

    • Process latency(ms)
      bolt收到一个tuple到bolt ack这个tuple的平均时间

    • Acked
      成功tuple数

    • Failed
      失败tuple数

    • Error Host
      发生错误的机器

    • Error Port
      发生错误的端口号

    • Last error
      最近的错误数

    • Error Time
      错误发生时间

  • Topology Visualization 拓扑图展示

  • Topology Configuration 配置说明

Supervisor Summary

  • Host
    supervisor的主机名
  • Id
    系统生成的supervisor id
  • Uptime
    supervisor运行时间
  • Slots
    supervisor端口数
  • Used Slots
    supervisor使用的端口数
  • Use Mem(MB)
    supervisor使用的内存
  • Version
    supervisor的版本

Nimbus Configuration

nimbus集群中配置文件信息

posted @ 2021-07-20 09:09  cos晓风残月  阅读(241)  评论(0)  编辑  收藏  举报
*