storm基本使用心得精华

最新推荐文章于 2024-04-14 12:06:46 发布

bigdataCoding

最新推荐文章于 2024-04-14 12:06:46 发布

阅读量2.7k

点赞数

分类专栏： Storm 大数据

本文链接：https://blog.csdn.net/UnionIBM/article/details/54291743

版权

大数据同时被 2 个专栏收录

35 篇文章 0 订阅

订阅专栏

Storm

6 篇文章 0 订阅

订阅专栏

1.利用mvn打好jar 提交到集群上

storm jar stormTopoploy.jar [主函数名] [参数名]

2.查看集群上运行的Topology

storm list

Topology_name Status Num_tasks Num_workers Uptime_secs

-------------------------------------------------------------------

wdTopology ACTIVE 29 3 1157

3 kill 运行的Topology

storm kill [Topology名字]

2542 [main] INFO b.s.u.StormBoundedExponentialBackoffRetry - The baseSleepTimeMs [2000] the maxSleepTimeMs [60000] the maxRetries [5]

2599 [main] INFO b.s.c.kill-topology - Killed topology: wdTopology

二本地运行Storm

3226 [main] INFO b.s.u.Utils - Using defaults.yaml from resources //默认读取本地的storm.yaml
4753 [main] INFO o.a.s.s.o.a.z.ZooKeeper - Client environment:zookeeper.version=3.4.6-1569965, built on 02/20/2014 09:09 GMT
4753 [main] INFO o.a.s.s.o.a.z.ZooKeeper - Client environment:host.name=172.18.59.82
4753 [main] INFO o.a.s.s.o.a.z.ZooKeeper - Client environment:java.version=1.8.0_101
4753 [main] INFO o.a.s.s.o.a.z.ZooKeeper - Client environment:java.vendor=Oracle Corporation
4753 [main] INFO o.a.s.s.o.a.z.ZooKeeper - Client environment:java.home=/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre

//Storm 读取 zookeeper的信息

Map<String, Object> cf = backtype.storm.utils.Utils.readStormConfig();

String zkServers = cf.get(Config.STORM_ZOOKEEPER_SERVERS).toString();

String zkPort = cf.get(Config.STORM_ZOOKEEPER_PORT).toString();
System.out.println(zkServers+"----"+zkPort);

//public static final String STORM_ZOOKEEPER_SERVERS = "storm.zookeeper.servers";

//public static final String STORM_ZOOKEEPER_PORT = "storm.zookeeper.port";

由于Storm中Nimbus和Supervisor是无状态的，Nimbus会把topology写到到ZK当中，Supervisor会到ZK去读这些信息，实现了解耦

如下zookeeper存放storm的一些信息

/-{storm-zk-root}           -- storm在zookeeper上的根
        |                            目录
        |
        |-/assignments            -- topology的任务分配信息
        |   |
        |   |-/{topology-id}      -- 这个下面保存的是每个
        |                            topology的assignments
        |                            信息包括： 对应的
        |                            nimbus上的代码目录,所有
        |                            task的启动时间,
        |                            每个task与机器、端口的映射
        |
        |-/tasks                  -- 所有的task
        |   |
        |   |-/{topology-id}      -- 这个目录下面id为
        |       |                    {topology-id}的topology
        |       |                    所对应的所有的task-id
        |       |
        |       |-/{task-id}      -- 这个文件里面保存的是这个
        |                            task对应的component-id：
        |                            可能是spout-id或者bolt-id
        |
        |-/storms                 -- 这个目录保存所有正在运行
        |   |                        的topology的id
        |   |
        |   |-/{topology-id}      -- 这个文件保存这个topology
        |                            的一些信息，包括topology的
        |                            名字，topology开始运行的时
        |                            间以及这个topology的状态
        |                            (具体看StormBase类)
        |
        |-/supervisors            -- 这个目录保存所有的supervisor
        |   |                        的心跳信息
        |   |
        |   |-/{supervisor-id}    -- 这个文件保存的是supervisor
        |                            的心跳信息包括:心跳时间，主
        |                            机名，这个supervisor上worker
        |                            的端口号运行时间
        |                            (具体看SupervisorInfo类)
        |
        |-/taskbeats              -- 所有task的心跳
        |   |
        |   |-/{topology-id}      -- 这个目录保存这个topology的所
        |       |                    有的task的心跳信息
        |       |
        |       |-/{task-id}      -- task的心跳信息，包括心跳的时
        |                            间，task运行时间以及一些统计
        |                            信息
        |
        |-/taskerrors             -- 所有task所产生的error信息
        |
        |-/{topology-id}      -- 这个目录保存这个topology下面
        |                    每个task的出错信息
        |
        |-/{task-id}      -- 这个task的出错信息

Storm 问题

ClassNotFoundException: kafka.api.OffsetRequest ，要注意strom-kafka是使用的kafka的低级api，因此也要引用kafka的包导入就不报错了

这个博客讲Storm觉得不错

http://blog.csdn.net/tanggao1314/article/category/6326204

Storm如何保证消息的完整性:

Ack原理
　　Storm中有个特殊的task名叫acker，他们负责跟踪spout发出的每一个Tuple的Tuple树（因为一个tuple通过spout发出了，经过每一个bolt处理后，会生成一个新的tuple发送出去）。当acker（框架自启动的task）发现一个Tuple树已经处理完成了，它会发送一个消息给产生这个Tuple的那个task。
Acker的跟踪算法是Storm的主要突破之一，对任意大的一个Tuple树，它只需要恒定的20字节就可以进行跟踪。
Acker跟踪算法的原理：acker对于每个spout-tuple保存一个ack-val的校验值，它的初始值是0，然后每发射一个Tuple或Ack一个Tuple时，这个Tuple的id就要跟这个校验值异或一下（两个操作数的位中，相同则结果为0，不同则结果为1），并且把得到的值更新为ack-val的新值。那么假设每个发射出去的Tuple都被ack了，那么最后ack-val的值就一定是0。Acker就根据ack-val是否为0来判断是否完全处理，如果为0则认为已完全处理。

要实现ack机制：
1，spout发射tuple的时候指定messageId
2，spout要重写BaseRichSpout的fail和ack方法
3，spout对发射的tuple进行缓存(否则spout的fail方法收到acker发来的messsageId，spout也无法获取到发送失败的数据进行重发)，看看系统提供的接口，只有msgId这个参数，这里的设计不合理，其实在系统里是有cache整个msg的，只给用户一个messageid，用户如何取得原来的msg貌似需要自己cache，然后用这个msgId去查询，太坑爹了
3，spout根据messageId对于ack的tuple则从缓存队列中删除，对于fail的tuple可以选择重发。
4,设置acker数至少大于0；Config.setNumAckers(conf, ackerParal);

Storm的Bolt有BsicBolt和RichBolt:
　　在BasicBolt中，BasicOutputCollector在emit数据的时候，会自动和输入的tuple相关联，而在execute方法结束的时候那个输入tuple会被自动ack。
　　使用RichBolt需要在emit数据的时候，显示指定该数据的源tuple要加上第二个参数anchor tuple，以保持tracker链路，即collector.emit(oldTuple, newTuple);并且需要在execute执行成功后调用OutputCollector.ack(tuple), 当失败处理时，执行OutputCollector.fail(tuple);