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