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

[[179446]]

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

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

1. Cluster load

集群的load狀況直接反映了集群的健康程度，load狀況的獲取非常容易，直接部署ganglia即可得到，由于hbase以優(yōu)秀的可伸縮性著稱，因此多數(shù)情況下load超出接受范圍時加機器是一個不錯的解決方法，當(dāng)然，這還和系統(tǒng)的設(shè)計和使用hbase的方式有關(guān)。

如有出現(xiàn)個別機器load比較高的現(xiàn)象，通常是由于集群使用的不均衡造成，需要進行一定的處理，這個放到讀寫部分再說吧。

2. 讀寫

讀寫方面的信息主要包括了讀寫的次數(shù)以及速度，這個通過ganglia看其實不怎么方便，***還是自己改造下實現(xiàn)，讀寫次數(shù)反映了集群的使用程度，一般來說需要根據(jù)壓力測試中形成的報告來設(shè)置一個讀寫次數(shù)的閾值，以保護系統(tǒng)的穩(wěn)定。

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

如讀速度不OK，則需要關(guān)注以下幾點：

* 集群均衡嗎?

集群是否均衡主要需要通過三個方面來判斷：各region server的region數(shù)是否均衡、table的region是否均衡分布還有就是讀請求是否均衡分布。

通常各region server的region數(shù)是均衡的，這個是目前hbase master的balance策略來保證的，頂多就是有短暫時間的不均衡現(xiàn)象。

table 的region分布則不一定是均衡的，對于有多個table的情況，完全有可能出現(xiàn)某張表的一堆的region在同一臺上的現(xiàn)象，對于這種情況，一種方法 是修改master的balance策略，讓其在balance時考慮table的region的balance，我們目前采用的是另外一種方法，提供了 一個界面來手工balance table的region，如果是由于table的region不均衡導(dǎo)致了讀速度的不OK，可以采用這種辦法解決下。

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

* cache的***率如何?

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

如 cache的***率不高，首先需要看下目前系統(tǒng)用于做LRUBlockcache的大小是不是比較小，這主要靠調(diào)整region server啟動的-Xmx以及hfile.block.cache.size參數(shù)來控制，可通過修改hbase-env.sh，增加export HBASE_REGIONSERVER_OPTS=”-Xmx16g”來單獨的調(diào)整region server的heap size，如LRUBlockCache已足夠大，cache***率仍然不高的話，則多數(shù)情況是由于隨機讀無熱點造成的，這種情況如果要提升cache***率的話，就只能靠加機器了。

在cache的使用率上要關(guān)注應(yīng)用對數(shù)據(jù)的讀取方式，經(jīng)常整行數(shù)據(jù)讀取的適合設(shè)計在同一cf里，不經(jīng)常整行讀取的適合設(shè)計在多cf里。

* bloomfilter打開了嗎?

默 認(rèn)情況下創(chuàng)建的table是不打開bloomfilter的(可通過describe table來確認(rèn)，如看到BLOOMFILTER => ‘NONE’則表示未打開)，對于隨機讀而言這個影響還是比較明顯的，由于bloomfilter無法在之后動態(tài)打開，因此創(chuàng)建表時***就處理好，方法類 似如此：create ‘t1′, { NAME => ‘f1′, BLOOMFILTER => ‘ROWCOL’ }。

* Compact

在某些特殊的應(yīng)用場景下，為了保證寫速度的平穩(wěn)，可能會考慮不進行Compact，不進行compact會導(dǎo)致讀取數(shù)據(jù)時需要掃描大量的文件，因此compact還是有必要做的。

* 應(yīng)用的使用方式

應(yīng)用在讀取數(shù)據(jù)時是隨機讀、有熱點的隨機讀還是連續(xù)讀，這個對讀速度也有很大的影響，這個需要結(jié)合業(yè)務(wù)進行分析，總的來說，hbase在隨機讀上效率還是很一般的，這和它的存儲結(jié)構(gòu)有一定關(guān)系。

另外，應(yīng)用在讀取時如每次都是讀取一行的所有數(shù)據(jù)的話，schema設(shè)計的時候在同一個cf下就比較合適。

如寫速度不OK，則需要關(guān)注以下幾點：

* 集群均衡嗎?

除 了和讀一樣的集群均衡性問題外，還有一個問題是rowKey的設(shè)計問題，因為hbase是按rowKey連續(xù)存儲的，因此如應(yīng)用寫入數(shù)據(jù)時rowKey是 連續(xù)的，那么就會造成寫的壓力會集中在單臺region server上，因此應(yīng)用在設(shè)計rowKey時，要盡可能的保證寫入是分散的，當(dāng)然，這可能會對有連續(xù)讀需求的場景產(chǎn)生一定的沖擊。

* 日志中是否出現(xiàn)過以下信息?

** Flush thread woke up with memory above low water.

日 志中出現(xiàn)這個信息說明有部分寫出現(xiàn)過阻塞等待的現(xiàn)象，造成這個現(xiàn)象的原因是各個region的memstore使用的大小加起來超過了總的閾值，于是阻塞 并開始找一個region進行flush，這個過程會需要消耗掉一些時間，通常來說造成這個的原因是單臺region server上region數(shù)太多了，因此其實單臺region server上***不要放置過多的region，一種調(diào)節(jié)方法是調(diào)大split的fileSize，這樣可以適當(dāng)?shù)臏p少region數(shù)，但需要關(guān)注調(diào)整后 讀性能的變化。

** delaying flush up to

當(dāng)日志中出現(xiàn)這個信息時，可能會造成出現(xiàn)下面的現(xiàn)象，從而產(chǎn)生影響，這個通常是store file太多造成的，通常可以調(diào)大點store file個數(shù)的閾值。

** Blocking updates for

當(dāng) 日志中出現(xiàn)這個信息時，表示寫動作已被阻塞，造成這個現(xiàn)象的原因是memstore中使用的大小已超過其閾值的2倍，通常是由于上面的delaying flush up to造成的，或者是region數(shù)太多造成的，或者是太多hlog造成的，這種情況下會造成很大的影響，如內(nèi)存夠用的話，可以調(diào)大閾值，如其他原因則需要 對癥下藥。

* split造成的?

split會造成讀寫短暫的失敗，如寫的數(shù)據(jù)比較大的話，可能會有頻繁的split出現(xiàn)，對于這種情況主要需要依靠調(diào)大split的filesize(hbase.hregion.max.filesize)來控制。

3. 磁盤空間

磁盤空間可直接通過hdfs的管理界面查看，磁盤空間如占用比較多的話，可以關(guān)注下表的壓縮是否開啟(describe表后，COMPRESSION => ‘NONE’表示未開啟)，默認(rèn)是不開啟的，在創(chuàng)建表時可create ‘t1′,{NAME => “cf1″,COMPRESSION => “LZO”}，如為已經(jīng)創(chuàng)建的表，則需要先disable、alter、enable后再執(zhí)行下major_compact，在我們的幾個案例中大概能壓 縮到原大小的20%–30%，還是很可觀的。

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

【本文為51CTO專欄作者“王森豐”的原創(chuàng)稿件，轉(zhuǎn)載請注明出處】