技術(shù)大牛論道HBase 3.0 可能的新特性

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

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

本文內(nèi)容根據(jù)演講視頻以及PPT整理而成。

PPT下載地址，請戳這里！

其實(shí)，開源社區(qū)一直在反思為什么HBase 2.0經(jīng)歷了那么長的時(shí)間還是沒有發(fā)布出來。社區(qū)也不希望在發(fā)布HBase 3.0版本的時(shí)候還是和發(fā)布HBase 2.0遇到同樣的情況。所以雖然目前主要的精力還是放在2.X版本，想要將其變得更加穩(wěn)定，但是HBase 3.0也已經(jīng)開始計(jì)劃了。本文的主要內(nèi)容就是把HBase 3.0版本中可能的上線的feature先列出來，之后再出現(xiàn)對(duì)于其他新feature的需求如果來不及就不再往HBase 3.0里面放了，這也是為了讓HBase 3.0能夠盡快發(fā)布出來。

同步復(fù)制

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

CCSMap

CCSMap主要解決的就是GC問題，原來的HBase會(huì)把實(shí)際的數(shù)據(jù)放到2M的Chunk里面去，但是ConcurrentSkipList來做索引，那么讀取一個(gè)對(duì)象在哪就需要先去ConcurrentSkipList找一下并去Chunk里面讀取，這樣一來因?yàn)楝F(xiàn)在的機(jī)器內(nèi)存都已經(jīng)很大了可能達(dá)到128G內(nèi)存，而MapStore也能達(dá)到幾十G，這樣一來每個(gè)Value都可能成千上萬甚至幾千萬個(gè)對(duì)象，這些對(duì)象都堆在ConcurrentSkipList里面，GC進(jìn)行掃描則是非常耗費(fèi)時(shí)間的。目前阿里的團(tuán)隊(duì)已經(jīng)在內(nèi)部實(shí)現(xiàn)將索引放到Chunk里面，所有的數(shù)據(jù)都是encode到Chunk里面去的，這樣一來對(duì)象的數(shù)量能夠減少很多，GC的負(fù)擔(dān)也能大大減輕，這樣一來在Java堆上的東西就會(huì)很小了，可能就不需要那么多的調(diào)整GC參數(shù)的策略了。目前HBASE-20312也已經(jīng)在做這件事情了。

備份&恢復(fù)

備份和恢復(fù)本來是在HBase 2.0版本要加進(jìn)去的，但是后來去除掉了。這個(gè)就是比較強(qiáng)的一致性，其支持增量備份。目前冷備份就是打一個(gè)Snapshot然后考上去，考到另外一個(gè)異構(gòu)的文件系統(tǒng)上去，然后過一段時(shí)間再打一個(gè)Snapshot再繼續(xù)拷貝。這樣實(shí)現(xiàn)的好處是比較簡單，不容易出問題。但是可能對(duì)于空間的浪費(fèi)比較嚴(yán)重。而備份和增量特性則是在打完Snapshot之后通過Log一點(diǎn)點(diǎn)進(jìn)行備份，這樣就不會(huì)有太多空間的浪費(fèi)，這一部分目前的代碼質(zhì)量不是特別好，因此在2.0版本沒有讓它上，而是否能夠在3.0版本中增加也不好確定，因?yàn)檫€需要進(jìn)一步優(yōu)化和測試。

讀路徑重構(gòu)

讀路徑優(yōu)化這個(gè)工作目前還沒有開始，但是已經(jīng)有很多人提出過類似的問題了，就是HBase的讀路徑太過于復(fù)雜，發(fā)現(xiàn)有些優(yōu)化的位置不太對(duì)，導(dǎo)致這部分的代碼比較亂，如果現(xiàn)在不再進(jìn)行整理可能之后就沒有人敢去觸碰這部分代碼了。常見的一個(gè)優(yōu)化就是在一個(gè)流上Seek，如果發(fā)現(xiàn)Seek的點(diǎn)離自己很近，那么就不需要重新Seek一遍把指針放到那里去，只需要直接往后讀取一段就可以了。現(xiàn)在的問題是雖然HBase也有這樣的優(yōu)化，但是在開啟Scanner的時(shí)候，比如Filter需要跳過這一行會(huì)返回到Seek到下一行，但是到底是Seek到下一行還是Skip到下一行將會(huì)視情況進(jìn)行，如果距離很近就會(huì)Seek過去，如果距離很遠(yuǎn)就會(huì)Skip過去。

