Zookeeper+Kafka+Storm+HDFS实践

Kafka是一种高吞吐量的分布式发布订阅消息系统，它能够处理消费者规模的网站中的全部动做流数据。

Hadoop通常用在离线的分析计算中，而storm区别于hadoop，用在实时的流式计算中，被普遍用来进行实时日志处理、实时统计、实时风控等场景，固然也能够用在对数据进行实时初步的加工，存储到分布式数据库中如HBase，便于后续的查询。
面对的大批量的数据的实时计算，storm实现了一个可扩展的、低延迟、可靠性和容错的分布式计算平台。
一、对象介绍
tuple：表示流中一个基本的处理单元，能够包括多个field，每一个filed表示一个属性
topology：一个拓扑是一个个计算节点组成的图，每一个节点包换处理的逻辑，节点之间的连线表示数据流动的方向
spout：表示一个流的源头，产生tuple
bolt：处理输入流并产生多个输出流，能够作简单的数据转换计算，复杂的流处理通常须要通过多个bolt进行处理
nimnus：主控节点，负责在集群中发布代码，分配工做给机器，而且监听状态
supervisor：一个机器，工做节点，会监听分配给的工做，根据须要启动和关闭工做进程。
woker：执行topology的工做进程，用于生成task
task：每一个spout和bolt均可以做为task在storm中运行，一个task对应一个线程
storm拓扑topology的组成见下图，

总体架构

客户端提交拓扑到nimbus。

Nimbus针对该拓扑创建本地的目录根据topology的配置计算task，分配task，在zookeeper上创建assignments节点存储task和supervisor机器节点中woker的对应关系；

在zookeeper上建立taskbeats节点来监控task的心跳；启动topology。

Supervisor去zookeeper上获取分配的tasks，启动多个woker进行，每一个woker生成task，一个task一个线程；根据topology信息初始化创建task之间的链接;Task和Task之间是经过zeroMQ管理的；后整个拓扑运行起来。

上述只是介绍了storn的整个工做流程，固然storm在可靠性、容错性等方面考虑的比较全面，这后续再补充。

 

Storm的配置文件通常存放在$STORM_HOME/conf下，一般名为storm.yaml，它符合yaml格式要求。

配置项详解:

如下是从storm的config类中搜集的全部storm支持的配置项(Based storm 0.6.0):

配置项	配置说明
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在哪些路径下定位本地库.

提交topology成功后，发现运行不正常

1. 验证topology提交成功：打开nimbus ui，看看提交的topology是否存在
2. 检查本身的topology，在ui中点击本身的topology后查看spout是否有emit计数，若是有，那么storm集群ok，若是不正常，那是程序的问题
3. 在ui中看看是否有可用的supervisor
4. 在ui中看是否有free slot
5. 在ui中检查本身的topology，看看是否显示了spout和bolt运行在哪儿，若是没有说明根本没起来，若是重启集群后，依然没法起来，那么是你的程序问题

程序问题排查

1. submit日志在nimbus.log
2. 生成work命令行的日志输出在supervisor.log
3. 程序运行时的日志在work-xxx.log

参考 ：

　　zookeeper集群搭建

     Kafka+Storm+HDFS整合实践

　　Storm 入门简介

      Storm Kafka