作者 | 個推大數據運維工程師 行者
升級背景
個推作為專業的數據智能服務商，在業務開展過程中存在海量的數據存儲與查詢的需求，為此個推選用了高可靠、高性能、面向列、可伸縮的分布式數據存儲系統——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的原因主要有以下幾點：
- 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主要包括以下幾個優化 ：
- 對BucketCache引用計數，避免讀取時的拷貝；
- 使用ByteBuffer做為服務端KeyValue的實現，從而使KeyValue可以存儲在offheap的內存中；
- 對BucketCache進行了一系列性能優化。
寫鏈路的offheap包括以下幾個優化：
- 在RPC層直接把網絡流上的KeyValue讀入offheap的bytebuffer中；
- 使用offheap的MSLAB pool；
- 使用支持offheap的Protobuf版本（3.0+）。
HBase2.0 的“坑”
V2.0.3之前版本不支持HBCK2
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.
建議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，與大家共同探討如何在生產環境中更好地對其進行使用。