NoSQL現在風生水起，hbase的使用也越來越廣，但目前幾乎所有的NoSQL產品在運維上都沒法和DB相提并論，在這篇文章中來總結下我們在運維hbase時的一些問題以及解決的方法，也希望得到更多hbase同行們的建議，:)

[[179446]]

在運維hbase時，目前我們最為關注的主要是三大方面的狀況：

• Cluster load;
• 讀寫;
• 磁盤空間。

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，因此會有一定的空間浪費。

【本文為51CTO專欄作者“王森豐”的原創稿件，轉載請注明出處】