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進制的過程
