大数据(十四)

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是project主管或技术主管,管理工作进程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连接port

storm.local.dir

storm使用的本地文件系统文件夹(必须存在而且storm进程可读写)

storm.cluster.mode

Storm集群执行模式([distributed|local])

storm.local.mode.zmq

Local模式下是否使用ZeroMQ作消息系统。假设设置为false则使用java消息系统。默觉得false

storm.zookeeper.root

ZooKeeperStorm的根文件夹位置

storm.zookeeper.session.timeout

client连接ZooKeeper超时时间

storm.id

执行中拓扑的id,storm name和一个唯一随机数组成。

nimbus.host

nimbus服务器地址

nimbus.thrift.port

nimbusthrift监听port

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的服务port

drpc.servers

DRPC服务器列表,以便DRPCSpout知道和谁通讯

drpc.port

Storm DRPC的服务port

supervisor.slots.ports

supervisor上能够执行workers的port列表.每一个worker占用一个port,且每一个port只执行一个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

假设设置成trueStorm将记录发射的每条信息。

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

topologyspout发送消息的最大处理超时时间.假设一条消息在该时间窗体内未被成功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,而不是整个spoutstopology.

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,Supervisorworkers)时的java.library.path设置.该选项告诉JVM在哪些路径下定位本地库.


命令
公布启动任务
    storm jar jar包名 包括main方法的类
    storm jar jar包名 包括main方法的类  拓扑名
查看任务
    storm list
停止任务
    storm kill 任务名称


【推广】 免费学中医,健康全家人
原文地址:https://www.cnblogs.com/zhchoutai/p/8305971.html