前言：在系統(tǒng)中向hbase中插入數(shù)據(jù)時，常常通過設(shè)置region的預(yù)分區(qū)來防止大數(shù)據(jù)量插入的熱點問題，提高數(shù)據(jù)插入的效率，同時可以減少當(dāng)數(shù)據(jù)猛增時由于Region split帶來的資源消耗。大量的預(yù)分區(qū)數(shù)量會導(dǎo)致hbase客戶端緩存大量的分區(qū)地址，導(dǎo)致內(nèi)存的增長，某些系統(tǒng)中一個JVM進程中會開啟幾十個獨立的hbase客戶端對象，同時會查詢多張Hbase表，這樣JVM進程就會緩存 (預(yù)分區(qū)數(shù) X 表數(shù) X Hbase客戶端數(shù)=條記錄)。
有沒有這種情況?有的，在本人的storm項目中，采用結(jié)合spring注入的方式來結(jié)合Hbase向hbase存入數(shù)據(jù)，storm中的每一個線程都會創(chuàng)建一個XmlBeanDefinitionReader對象來加載spring的配置文件，所以一個線程就有一個hbse客戶端對象了，同時Hbase表設(shè)置102預(yù)分區(qū)，一個topology會操作最少8張表，一個worker會走20個task。所以一個work會緩存大約102*8*20=16320條記錄，每一條記錄的數(shù)據(jù)格式大致就是hbase.meta的一條數(shù)據(jù)格式，經(jīng)過我計算16000多條記錄一個JVM中占用內(nèi)存也就5M多，對內(nèi)存的消耗是完全可以忽略不計的。這就很尷尬了。這種優(yōu)化只是對于大規(guī)模的集群來說有效果，小規(guī)模集群考慮這種情況是過度設(shè)計了。比如那種Hbase客戶端會有緩存一整張hbase.meta表數(shù)據(jù)的系統(tǒng)又或者那種hbase表分區(qū)達到上萬的系統(tǒng)，那么一個woeker中地址的緩存會達到幾百兆，這個時候從原理上就可以進行設(shè)計了來節(jié)省資源消耗，想想可以省好多臺服務(wù)器。
原文和作者一起討論:http://www.cnblogs.com/intsmaze/p/6648834.html
微信：intsmaze
說了這么多，如何來進行系統(tǒng)資源優(yōu)化？可以結(jié)合storm的自定義分區(qū)，不再使用storm提供的分組策略，我們把作用于hbase的散列算法來作為storm的分組策略，就可以得到storm的task與hbase的預(yù)分區(qū)一一對應(yīng)了。
以前的系統(tǒng)：
網(wǎng)友評論
