storm开发解决问题点
1.kafka消费速度跟不上问题
这个问题可以从加大topic partition进行解决,可以在topic正在运行时候运行命令
./kafka-topics --alter --zookeeper rhel071:2181 --topic heartbeat --partitions 6进行扩容,并且只能往上扩容,不能减少partition。每个partition会对应一个storm的spout，所以能整体增加消费速度。当然如果kafka下面log挂了多个磁盘,那么多个分区速度理论上会更快。
2.消费者topic一致共用的问题
两个storm想共用一个topic数据时候,可以采用不用group进行消费。此时会互不影响,但是后门新的group只能中途进行消费.也就是不会从begining开始.如果要从头开始消费要进行offset设置.但是也要考虑kafka数据只保留默认7天（看设置）。所以begining也是保留的开始端。
3.测试的topic没有group如何查询范围的问题
一个新的topic想看里面有没数据，但是也没group可以查，除了看原始数据比较简便方法是
注： time为-1时表示最大值，time为-2时表示最小值
bin/kafka-run-class.sh kafka.tools.GetOffsetShell --topic tb_exception_reg_1 --time -1 --broker-list 192.168.42.75:9092 --partitions 0
可以查看offset的范围,就可以看到里面是否进行了数据。
4.mysql 8小时断开问题
mysql默认链接会有个8小时失效问题。这个要有意识,如果mysql一段时间正常后报错可以考虑这个问题，网上找方案解决.方案比较多不一一列举。默认mysql是8小时有效
5.查看topic消费者挤压问题
GROUP TOPIC PID OFFSET LOGSIZE LAG
消费者组 话题id 分区id 当前已消费的条数 总条数 未消费的条数
这个要注意看LAG的数据挤压。。记得放大CRT，不然容易看错
6.mysql修改系统参数出现Access denied; you need the SUPER privilege for this operation问题
修改mysql环境变量的参数时候,有两种一种是
set @@global.interactive_timeout=300;
set @@global.wait_timeout=300;
这种重启后会失效,还有一种是修改mysql 的my.cnf进行永久修改。记得最好进命令行库中用root进行修改参数。在工具中进行远程试过root登录也一直报权限修改未成功。
7.Kerberos连接hbase的问题
conf.set("java.security.krb5.kdc", "/etc/krb5.conf");
conf.set("java.security.krb5.realm", "HADOOP.COM");
conf.set("kerberos.principal", "hbase/_HOST@HADOOP.COM");
conf.set("java.security.krb5.kdc", "/etc/krb5.conf");
conf.set("java.security.krb5.realm", "HADOOP.COM");
conf.set("hbase.zookeeper.quorum", constant.HbaseKafkaZKClustAddress);//dm-hadoop6,dm-hadoop7,dm-hadoop8 //192.168.42.71
conf.set("hbase.zookeeper.property.clientPort", "2181");
conf.set("zookeeper.znode.parent", "/hbase");
conf.set("hadoop.security.authentication", "kerberos");
conf.set("hbase.security.authentication", "kerberos");
conf.set("hbase.master.kerberos.principal", "hbase/_HOST@HADOOP.COM");
conf.set("hbase.regionserver.kerberos.principal",
"hbase/_HOST@HADOOP.COM");
hbase手动认证(有时效限制)
kinit -k -t /home/richdm/richdm.keytab richdm@HADOOP.COM
8.spout killed的时候内存缓存数据的清理问题
storm本身在执行killstorm的时候会执行cleanup()方法,但是本人验证多次,很多时候执行到一半storm就被关闭了。在此推荐另一种方案，由spout的deactivate（）方法出发,当storm关闭的时候发出一条emit通知所有下游做好关闭资源动作。可以另起一个spout用来专用管理storm的关闭功能
public void deactivate() {
System.out.println("shutdown deaactivate to spout and bolt");
try {
String mes = "shutDown";
long id = 11111111111111111L;
_collector.emit("stop", new Values(mes), id);
//Thread.sleep(1000);
} catch (Exception e) {
e.printStackTrace();
}
}
//接上kill storm 资源释放 20
builder.setBolt("HbaseBolt", new HbaseBolt(), constant.HbaseBoltNum).shuffleGrouping("SensitiveBolt").allGrouping("shutDownSpout","stop");//hbase入库模块
//kill storm清理资源
if ( tuple.getSourceStreamId().equals("stop") ) {
// System.out.println("==========clear======HbaseBolt=======");
this.StromCleaner("killStorm",this.hbaseUtil,this.storm_HbaseMap_reg,this.storm_HbaseMap_heartbeat,this.storm_HbaseMap_reg_delay,this.storm_HbaseMap_heartbeat_delay);
return;
}
9.storm定时器造成数据少接收问题
在storm里面用timer不知道为什么会造成数据接收丢失,但是笔者在stormHDFS包源码看过类似用法。这里比较推介用storm自带的定时器
@Override
public Map<String, Object> getComponentConfiguration() {
//设置发送ticktuple的时间间隔，默认半小时一次1800秒 1200
Config conf = new Config();
conf.put(conf.TOPOLOGY_TICK_TUPLE_FREQ_SECS, 60);
return conf;
}
在tuple接收端
if (tuple.getSourceComponent().equals(Constants.SYSTEM_COMPONENT_ID)&& tuple.getSourceStreamId().equals(Constants.SYSTEM_TICK_STREAM_ID)) {
逻辑；
}
10.storm节点不稳定造成数据丢失问题
测试环境开发的时候有时候会出现数据数据丢失,或者关闭一些功能不执行。可以观察下每个bolt的端口节点,数据数量上知否一致。
一般来说,executed的节点分配数量都会比较均匀,所以执行数量也会比较接近,如果差距数量大,并且会掉数,可以从节点出错进行排查。
11.storm节点数量太少造成单节点数据并发混乱问题
storm分配会优先不同节点,不同端口,然后同一个节点不同端口进行分配应用执行。但是当用户开放的端口过少的时候,storm会把同一个应用运行于同一个端口上。这时候或许是程序并行执行。当出现不安全操作的时候。很容易出现掉数等一类问题。所以上应用之前。spout和bolt的并发数设置和自己端口是否够用要确定好。上之后storm分配给你的正不正确,并发之间是否独立要观察好。
12.storm多个节点同时操作mysql和hbase一些冲突问题
storm 一个bolt去更新mysql的时候，并发下会出现多个节点一起操作问题。这时候最好设定主键，然后利用主键去判断这一问题。当然也可以通过设置一个单一职责的bolt去做这件事。由于开发周期比较长，本人用了主键冲突去做了判断是否别的节点已经更新。
13.storm 执行exit work重启问题
在bolt里面执行java的exit（0）的时候会造成一个节点的重启运行。判断可以看日志是否重启了work或者节点UI的数量又从0开始计算了。
14.storm log不会完成保留的问题（未解决,可以用日志调试级别）
storm会打印出大量日志。/opt/storm/log4j2可以设置保存的日志方式。比如设置了100M 日志满100M就会进行压缩块。保存多少压缩块。经过测试最好别打印太多日志，只保留一些error。和关键的运行参数。
slf4j也可以在此处进行调整，只输出哪种类型的日志。方便排查
15.storm work和bolt并发数的调整问题
storm 一个work可以承担几个并发。并不是一一对应。具体如何调整可以看网上文章
16.hbase入库速度处理跟不上spout流速度造成数据挤压问题
在处理hbase的时候一度产生大量数据挤压，跟不上spout的速度。后来把一些比较费事的操作比如hbase 每次都判断表是否存在。改成只判定一次。（建议spout 和bolt操作中不要进行太耗时操作）
17.入库每天会少1---10万的数据问题
这个问题当时排查了很多思路。1 上游发送数据量和自己数据量批对（应该不会丢失太多）。hbase每天插入是否有数据量丢失（理论应该成批次丢失）。内存残留数据（可以定时flush）。后来排查到问题是产生rowkey的方式有问题。出现重复了。hbase对于rowkey问题还是要参考UUID
18.hive转移hbase关联表出现0KB文件问题
这个问题首先考虑到是MR执行数据倾斜了,后来突然想到MR执行过程可能是根据hbase的分区去进行抽取的,测试去掉一些没用的hbase预分区,0KB文件消失了。还有一个问题是javaUUID产生的算法是每位由16进制的数字生成,所以首位最大是f,也就是0--9 a---f，不会超过f,所以hbase预分区应当不超过f。产生16进制UUID关键代码如下。关键toString 返回而digits是产生16进制的过程
