一、集群storm版本:
storm version命令打出來的:
storm 0.10.0.2.3.0.0-2557url [email protected]:hortonworks/storm.git -r 38fad7c05bd00ac4ca61b68abf7411d9abc6189c
branch (no branch)
compiled by jenkins on
2015-07-14t14:45z
from source with checksum 43c4b3baaad6a0bca88145356d46327
本地storm版本:apache-storm-0.10.1 注意版本和集群並不一致
storm-hbase jar包版本:
<dependency
>
<
groupid
>org.apache.storm
groupid
>
<
artifactid
>storm-hbase
artifactid
>
<
version
>0.10.0
version
>
dependency
>
hbase version:
[root@node3 tmp]# hbase version2016-07-08 14:02:14,137 info [main] util.versioninfo: hbase 1.1.1.2.3.0.0-2557
2016-07-08 14:02:14,140 info [main] util.versioninfo: source code repository git: revision=6a55f21850cfccf19fa651b9e2c74c7f99bbd4f9
2016-07-08 14:02:14,140 info [main] util.versioninfo: compiled by jenkins on tue jul 14 09:41:13 edt 2015
2016-07-08 14:02:14,140 info [main] util.versioninfo: from source with checksum 8f076e3255b10e166a73c2436c2b1706
二、本地模式下測試往hbase裡寫資料,拓撲定義**如下,用了自帶的hbasebolt類
publicclass
persisttopology
else
}}
測試結果:520多萬條資料,寫了幾個多小時,平均一秒鐘才幾百條
問題原因:看了hbasebolt類的原始碼發現,此版本實現不是批量發的,如下,每收到乙個tuple會呼叫execute函式,然後就直接batchmutate發出去了
@overridepublic
void
execute(tuple tuple)
catch
(exception e)
this
.collector.ack(tuple);
}
二、下了乙個apache-storm-1.0.1的原碼發現execute函式的實現已經變成真正的批量傳送,如下:
@overridepublic
void
execute(tuple tuple) /{}]", tuplebatch.size(), batchsize);
collector.ack(tuple);
flush = true
; }
else
}if (flush && !tuplebatch.isempty())
tuplebatch.clear();
batchmutations.clear();}}
catch
(exception e)
tuplebatch.clear();
batchmutations.clear();
}}
batchsize可以設定,一旦當前資料量超過這個值就會被批量寫入到hbase,同時,if (tupleutils.istick(tuple))這個目測是一種機制,隔一段時間bolt就會收到這樣乙個tick tuple,類似於一種定時的機制,這樣可保證到達這個時間後即使資料量不到batchsize這麼多也能被及時寫入,該值可以設定,通過**或storm.yaml配置檔案都可以,**設定如下:
conf.put("hbase.conf", hbconf);8);
32);
16384);
16384);
conf.put(config.topology_tick_tuple_freq_secs, 1);
配置檔案設定如下,**設定應該優先順序更高(還沒試過):
[root@node1 conf]# more storm.yaml |greptuple
topology.tick.tuple.freq.secs :
1
沒有公升級storm版本,直接在當前的版本裡把新版本中優化的**抄了過來,上集群測試。
測試結果:資料量和之前一樣,但是有非常大的提公升,之前需要5個多小時寫入的資料,差不多二十分鐘就寫完了
提高HBase寫效能
以下為使用hbase一段時間的三個思考,由於在記憶體充足的情況下hbase能提供比較滿意的讀效能,因此寫效能是思考的重點。希望讀者提出不同意見討論 1 autoflush false的影響 2 hbase.hregion.max.filesize應該設定多少合適 hbase中hfile的預設最大值 ...
HBase寫效能優化之引數篇
hbase.regionserver.handler.count hbase site.xml 預設值 10 引數說明 每個region server上的rpc handler的數量,提公升rpc handler的數量可以一定程度上提高hbase在處理大量併發時接收請求的能力 hbase heaps...
Storm效能優化
如何找到topology的效能瓶頸?效能優化的第一步就是找到瓶頸在 從瓶頸處入手,解決關鍵點問題,事半功倍。除了通過系統命令檢視cpu使用,jstack檢視堆疊的呼叫情況以外,還可以通過storm自身提供的資訊來對效能做出相應的判斷。在storm 的ui中,對沒過topology都提供了相應的統計資...