摘要：經過了四年的發展歷程，HBase 2.0終於發布上線，其增加了很多的新特性，能夠更好地適應更多的場景，但是也有一些原本計劃的特性並沒有隨之上線。在未來的HBase 3.0版本中，又有哪些特性能夠增加進來呢？本文中，技術大牛將論道HBase 3.0那些可能的新特性。

其實，開源社區一直在反思為什麽HBase 2.0經歷了那麽長的時間還是沒有發布出來。社區也不希望在發布HBase 3.0版本的時候還是和發布HBase 2.0遇到同樣的情況。所以雖然目前主要的精力還是放在2.X版本，想要將其變得更加穩定，但是HBase 3.0也已經開始計劃了。本文的主要內容就是把HBase 3.0版本中可能的上線的feature先列出來，之後再出現對於其他新feature的需求如果來不及就不再往HBase 3.0裏面放了，這也是為了讓HBase 3.0能夠盡快發布出來。

同步復制

第一個特性就是同步復制，這裏指的是支持雙機房的強同步。之前HBase是無法跨機房進行部署的，基本上就是在同一個機房裏面進行部署，多機房部署中間所造成的延遲可能無法承受。所以同步復制可以支持兩個機房之間的強同步，而原來的HBase 2.0是異步的，這個機房是主集群，另外一個是備用集群，兩者之間存在幾秒的延遲，一旦主機群發生宕機的話，那麽備用集群的數據不一定是完整的，這個特性主要解決的就是讓備用集群起來變成主機群的時候與之前的主集群所確認過的數據是一致的，至於這些具體是如何實現的，可以參考阿裏在HBaseCon Asia2017上的演講，阿裏在內部做過一個版本，而HBase 3.0就是將這個特性做到社區裏面去，在2018年的HBaseCon上也會進行詳細地講解。目前在社區中，在HBASE-19064上已經基本上可以使用同步復制了。綜上所述，同步復制這個特性在HBase 3.0中一定能夠出現。

CCSMap

CCSMap主要解決的就是GC問題，原來的HBase會把實際的數據放到2M的Chunk裏面去，但是ConcurrentSkipList來做索引，那麽讀取一個對象在哪就需要先去ConcurrentSkipList找一下並去Chunk裏面讀取，這樣一來因為現在的機器內存都已經很大了可能達到128G內存，而MapStore也能達到幾十G，這樣一來每個Value都可能成千上萬甚至幾千萬個對象，這些對象都堆在ConcurrentSkipList裏面，GC進行掃描則是非常耗費時間的。目前阿裏的團隊已經在內部實現將索引放到Chunk裏面，所有的數據都是encode到Chunk裏面去的，這樣一來對象的數量能夠減少很多，GC的負擔也能大大減輕，這樣一來在Java堆上的東西就會很小了，可能就不需要那麽多的調整GC參數的策略了。目前HBASE-20312也已經在做這件事情了。

備份&恢復

備份和恢復本來是在HBase 2.0版本要加進去的，但是後來去除掉了。這個就是比較強的一致性，其支持增量備份。目前冷備份就是打一個Snapshot然後考上去，考到另外一個異構的文件系統上去，然後過一段時間再打一個Snapshot再繼續拷貝。這樣實現的好處是比較簡單，不容易出問題。但是可能對於空間的浪費比較嚴重。而備份和增量特性則是在打完Snapshot之後通過Log一點點進行備份，這樣就不會有太多空間的浪費，這一部分目前的代碼質量不是特別好，因此在2.0版本沒有讓它上，而是否能夠在3.0版本中增加也不好確定，因為還需要進一步優化和測試。

讀路徑重構

讀路徑優化這個工作目前還沒有開始，但是已經有很多人提出過類似的問題了，就是HBase的讀路徑太過於復雜，發現有些優化的位置不太對，導致這部分的代碼比較亂，如果現在不再進行整理可能之後就沒有人敢去觸碰這部分代碼了。常見的一個優化就是在一個流上Seek，如果發現Seek的點離自己很近，那麽就不需要重新Seek一遍把指針放到那裏去，只需要直接往後讀取一段就可以了。現在的問題是雖然HBase也有這樣的優化，但是在開啟Scanner的時候，比如Filter需要跳過這一行會返回到Seek到下一行，但是到底是Seek到下一行還是Skip到下一行將會視情況進行，如果距離很近就會Seek過去，如果距離很遠就會Skip過去。

