關於HBase2.0的新特性，看這一篇文章就夠了！

做者 | 個推大數據運維工程師 行者

​

升級背景

個推做爲專業的數據智能服務商，在業務開展過程當中存在海量的數據存儲與查詢的需求，爲此個推選用了高可靠、高性能、面向列、可伸縮的分佈式數據存儲系統——HBase。

然而，運行HBase老集羣（使用HBase1.0版本）多年後，遇到了兩大問題：各節點基礎環境不一致；該集羣的服務器運行多年已過保。並且隨着個推業務量增加，性能方面也開始遇到瓶頸。通過綜合評估，個推決定將老集羣升級並遷移到HBase2.0新集羣以解決HBase老集羣存在的上述問題。

升級步驟

下面是個推升級並遷移的全步驟，供開發者參考。因爲整個過程將涉及多個部門且用時長，建議各位在操做的過程當中可讓各部門指定專人對接。

準備1：HBase表認領，找到全部表的讀寫應用與業務方；

準備2：HBase2.0新集羣部署，並打通到全部讀寫應用服務器的網絡；

調試3：測試環境調試應用，確認能正常使用HBase2.0集羣；

調試4：開發數據校驗工具，對遷移後新老集羣數據進行完整性校驗；

遷移5：全部表雙寫工程上線，並確認新老集羣寫入數據一致；

遷移6：全部讀取應用變動，遷移到新集羣，確認讀取正常；

收尾7：老集羣寫入工程中止，表禁用半個月，無異常後老集羣下線。

HBase2.0 新特性

2018年4月29日，HBase2.0發佈，共包含了4551個Issues。HBase2.0的新特性很是多，本次只介紹主要的幾個特性，更多內容見官網文檔。

[https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310753&version=12327188]

​

特性1：AssignmentManager V2

AMv1存在的問題及緣由分析

​

AMV1存在的主要問題是Regoins in Transition（RIT）。深度使用HBase的人通常都被 RIT困擾過，長時間的RIT簡直使人抓狂。一些RIT確實是因爲Region沒法被RegionServer open形成的，但大部分的RIT，都是AM自己的問題引發的。

引起RIT的緣由主要有如下幾點：

1. Region狀態變化複雜

Region open 的過程有7 個組件參與並涉及20 多個步驟，但越複雜的邏輯意味着越容易出 bug。

​

2.region 狀態多處緩存

Master 內存 、Meta 表、Zookeeper 都會保存 region 的狀態，Hbase1.0要求三者要保持徹底同步；

Master 和 RegionServer 都會修改 Meta 表的狀態和 Zookeeper 的狀態，這將很是容易致使region狀態出現混亂；

若是出現不一致，到底以哪裏的狀態爲準?

​

3.嚴重依賴 Zookeeper進行狀態通知

Region 狀態的通知徹底經過 Zookeeper，這致使了 region 的上線/下線的速度存在着必定的瓶頸。特別是在 region 比較多的時候，Zookeeper的通知會出現嚴重的滯後現象。

​

AMv2 的改進

主要的改進有如下四點：

1.region 每次狀態變化，會先記錄到 ProcedureWAL中，而後記錄在 Meta 表；

2.region 狀態信息只存放兩個地方：meta 表、HMaster 的內存，再也不存放Zookeeper；

3.只有 HMaster 才能夠更新 meta 表中的信息；

4.HMaster與RS直接進行狀態信息同步，去除Zookeeper依賴；

​

總體上來看，AMv2去除了 Zookeeper 依賴，有清晰明瞭的 region transition 機制，代碼的可讀性更強，很是有效地解決了RIT現象。

特性2：In-memory Flush & Compaction

HBase寫入流程中，數據會先寫入Memstore（內存中），達到閾值後，會觸發flush刷新，生成HFile文件落到磁盤中。須要注意的是MemStore的最小flush單元是‘HRegion’而不是單個MemStore，若是HRegion中Memstore過多，每次flush的IO開銷會很大。

​

HBase1.x 的問題

Memstore flush刷新的觸發條件不少，不過大多數對業務影響小，開發者無需擔憂。但若是觸發Region Server級別flush，將會致使整個 RS 執行 flush，阻塞全部落在該Region Server上的更新操做，並且阻塞時間很長，可能會達到分鐘級別，對業務影響很是大。

HBase2.0的改進

在2.0版本中，MemStore中的數據先Flush成一個Immutable的Segment，多個Immutable Segments能夠在內存中進行Compaction，當達到必定閾值之後纔將內存中的數據持久化成HDFS中的HFile文件。這就是2.0的新特性：In-memory Flush and Compaction ，並且該特性在2.0版本中已被默認啓用(系統表除外)。

好處1：減小數據量、下降磁盤 IO，不少表的列簇只保留1個版本；

好處2：Segment 來替代 ConcurrentSkipListMap數據結構存儲索引，節省空間，一樣的 MemStore 能夠存儲更多的數據。

​

特性3：Offheaping of Read/Write Path

HBase 服務讀寫數據較多依賴堆內內存實現，JVM採用的是stop-the-world的方式進行垃圾回收，很容易形成 JVM 進程由於 GC 而停頓時間比較長。 而HBase 是一個低延遲、對響應性要求比較高的系統，GC 很容易形成HBase 服務抖動、延遲高。

HBase社區解決GC延遲的思路是儘可能減小使用JVM 堆內內存，堆內內存使用減小了，GC也就隨着減小了，社區爲此支持了讀寫鏈路的offheap。

​

讀鏈路的offheap主要包括如下幾個優化 ：

1. 對BucketCache引用計數，避免讀取時的拷貝；

2. 使用ByteBuffer作爲服務端KeyValue的實現，從而使KeyValue能夠存儲在offheap的內存中；

3. 對BucketCache進行了一系列性能優化。

寫鏈路的offheap包括如下幾個優化：

1. 在RPC層直接把網絡流上的KeyValue讀入offheap的bytebuffer中；

2. 使用offheap的MSLAB pool；

3. 使用支持offheap的Protobuf版本（3.0+）。

HBase2.0 的「坑」

V2.0.3以前版本不支持HBCK2

<pre>

HBCK2 versions should be able to work across multiple hbase-2 releases. It will fail with a complaint if it is unable to run. There is no HbckService in versions of hbase before 2.0.3 and 2.1.1. HBCK2 will not work against these versions.

</pre>

建議HBase升級到V2.0.3或V2.1.1，詳情看HBCK2文檔。

[https://github.com/apache/hbase-operator-tools/tree/master/hbase-hbck2]

重度依賴Procedure V2

AMv2之因此能保持簡潔高效的一個重要緣由就是其重度依賴了Procedure V2，把一些複雜的邏輯都轉移到了Procedure V2中。可是這樣作的問題是：一旦ProcedureWAL出現了損壞，這個後果就是災難性的。固然，小編相信通過一段時間的bug修復和完善後，這些問題將不復存在。

HBase做爲個推大數據一項重要的基礎服務，性能的好壞影響重大。個推將HBase1.0升級到了HBase2.0版本後，在可靠性、安全性方面都有了很大提高，有效解決了1.0版本中的多種問題。將來，個推將會持續關注HBase 2.0，與你們共同探討如何在生產環境中更好地對其進行使用。

​