大数据(十四) - Storm

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在传输过程中须要序列化和反序列化

http://www.51studyit.com/html/notes/20140329/44.html

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	ZooKeeper中Storm的根文件夹位置
storm.zookeeper.session.timeout	client连接ZooKeeper超时时间
storm.id	执行中拓扑的id,由storm name和一个唯一随机数组成。

nimbus.host	nimbus服务器地址
nimbus.thrift.port	nimbus的thrift监听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	假设设置成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 任务名称