NoSQL現在風生水起，hbase的使用也越來越廣，但目前幾乎所有的NoSQL產品在運維上都沒法和DB相提並論，在這篇blog中來總結下我們在運維hbase時的一些問題以及解決的方法，也希望得到更多hbase同行們的建議，:)
在運維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，因此會有一定的空間浪費。
另外，在運維hbase時，有幾個重點的穩定性相關的patch需要處理下：
1. namenode crash的數據丟失；
詳細見： https://issues.apache.org/jira/browse/HBASE-3722
2. master恢復速度過慢；
詳細請見：https://issues.apache.org/jira/browse/HBASE-1364
這個會造成出現故障時恢復時間過長。
ps: 引以為榮下，這個patch是facebook提交的，然後我們team的竹莊同學改進了下並且已被官方接受，:)
3. backup master不自動接管；
詳細請見： https://issues.apache.org/jira/browse/HBASE-3988
4. os crash的話有丟失數據的風險；
hlog寫入的時候只是寫到了os cache，如os crash了的話仍然有丟失數據的可能，需要修改hdfs寫入的方法才能修復，目前無官方patch。
