主要內(nèi)容：

HBASE介紹

HBASE數(shù)據(jù)熱點

HBASE常見故障處理

HBASE壓縮

1.1關(guān)系型數(shù)據(jù)庫和非關(guān)系型數(shù)據(jù)庫

1.2關(guān)系型數(shù)據(jù)庫和hbase的區(qū)別

1、數(shù)據(jù)類型：關(guān)系數(shù)據(jù)庫采用關(guān)系模型，具有豐富的數(shù)據(jù)類型和存儲方式，HBase則采用了更加簡單的數(shù)據(jù)模型，它把數(shù)據(jù)存儲為未經(jīng)解釋的字符串。

2、數(shù)據(jù)操作：關(guān)系數(shù)據(jù)庫中包含了豐富的操作，其中會涉及復雜的多表連接。HBase操作則不存在復雜的表與表之間的關(guān)系，只有簡單的插入、查詢、刪除、清空等，因為HBase在設(shè)計上就避免了復雜的表和表之間的關(guān)系。

3、存儲模式：關(guān)系數(shù)據(jù)庫是基于行模式存儲的。HBase是基于列存儲的。

4、數(shù)據(jù)索引：關(guān)系數(shù)據(jù)庫通常可以針對不同列構(gòu)建復雜的多個索引，以提高數(shù)據(jù)訪問性能。HBase只有一個索引——Rowkey。

5、數(shù)據(jù)維護：在關(guān)系數(shù)據(jù)庫中，更新操作會用最新的當前值去替換記錄中原來的舊值，舊值被覆蓋后就不會存在。而在HBase中執(zhí)行更新操作時，并不會刪除數(shù)據(jù)舊的版本，而是生成一個新的版本，舊有的版本仍然保留。

6、可伸縮性：關(guān)系數(shù)據(jù)庫很難實現(xiàn)橫向擴展，縱向擴展的空間也比較有限。相反，HBase和BigTable這些分布式數(shù)據(jù)庫就是為了實現(xiàn)靈活的水平擴展而開發(fā)的，能夠輕易地通過在集群中增加或者減少硬件數(shù)量來實現(xiàn)性能的伸縮

1.3 HABSE架構(gòu)變化

HBASE 1.0以前



HBASE1.0以后




[
2.HBASE數(shù)據(jù)熱點
]




2.1 HABSE Rowkey

HBase 表的數(shù)據(jù)是按照Rowkey來分散到不同Region，不合理的Rowkey設(shè)計會導致熱點問題。熱點問題是大量的Client直接訪問集群的一個或極少數(shù)個節(jié)點，而集群中的其他節(jié)點卻處于相對空閑狀態(tài)。




Hbase是根據(jù)Rowkey來進行檢索的，檢索支持3種方式：

1、通過單Rowkey訪問，即按照某個Rowkey鍵值進行g(shù)et操作，獲取唯一記錄。




2、通過Rowkey的range進行scan,即通過是指startRowkey和endRowkey，在這個范圍進行掃描。這樣可以指定條件獲取一批記錄。




3、全表掃描，即直接掃描整張表中所有的記錄。（該方法效率特別低）




2.2 Hbase如何避免數(shù)據(jù)熱點

1、salting(加鹽)

在Rowkey前面加入隨機數(shù)，具體就是給Rowkey前面分配一個隨機前綴，以使得它和之前的排序不同。但是會對寫造成了一定的負面影響，會增加寫時的吞吐量。




2、加入Hashing

Hashing的原理就是計算Rowkey的hash值，然后取hash的部分字符和原來的Rowkey進行拼接。這里的hash包含比如MD5這種類似的算法。




3、Reversing(反轉(zhuǎn))    

Reversing的原理是反轉(zhuǎn)一段固定長度或者全部的鍵。




4、Rowkey的長度。

Rowkey可以是任意字符，越短越好，但是不要超過16個字節(jié)，存為byte[]字節(jié)數(shù)組，一般設(shè)計成定長。




[
3.HBASE常見故障及處理
]




3.1RegionServer異常下線

regionserver進程時常出現(xiàn)異常下線的情況




檢查分析：

（1）檢查日志



（2）該主機收到的告警短信



該主機出現(xiàn)某個磁盤寫數(shù)據(jù)繁忙的情況，出現(xiàn)這類情況就要從datanode入手（因為該磁盤sdg為datanode數(shù)據(jù)盤）。




（3）檢查對比nmon日志





圖一為問題主機DISKBUYS報表圖，由圖一wavg偏高，說明磁盤的繁忙程度相比于同一集群的其他主機更高。




（4）根據(jù)nmon圖分析為主機磁盤問題



通知主機方檢查主機，最終檢查出其中一個hadoop數(shù)據(jù)盤有問題，更換完后問題解決，如上圖可以看出之前壞的主機nmon的DISKBUYS無異常。




3.2 Hbase請求異常

1、查看Hbaseui

通過hbaseui界面查看hbase請求量大部分時間處于10000以下，甚至還在幾百（此集群平時正常時候請求量大部分在7w-12w左右）




2、日志信息

Numberof regions in transition: 0...ERROR: RegionServer:xxx主機,2302,1546020590497Unable to fetch region information.org.apache.hadoop.net.ConnectTimeoutException: 20000 millis timeoutwhile waiting for channel to be ready for connect. ch :java.nio.channels.SocketChannel[connection-pendingremote=主機名/ip:2302]

(體現(xiàn)為regionserver無法提供handler為master提供信息。導致同步meta表出錯。)




3、通過netstat-anp|grep 2302 命令查看鏈接狀況出現(xiàn)SYN_RECV（半連接）






4、問題處理過程

登錄堡壘機，執(zhí)行 hbase hbck，查看有無 ConnectTimeoutException 報錯，如發(fā)現(xiàn)相關(guān)報錯,保留頁面信息，訪問問題主機ip:2301頁面，右鍵另存為當前網(wǎng)頁，點擊界面Debugdump和MetricsDump鏈接分別保存信息，登錄故障主機，保留信息，通過netstat-anp|grep2302查看連接狀態(tài)，通過jps查看regionserver進程，jstack -l rsPID >/tmp/jstack.${time}，如果發(fā)現(xiàn)報錯，登錄rstimeout主機通過hbase-daemon.shstopregionserver停止regionserver,觀察請求量是否恢復,待集群恢復正常后，討論是否重新拉起故障regionserver。




[
4.Hbase壓縮
]




1、情景再現(xiàn)  

采用壓縮優(yōu)化解決方案，用最少的投資承載更多的數(shù)據(jù)存儲，實現(xiàn)降本增效的目標，適用于類似此種一次寫入、少量查詢的溫冷數(shù)據(jù)場景。入庫時采用SNAPPY壓縮，不影響數(shù)據(jù)入庫效率，在業(yè)務(wù)閑時，修改數(shù)據(jù)壓縮方式為GZ，降低存儲資源消耗。




2、具體實現(xiàn)步驟

（1）disablesnappy_test

（2）altersnappy_test ,NAME=>cf,COMPRESSION => GZ

（3）enablesnappy_test

（4）major_compactsnappy_test




3、測試結(jié)果

表名	壓縮前大?。╯nappy）	壓縮后大?。℅Z)	壓縮比	壓縮時間
snappy_test	380.9G	207.5G	大約35%	大約1小時15分鐘major完全執(zhí)行完