這一層在實(shí)現(xiàn)的時(shí)候是在StoreFileScanner這一層實(shí)現(xiàn)的，這是比較頭疼的，因?yàn)镾toreFileScanner是很多個(gè)StoreFile在Merge之后形成的，在這一層進(jìn)行判斷的時(shí)候比較討厭的一點(diǎn)就是下面有好多個(gè)文件，所以判斷并不一定非常準(zhǔn)確。更正常的是應(yīng)該由StoreFileScanner決定要Seek到哪里，進(jìn)而判斷要Seek到的位置有多遠(yuǎn)，然后讓自己決定到底是Seek還是Skip。所以對(duì)于同一個(gè)StoreFileScanner而言，下面很多個(gè)StoreFile，有的需要Seek，有些需要Skip。在StoreFileScanner這一層決定使用pread還是stream read，熟悉HDFS的同學(xué)可能知道如果開啟HDFS的stream read，那么就會(huì)不停地發(fā)送數(shù)據(jù)，pread的好處就是往HDFS發(fā)送請求的時(shí)候會(huì)說從哪個(gè)位置開始讀取哪一段，當(dāng)讀取完畢之后就不會(huì)再發(fā)了。pread的連接用完之后可以放回到連接庫中去，下次有人需要可以重用這個(gè)連接。如果使用stream read可能讀取出來少了4K數(shù)據(jù)，那么就不讀取了，那么這個(gè)連接也就廢掉了，只能關(guān)閉了。其實(shí)在HBase 1.X版本中Scan有一個(gè)參數(shù)是setSmall，如果不是用small就默認(rèn)使用stream read，如果setSmall就是使用pread。目前HBase 2.0做了一個(gè)適配默認(rèn)開始時(shí)都是想要使用pread，當(dāng)發(fā)現(xiàn)讀取過長之后切換成stream read，但是其實(shí)這與上面存在同樣的問題，因?yàn)槠湟彩窃赟toreScanner層做的，所以問題也很多，有一些文件pread流，有的則是用stream read流。

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

寫路徑重構(gòu)

目前一些團(tuán)隊(duì)對(duì)于寫路徑優(yōu)化上做了一些工作，看起來效果基本上還可以。基本上就是用Staged Event Driven的架構(gòu)實(shí)現(xiàn)，這里的寫路徑相比于讀路徑要簡單很多，這是因?yàn)樽x路徑最主要的具有Filter，這就導(dǎo)致了讀路徑的邏輯會(huì)復(fù)雜很多。而寫路徑則比較清晰了，先寫出readlog，成功之后更新memstore并在最后complete mvcc就完成了。這樣的改造使得需要的線程數(shù)會(huì)更少一些，而之前就是一個(gè)線程從頭跑到尾，寫readlog時(shí)如果沒有寫過來，就會(huì)一直在這里堵著等待，之后的更新memstore并在最后complete mvcc也會(huì)堵在這里等，所以線程很多時(shí)間都是什么事情都沒干的，改成Staged之后線程需要的就會(huì)更少一些，性能就會(huì)更好一些。寫路徑比讀路徑更加清晰和簡單，但是寫路徑需要注意的一點(diǎn)就是絕對(duì)不能出現(xiàn)Bug，讀路徑出現(xiàn)Bug可能只是數(shù)據(jù)讀不到，但是如果寫路徑出現(xiàn)Bug寫入的數(shù)據(jù)就丟到了。

其他Feature

其實(shí)還有一些其他的Feature本在也在HBase 2.0版本中計(jì)劃上線，但是因?yàn)镠Base 2.0版本計(jì)劃了太多的新特性，因此不得不將這些特性拿出去，不然就更加發(fā)布不出來了。這些特性其一是C++ Client，這個(gè)基本上有一個(gè)可用的版本了，但是還需要后續(xù)的測試包裝等步驟。其二是HLC，Google是使用原子鐘在所有機(jī)器上面做了一套硬件，所以拿到的是時(shí)鐘誤區(qū)基本差不多，時(shí)間誤差允許范圍內(nèi)。而HLC是在沒有這樣的硬件條件下，依靠NCP實(shí)現(xiàn)各個(gè)機(jī)器之間的時(shí)間同步，HBase是想把Timestrap類似的東西用HLC實(shí)現(xiàn)。還有一個(gè)是Spark的Connecter，這個(gè)可以幫助Spark實(shí)現(xiàn)一些計(jì)算的下推，這部分在Master分支中也是有的，只不過因?yàn)闆]有完成所以沒有出現(xiàn)在HBase 2.0版本中。但是這些特性并不一定都能夠在HBase 3.0中上線。

原文鏈接

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。