作者 | 個推大資料運維工程師  行者

升級背景

個推作為專業的資料智慧服務商，在業務開展過程中存在海量的資料儲存與查詢的需求，為此個推選用了高可靠、高效能、面向列、可伸縮的分散式資料儲存系統——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的新特性非常多，本次只介紹主要的幾個特性，更多內容見官網文件。

 

特性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，與大家共同探討如何在生產環境中更好地對其進行使用。

相關推薦