在運維hbase時，目前我們最為關注的主要是三大方面的狀況：
1. Cluster load；
2. 讀寫；
3. 磁碟空間。

1. Cluster load
叢集的load狀況直接反映了叢集的健康程度，load狀況的獲取非常容易，直接部署ganglia即可得到，由於hbase以優秀的可伸縮性著稱，因此多數情況下load超出接受範圍時加機器是一個不錯的解決方法，當然，這還和系統的設計和使用hbase的方式有關。
如有出現個別機器load比較高的現象，通常是由於叢集使用的不均衡造成，需要進行一定的處理，這個放到讀寫部分再說吧。

2. 讀寫
讀寫方面的資訊主要包括了讀寫的次數以及速度，這個通過ganglia看其實不怎麼方便，最好還是自己改造下實現，讀寫次數反映了叢集的使用程度，一般來說需要根據壓力測試中形成的報告來設定一個讀寫次數的閾值，以保護系統的穩定。

讀寫速度方面主要是顯示當前的讀寫速度狀況（當然，也需要有歷史的報表），如讀寫速度是在可接受範圍，其實就可以不用過多的關心了，如讀寫速度不OK的話，則需要進行一定的處理。

如讀速度不OK，則需要關注以下幾點：
* 叢集均衡嗎？
叢集是否均衡主要需要通過三個方面來判斷：各region server的region數是否均衡、table的region是否均衡分佈還有就是讀請求是否均衡分佈。

通常各region server的region數是均衡的，這個是目前hbase master的balance策略來保證的，頂多就是有短暫時間的不均衡現象。
table 的region分佈則不一定是均衡的，對於有多個table的情況，完全有可能出現某張表的一堆的region在同一臺上的現象，對於這種情況，一種方法 是修改master的balance策略，讓其在balance時考慮table的region的balance，我們目前採用的是另外一種方法，提供了 一個介面來手工balance table的region，如果是由於table的region不均衡導致了讀速度的不OK，可以採用這種辦法解決下。

讀 請求是否均衡分佈一方面取決於table的region的分佈狀況，另一方面則取決於應用的使用方法，如table的region分佈均衡，讀請求仍然不 均衡分佈的話，說明應用的請求有熱點的狀況，如這種狀況造成了讀速度的不OK，可以手工將region進行拆分，並分配到不同的region server上，這是hbase很簡單的一種應對熱點的解決方法。

* cache的命中率如何？
cache的命中率目前通過ganglia以及region server的log都不是很好看，因此我們也進行了改造，更直白的顯示cache的命中率的變化狀況。

如 cache的命中率不高，首先需要看下目前系統用於做LRUBlockcache的大小是不是比較小，這主要靠調整region server啟動的-Xmx以及hfile.block.cache.size引數來控制，可通過修改hbase-env.sh，增加export HBASE_REGIONSERVER_OPTS=”-Xmx16g”來單獨的調整region server的heap size，如LRUBlockCache已足夠大，cache命中率仍然不高的話，則多數情況是由於隨機讀無熱點造成的，這種情況如果要提升cache命 中率的話，就只能靠加機器了。
在cache的使用率上要關注應用對資料的讀取方式，經常整行資料讀取的適合設計在同一cf裡，不經常整行讀取的適合設計在多cf裡。

* bloomfilter打開了嗎？
默 認情況下建立的table是不開啟bloomfilter的（可通過describe table來確認，如看到BLOOMFILTER => ‘NONE’則表示未開啟），對於隨機讀而言這個影響還是比較明顯的，由於bloomfilter無法在之後動態開啟，因此建立表時最好就處理好，方法類 似如此：create ‘t1′, { NAME => ‘f1′, BLOOMFILTER => ‘ROWCOL’ }。

* Compact
在某些特殊的應用場景下，為了保證寫速度的平穩，可能會考慮不進行Compact，不進行compact會導致讀取資料時需要掃描大量的檔案，因此compact還是有必要做的。

* 應用的使用方式
應用在讀取資料時是隨機讀、有熱點的隨機讀還是連續讀，這個對讀速度也有很大的影響，這個需要結合業務進行分析，總的來說，hbase在隨機讀上效率還是很一般的，這和它的儲存結構有一定關係。
另外，應用在讀取時如每次都是讀取一行的所有資料的話，schema設計的時候在同一個cf下就比較合適。

如寫速度不OK，則需要關注以下幾點：
* 叢集均衡嗎？
除 了和讀一樣的叢集均衡性問題外，還有一個問題是rowKey的設計問題，因為hbase是按rowKey連續儲存的，因此如應用寫入資料時rowKey是 連續的，那麼就會造成寫的壓力會集中在單臺region server上，因此應用在設計rowKey時，要儘可能的保證寫入是分散的，當然，這可能會對有連續讀需求的場景產生一定的衝擊。

* 日誌中是否出現過以下資訊？
** Flush thread woke up with memory above low water.
日 志中出現這個資訊說明有部分寫出現過阻塞等待的現象，造成這個現象的原因是各個region的memstore使用的大小加起來超過了總的閾值，於是阻塞 並開始找一個region進行flush，這個過程會需要消耗掉一些時間，通常來說造成這個的原因是單臺region server上region數太多了，因此其實單臺region server上最好不要放置過多的region，一種調節方法是調大split的fileSize，這樣可以適當的減少region數，但需要關注調整後 讀效能的變化。

** delaying flush up to
當日志中出現這個資訊時，可能會造成出現下面的現象，從而產生影響，這個通常是store file太多造成的，通常可以調大點store file個數的閾值。

** Blocking updates for
當 日誌中出現這個資訊時，表示寫動作已被阻塞，造成這個現象的原因是memstore中使用的大小已超過其閾值的2倍，通常是由於上面的delaying flush up to造成的，或者是region數太多造成的，或者是太多hlog造成的，這種情況下會造成很大的影響，如記憶體夠用的話，可以調大閾值，如其他原因則需要 對症下藥。

* split造成的？
split會造成讀寫短暫的失敗，如寫的資料比較大的話，可能會有頻繁的split出現，對於這種情況主要需要依靠調大split的filesize（hbase.hregion.max.filesize）來控制。

3. 磁碟空間
磁 盤空間可直接通過hdfs的管理介面檢視，磁碟空間如佔用比較多的話，可以關注下表的壓縮是否開啟（describe表後，COMPRESSION => ‘NONE’表示未開啟），預設是不開啟的，在建立表時可create ‘t1′,{NAME => “cf1″,COMPRESSION => “LZO”}，如為已經建立的表，則需要先disable、alter、enable後再執行下major_compact，在我們的幾個案例中大概能壓 縮到原大小的20%–30%，還是很可觀的。

如壓縮已開啟，佔用仍然比較多的話，基本就只能增加機器或升級硬碟了，由於hbase需要對每列重複儲存rowkey，因此會有一定的空間浪費。