主要內容：

HBASE介紹

HBASE數據熱點

HBASE常見故障處理

HBASE壓縮

1.1關系型數據庫和非關系型數據庫

1.2關系型數據庫和hbase的區別

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

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

3、存儲模式：關系數據庫是基于行模式存儲的。HBase是基于列存儲的。

4、數據索引：關系數據庫通常可以針對不同列構建復雜的多個索引，以提高數據訪問性能。HBase只有一個索引——Rowkey。

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

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

1.3 HABSE架構變化

HBASE 1.0以前



HBASE1.0以后




[
2.HBASE數據熱點
]




2.1 HABSE Rowkey

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




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

1、通過單Rowkey訪問，即按照某個Rowkey鍵值進行get操作，獲取唯一記錄。




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




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




2.2 Hbase如何避免數據熱點

1、salting(加鹽)

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




2、加入Hashing

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




3、Reversing(反轉)    

Reversing的原理是反轉一段固定長度或者全部的鍵。




4、Rowkey的長度。

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




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




3.1RegionServer異常下線

regionserver進程時常出現異常下線的情況




檢查分析：

（1）檢查日志



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



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




（3）檢查對比nmon日志





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




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



通知主機方檢查主機，最終檢查出其中一個hadoop數據盤有問題，更換完后問題解決，如上圖可以看出之前壞的主機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]

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




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






4、問題處理過程

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




[
4.Hbase壓縮
]




1、情景再現  

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




2、具體實現步驟

（1）disablesnappy_test

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

（3）enablesnappy_test

（4）major_compactsnappy_test




3、測試結果

表名	壓縮前大小（snappy）	壓縮后大小（GZ)	壓縮比	壓縮時間
snappy_test	380.9G	207.5G	大約35%	大約1小時15分鐘major完全執行完