storm自定義分組與Hbase預分區結合節省內存消耗

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的預分區一一對應了。

原文和做者一塊兒討論:http://www.cnblogs.com/intsmaze/p/6648834.html

之前的系統

 

　　

 

　　消息進來了之後，由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]}}