Hbas預分區
在系統中向hbase中插入數據時，常常通過設置region的預分區來防止大數據量插入的熱點問題，提高數據插入的效率，同時可以減少當數據猛增時由於Region split帶來的資源消耗。大量的預分區數量會導致hbase客戶端緩存大量的分區地址，導致內存的增長，某些系統中一個JVM進程中會開啟幾十個獨立的hbase客戶端對象，同時會查詢多張Hbase表，這樣JVM進程就會緩存 (預分區數 X 表數 X Hbase客戶端數=條記錄)。
storm的自定義分組
有沒有這種情況?有的，在本人的storm項目中，采用結合spring注入的方式來結合Hbase向hbase存入數據，storm中的每一個線程都會創建一個XmlBeanDefinitionReader對象來加載spring的配置文件，所以一個線程就有一個hbse客戶端對象了，同時Hbase表設置102預分區，一個topology會操作最少8張表，一個worker會走20個task。所以一個work會緩存大約102*8*20=16320條記錄，每一條記錄的數據格式大致就是hbase.meta的一條數據格式，經過我計算16000多條記錄一個JVM中占用內存也就5M多，對內存的消耗是完全可以忽略不計的。這就很尷尬了。這種優化只是對於大規模的集群來說有效果，小規模集群考慮這種情況是過度設計了。比如那種Hbase客戶端會有緩存一整張hbase.meta表數據的系統又或者那種hbase表分區達到上萬的系統，那么一個woeker中地址的緩存會達到幾百兆，這個時候從原理上就可以進行設計了來節省資源消耗，想想可以省好多台服務器。
說了這么多，如何來進行系統資源優化？可以結合storm的自定義分區，不再使用storm提供的分組策略，我們把作用於hbase的散列算法來作為storm的分組策略，就可以得到storm的task與hbase的預分區一一對應了。
以前的系統
消息進來了以后，由spout均勻的發送到各個intsmaze-bolt節點上，每一個bolt節點再使用散列算法把該消息存入對應的hbase表分區中。
現在的系統
消息進來了以后，spout在進行發送給intsmaze-bolt的時候，在分組策略中使用與hbase同樣的散列算法，然后把同一范圍內的消息發送給對應的intsmaze-bolt的taske,這樣就可以保證bolt的並行度與hbase的預分區一一對應，每一個taske中的hbase客戶端只會緩存對應的幾個hbase的表預分區的地址信息。
關於storm的自定義分組的實現可以百度，這里不給出代碼實現，只給出實現方案。補充一句，散列算法設計的好，是可以保證消息在storm的bolt里的task分發中不會發生數據傾斜的。
Hbase1.1.2的客戶端源碼
會先到zookeeper中拿到hbase.meta的地址信息，hbase.meta里面存儲着所有用戶表各個分區的地址已經rowkey的范圍：
locations= [region=hbase:meta,,1.1588230740, hostname=centos-reall-132,16020,1490876417048, seqNum=0]
這里就好把表名和該表的地址等元數據緩存下來，下次就不用走網絡去獲取了。下面就會第一次緩存hbse.meta表的數據信息。
當大量的向某個分區表插入數據后，metaCache中就有下面的數據:
{hbase:meta={[B@e09300c=[region=hbase:meta,,1.1588230740, hostname=centos-reall-132,16020,1490876417048, seqNum=0]},
t_regin_demo={
[B@f01dde6=[region=t_regin_demo,10|,1480171499299.e94245285fb3fbfe3dd3bb7e9c632be8., hostname=centos-reall-132,16020,1490876417048, seqNum=50],
[B@438f2ebc=[region=t_regin_demo,20|,1480171499299.b9bee9aad30185f682d943172136966b., hostname=centos-reall-132,16020,1490876417048, seqNum=50],
[B@6d455b4a=[region=t_regin_demo,30|,1480171499299.144c892d9a29739d46c3561c431326ac., hostname=centos-reall-132,16020,1490876417048, seqNum=53],
[B@646c8f51=[region=t_regin_demo,40|,1480171499299.f5c53075ed5f26cf1001ffd7d12101d1., hostname=centos-reall-132,16020,1490876417048, seqNum=50],
[B@13354259=[region=t_regin_demo,50|,1480171499299.2d3eff976bd362e338be87e6eb8b8e42., hostname=centos-reall-132,16020,1490876417048, seqNum=50],
[B@d96eae9=[region=t_regin_demo,60|,1480171499299.67c0711ff634ad63a81e2d3c753cf9f6., hostname=centos-reall-132,16020,1490876417048, seqNum=50],
[B@2f186df7=[region=t_regin_demo,70|,1480171499299.78c04fabbb1fb9aebc4600ff653eb3d8., hostname=centos-reall-132,16020,1490876417048, seqNum=47],
[B@6cdb8b48=[region=t_regin_demo,80|,1480171499299.b7ae8e09ddea0faea2360897add9b18f., hostname=centos-reall-132,16020,1490876417048, seqNum=56],
[B@41955bcd=[region=t_regin_demo,90|,1480171499299.8ac30f51ea6143b509b84e62ed62db7a., hostname=centos-reall-132,16020,1490876417048, seqNum=50]}}