這一層在實現的時候是在StoreFileScanner這一層實現的，這是比較頭疼的，因為StoreFileScanner是很多個StoreFile在Merge之後形成的，在這一層進行判斷的時候比較討厭的一點就是下面有好多個文件，所以判斷並不一定非常準確。更正常的是應該由StoreFileScanner決定要Seek到哪裏，進而判斷要Seek到的位置有多遠，然後讓自己決定到底是Seek還是Skip。所以對於同一個StoreFileScanner而言，下面很多個StoreFile，有的需要Seek，有些需要Skip。在StoreFileScanner這一層決定使用pread還是stream read，熟悉HDFS的同學可能知道如果開啟HDFS的stream read，那麽就會不停地發送數據，pread的好處就是往HDFS發送請求的時候會說從哪個位置開始讀取哪一段，當讀取完畢之後就不會再發了。pread的連接用完之後可以放回到連接庫中去，下次有人需要可以重用這個連接。如果使用stream read可能讀取出來少了4K數據，那麽就不讀取了，那麽這個連接也就廢掉了，只能關閉了。其實在HBase 1.X版本中Scan有一個參數是setSmall，如果不是用small就默認使用stream read，如果setSmall就是使用pread。目前HBase 2.0做了一個適配默認開始時都是想要使用pread，當發現讀取過長之後切換成stream read，但是其實這與上面存在同樣的問題，因為其也是在StoreScanner層做的，所以問題也很多，有一些文件pread流，有的則是用stream read流。

還有一個很嚴重的問題就是減少不必要的bytes比較，看過HBase源碼的人就會比較熟悉，特別是Filter裏面需要切換了rowkey，這種情況下需要先比較一下，但是可能之前在其他地方已經比較過了，但是再需要比較的時候拿不到信息。其實這部分測試過，這樣的比較浪費了大量的CPU資源，對於性能的影響是比較大的。所以這部分需要想一些辦法盡量減少不必要的bytes比較，一個可能的辦法是向Scanner的Context裏面放一些東西，之後從Context裏面取數據，這樣在切換之後如果沒有比較過就比較一下，之後就存儲下來，就不需要比較了。還有一個問題就是保證每次讀完一個cell，RegionScanner都有機會退出，也就是保證heartbeat一定能生效，這個在HBase 1.X版本中已經上線了。這裏heartbeat的意思就是可能設置了Filter很稀疏，可能很久都不能掃描到有用的數據返回給你，但是Client卻有Timeout，為了防止過了Timeout所以會返回沒有掃描到數據的提示信息，需要做這樣一個事情，所以一開始發現的最大問題就是Filter退不出來，一直在掃描，還來不及發送heartbeat就已經超時了。之前做過一件事情就是Filter可以跳出來，但是目前代碼裏面還有一些問題就是讀取Excel還不能跳出來，這方面也需要進行改進，否則在真正實現的時候就會失效了。這部分是主要提出的問題，目前還沒有具體的工作還沒有開始實現。

寫路徑重構

目前一些團隊對於寫路徑優化上做了一些工作，看起來效果基本上還可以。基本上就是用Staged Event Driven的架構實現，這裏的寫路徑相比於讀路徑要簡單很多，這是因為讀路徑最主要的具有Filter，這就導致了讀路徑的邏輯會復雜很多。而寫路徑則比較清晰了，先寫出readlog，成功之後更新memstore並在最後complete mvcc就完成了。這樣的改造使得需要的線程數會更少一些，而之前就是一個線程從頭跑到尾，寫readlog時如果沒有寫過來，就會一直在這裏堵著等待，之後的更新memstore並在最後complete mvcc也會堵在這裏等，所以線程很多時間都是什麽事情都沒幹的，改成Staged之後線程需要的就會更少一些，性能就會更好一些。寫路徑比讀路徑更加清晰和簡單，但是寫路徑需要註意的一點就是絕對不能出現Bug，讀路徑出現Bug可能只是數據讀不到，但是如果寫路徑出現Bug寫入的數據就丟到了。

其他Feature

其實還有一些其他的Feature本在也在HBase 2.0版本中計劃上線，但是因為HBase 2.0版本計劃了太多的新特性，因此不得不將這些特性拿出去，不然就更加發布不出來了。這些特性其一是C++ Client，這個基本上有一個可用的版本了，但是還需要後續的測試包裝等步驟。其二是HLC，Google是使用原子鐘在所有機器上面做了一套硬件，所以拿到的是時鐘誤區基本差不多，時間誤差允許範圍內。而HLC是在沒有這樣的硬件條件下，依靠NCP實現各個機器之間的時間同步，HBase是想把Timestrap類似的東西用HLC實現。還有一個是Spark的Connecter，這個可以幫助Spark實現一些計算的下推，這部分在Master分支中也是有的，只不過因為沒有完成所以沒有出現在HBase 2.0版本中。但是這些特性並不一定都能夠在HBase 3.0中上線。
原文鏈接請添加鏈接描述

本文為雲棲社區原創內容，未經允許不得轉載。

技術大牛論道HBase 3.0 可能的新特性