探索人工智能应用场景!

大数据(十四) – Storm

人工智能 admin 17℃ 0评论
storm是一个分布式实时计算引擎
storm/Jstorm的安装、配置、启动几乎一模一样
storm是twitter开源的

storm的特点
storm支持热部署,即时上限或下线app
可以在storm上使用各种编程语言如clojure、java、ruby、python等
本地模式:storm有一个本地模式,可以在处理过程中完全模拟storm集群,便于开发和测试。
storm使用场景
    1、流聚合:把两个或多个数据流聚合成一个数据流:基于一些共同的tuple字段
    2、批处理:因为性能或其他原因
    3、BasicBolt:太常见的一种场景,所以storm内置了实现
    4、内存内缓存+fields grouping组合
    5、计算top N
    6、TImecachemapping
    7、分布式DRPC
基本概念
Topology:计算拓扑,即一个应用程序app(通过storm jar发布),因为各个组件间的消息流动形成逻辑上的一个拓扑结构,因此得名。
    TopologyBuilder是拓扑构建器,将spout、bolt等组合起来
spout:消息流的源头,消息生产者。
bolt:消息处理者
Reliability:可靠性,storm保证每个tuple都会被处理。
task:任务,每个spout和bolt都是一个任务,每个任务默认是一个线程。
worker:工作进程,每个工作进程都有多个task
Values:数据容器
Tuple  英[tʌpl]:一个消息传递的基本单元,发送的数据封装到tuple中,实际就是一个value list
        JStorm将流中数据抽象为tuple,一个tuple就是一个值列表value list,list中的每个value都有一个name,并且该value可以是基本类型,字符类型,字节数组等,当然也可以是其他可序列化的类型。
Stream:消息流,源源不断的tuple组成了stream
stream grouping:消息分发策略,一共6种,定义每个bolt接收什么样的消息。
Cofig:设置一些配置信息
StormSubmitter/LocalCluster拓扑提交器
tuple在传输过程中需要序列化和反序列化
spout从外部数据源读取tuple,emit到topology里
spout分可靠的和非可靠的两种,对可靠的,还支持ack和fail方法
Storm Topology是基于Thrift结构, 并且Nimbus是个Thrift server, 所以对于Topology可以用任何语言实现, 最终都是转化为Thrift结构
重要的是, nimbus和supervisor的fail或restart不会影响worker的工作
打比方
Nimbus是老总,下放代码
zookeeper是项目经理,管理集群中的组件,管理任务task,负责nimbus和supervisor协调工作
supervisor是工程主管或技术主管,管理工作进程worker
work是工人,工作进程,他们处理任务task
task即任务,worker进程中每一个spout、bolt、actor的线程都是一个task任务
actor负责跟踪监控任务spout、bolt的执行,他也是任务task
executor是线程,一个task默认由一个executor线程执行,当然一个executor线程里可以处理多个task
storm集群结构
集群由一个主节点和多个子节点(控制节点和工作节点)组成。
1、主节点/控制节点:运行着一个叫做Nimbus的守护进程,负责分配代码、布置任务、故障将侧。
2、子节点/工作节点,运行着一个名为Supervisor的守护进程,负责监听工作,开始并终止工作进程worker
nimubus和storm ui需要在同一台机子上
tuple流的分组机制,即消息分发策略(以下是常用的策略)
    shuffle grouping:随机分组,随机派发stream里的tuple,保证每个bolt收到的tuple数量相同。
    field grouping:按字段分组,如userid,具有相同uiserid的tuple会被分到相同的bolt。(相同userid的tuple会分到相同的bolt中,但是这个bolt中可以有多种tuple)
    all grouping:广播发送,针对一个tuple,所有bolt都会受到(谨慎使用)
    global grouping:全局分组,指全部流都发送到Bolt的同一个任务中,再具体一点,是发送给ID最小的任务。
    non grouping:不分组,不需要关心怎么分组,目前等效于随机分组
storm组件生命周期
Spout方法调用顺序
    declareOutputFields     topology提交过程中会调用spout和bolt的这个方法
    open     类似bolt的prepare方法,而且参数也类似,可以处理配置信息,做准备工作
    activate
    nextTuple    循环调用
    deactivate
Bolt方法调用顺序
    declareOutputFields
    prepare
    execute    循环调用
storm可靠性
storm有默认的配置文件,在storm jar包里 storm.yaml
storm有一种机制可以保证从spout发出的每个tuple都会被完全处理。
什么样的消息被认为完整处理了:
    1、tuple tree不再生长
    2、树中的任何消息都标识为”已处理”
storm配置
storm.zookeeper.servers ZooKeeper服务器列表
storm.zookeeper.port ZooKeeper连接端口
storm.local.dir storm使用的本地文件系统目录(必须存在并且storm进程可读写)
storm.cluster.mode Storm集群运行模式([distributed|local])
storm.local.mode.zmq Local模式下是否使用ZeroMQ作消息系统,如果设置为false则使用java消息系统。默认为false
storm.zookeeper.root ZooKeeper中Storm的根目录位置
storm.zookeeper.session.timeout 客户端连接ZooKeeper超时时间
storm.id 运行中拓扑的id,由storm name和一个唯一随机数组成。
nimbus.host nimbus服务器地址
nimbus.thrift.port nimbus的thrift监听端口
nimbus.childopts 通过storm-deploy项目部署时指定给nimbus进程的jvm选项
nimbus.task.timeout.secs 心跳超时时间,超时后nimbus会认为task死掉并重分配给另一个地址。
nimbus.monitor.freq.secs nimbus检查心跳和重分配任务的时间间隔.注意如果是机器宕掉nimbus会立即接管并处理。
nimbus.supervisor.timeout.secs supervisor的心跳超时时间,一旦超过nimbus会认为该supervisor已死并停止为它分发新任务.
nimbus.task.launch.secs task启动时的一个特殊超时设置.在启动后第一次心跳前会使用该值来临时替代nimbus.task.timeout.secs.
nimbus.reassign 当发现task失败时nimbus是否重新分配执行。默认为真,不建议修改。
nimbus.file.copy.expiration.secs nimbus判断上传/下载链接的超时时间,当空闲时间超过该设定时nimbus会认为链接死掉并主动断开
ui.port Storm UI的服务端口
drpc.servers DRPC服务器列表,以便DRPCSpout知道和谁通讯
drpc.port Storm DRPC的服务端口
supervisor.slots.ports supervisor上能够运行workers的端口列表.每个worker占用一个端口,且每个端口只运行一个worker.通过这项配置可以调整每台机器上运行的worker数.(调整slot数/每机)
supervisor.childopts 在storm-deploy项目中使用,用来配置supervisor守护进程的jvm选项
supervisor.worker.timeout.secs supervisor中的worker心跳超时时间,一旦超时supervisor会尝试重启worker进程.
supervisor.worker.start.timeout.secs supervisor初始启动时,worker的心跳超时时间,当超过该时间supervisor会尝试重启worker。因为JVM初始启动和配置会带来的额外消耗,从而使得第一次心跳会超过supervisor.worker.timeout.secs的设定
supervisor.enable supervisor是否应当运行分配给他的workers.默认为true,该选项用来进行Storm的单元测试,一般不应修改.
supervisor.heartbeat.frequency.secs supervisor心跳发送频率(多久发送一次)
supervisor.monitor.frequency.secs supervisor检查worker心跳的频率
worker.childopts supervisor启动worker时使用的jvm选项.所有的”%ID%”字串会被替换为对应worker的标识符
worker.heartbeat.frequency.secs worker的心跳发送时间间隔
task.heartbeat.frequency.secs task汇报状态心跳时间间隔
task.refresh.poll.secs task与其他tasks之间链接同步的频率.(如果task被重分配,其他tasks向它发送消息需要刷新连接).一般来讲,重分配发生时其他tasks会理解得到通知。该配置仅仅为了防止未通知的情况。
topology.debug 如果设置成true,Storm将记录发射的每条信息。
topology.optimize master是否在合适时机通过在单个线程内运行多个task以达到优化topologies的目的.
topology.workers 执行该topology集群中应当启动的进程数量.每个进程内部将以线程方式执行一定数目的tasks.topology的组件结合该参数和并行度提示来优化性能
topology.ackers topology中启动的acker任务数.Acker保存由spout发送的tuples的记录,并探测tuple 何时被完全处理.当Acker探测到tuple被处理完毕时会向spout发送确认信息.通常应当根据topology的吞吐量来确定acker的数目, 但一般不需要太多.当设置为0时,相当于禁用了消息可靠性,storm会在spout发送tuples后立即进行确认.
topology.message.timeout.secs topology中spout发送消息的最大处理超时时间.如果一条消息在该时间窗口内未被成功ack,Storm会告知spout这条消息失败。而部分spout实现了失败消息重播功能。
topology.kryo.register 注册到Kryo(Storm底层的序列化框架)的序列化方案列表.序列化方案可以是一个类名,或者是com.esotericsoftware.kryo.Serializer的实现.
topology.skip.missing.kryo.registrations Storm是否应该跳过它不能识别的kryo序列化方案.如果设置为否task可能会装载失败或者在运行时抛出错误.
topology.max.task.parallelism 在一个topology中能够允许的最大组件并行度.该项配置主要用在本地模式中测试线程数限制.
topology.max.spout.pending 一个spout task中处于pending状态的最大的tuples数量.该配置应用于单个task,而不是整个spouts或topology.
topology.state.synchronization.timeout.secs 组件同步状态源的最大超时时间(保留选项,暂未使用)
topology.stats.sample.rate 用来产生task统计信息的tuples抽样百分比
topology.fall.back.on.java.serialization topology中是否使用java的序列化方案
zmq.threads 每个worker进程内zeromq通讯用到的线程数
zmq.linger.millis 当连接关闭时,链接尝试重新发送消息到目标主机的持续时长.这是一个不常用的高级选项,基本上可以忽略.
java.library.path JVM启动(如Nimbus,Supervisor和workers)时的java.library.path设置.该选项告诉JVM在哪些路径下定位本地库.

命令

发布启动任务
    storm jar jar包名 包含main方法的类
    storm jar jar包名 包含main方法的类  拓扑名
查看任务
    storm list
停止任务
    storm kill 任务名称
原文地址:http://blog.csdn.net/matthewei6/article/details/50570044

转载请注明:全球人工智能 » 大数据(十四) – Storm

   

您的支持将鼓励我们继续努力!

[微信] 扫描二维码打赏

[支付宝] 扫描二维码打赏

喜欢 (1)or分享 (0)
发表我的评论
取消评论
表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址