今天講述一下HBase相關(guān)的知識(shí)。首先HBase作為大數(shù)據(jù)發(fā)展初期伴隨Google三大論文問世的一個(gè)組件，在今天依舊被廣泛的應(yīng)用，今天我們來仔細(xì)的分析一下HBase的內(nèi)部原理，了解一下HBase的具體內(nèi)幕，以便在工作中更好使用它。以下內(nèi)容涉及到的源碼基于HBase 的Master分支編譯出的最新的3.0.0版本。

HBase相關(guān)算法與數(shù)據(jù)結(jié)構(gòu)基礎(chǔ)知識(shí)

跳躍表

暫時(shí)先不說跳躍表是什么，在Java里面有一個(gè)Map叫：ConcurrentSkipListMap，通過對(duì)HBase的源碼跟蹤，我們發(fā)現(xiàn)這些地方使用了它：

簡(jiǎn)單的列了幾個(gè)，但是觀察這幾個(gè)類所在的模塊就可以發(fā)現(xiàn)，HBase從客戶端，到請(qǐng)求處理，到元數(shù)據(jù)再到文件存儲(chǔ)貫穿HBase的整個(gè)生命周期中的各個(gè)重要環(huán)節(jié)，都能看到它的身影，Map那么多，為何偏偏HBase選擇了這個(gè)?接下來我們仔細(xì)分析下。

在算法概念里面有一種數(shù)據(jù)結(jié)構(gòu)叫跳躍表，顧名思義，之所以叫跳躍表就是因?yàn)樵诓檎业臅r(shí)候可以快速的跳過部分列表，用來提升查找效率，跳躍表的查找效率可以和二叉樹相比為O(log(N))，這個(gè)算法的實(shí)現(xiàn)在Java中的ConcurrentSkipListMap就是實(shí)現(xiàn)跳躍表的相關(guān)算法。

首先我們看一個(gè)有序的全量表：

假設(shè)我們要從中找出 可以發(fā)現(xiàn)需要比較的次數(shù)(比較次數(shù)不是循環(huán)次數(shù))為<3，5，8>共計(jì)16次，可以看到對(duì)這樣一個(gè)有序鏈表進(jìn)行查找比較的次數(shù)會(huì)非常多，那么有沒有辦法對(duì)這種查找做優(yōu)化。當(dāng)然是有的，對(duì)于這種查找耳熟能詳從數(shù)據(jù)結(jié)構(gòu)的基礎(chǔ)課程開始大家就知道二叉樹，折半查找，值查找都屬于解決這類問題的方法，自然跳躍表也是解決這類問題的方法之一。

跳躍表的思路和如今大部分大數(shù)據(jù)組件像kylin對(duì)海量數(shù)據(jù)下的快速查找的解決思路非常相似，都是通過某種邏輯提前將部分?jǐn)?shù)據(jù)做預(yù)處理，然后查找的時(shí)候進(jìn)行快速匹配，典型的空間換時(shí)間，那么對(duì)于跳躍表來說，它的預(yù)處理的方式如下：

可以看到，跳躍表是按照層次構(gòu)造的，最底層是一個(gè)全量有序鏈表，依次向上都是它的精簡(jiǎn)版，而在上層鏈表中節(jié)點(diǎn)的后續(xù)下一步的節(jié)點(diǎn)是以隨機(jī)化的方式進(jìn)行的，因此在上層鏈表中可以跳過部分列表，也叫跳躍表，特點(diǎn)如下：

• 鏈表層從上往下查找
• 跳躍表由很多層組成
• 每一層都是一個(gè)有序鏈表
• 最底層是全量有序鏈表
• 如果一個(gè)元素出現(xiàn)在上層的某個(gè)節(jié)點(diǎn)那么它一定會(huì)出現(xiàn)在下層的鏈表
• 每一個(gè)元素都有兩個(gè)指針，一個(gè)指向當(dāng)前鏈表的下一個(gè)元素，一個(gè)指向下一層鏈表的相同節(jié)點(diǎn)

假設(shè)根據(jù)前面的圖表我們要查詢G這個(gè)字母，那么在上面的跳躍表中經(jīng)過的路徑如下：

其中紅色代表查找所走過的路徑。

LSM樹

前面講到了跳躍表的原理，在HBase中較大規(guī)模的使用了跳躍表，就是為了增快其查找效率，除了跳躍表之外HBase還使用到了LSM樹，LSM樹本質(zhì)上和B+相似，是一種存儲(chǔ)在磁盤上的數(shù)據(jù)的索引格式，但是差異點(diǎn)在于LSM對(duì)寫入非常高效，實(shí)現(xiàn)來說就是無論什么樣的寫入LSM都是當(dāng)成一次順序?qū)懭?，這一點(diǎn)和HDFS的優(yōu)點(diǎn)正好契合，HDFS不支持隨機(jī)寫，支持順序?qū)?。LSM數(shù)據(jù)存儲(chǔ)在兩個(gè)地方，一個(gè)是磁盤上一個(gè)是內(nèi)存中，內(nèi)存中同樣使用的跳躍表，內(nèi)存中是多個(gè)有序的文件。

HBase對(duì)LSM的應(yīng)用采用了如上的結(jié)構(gòu)方式，對(duì)于HBase具體的存儲(chǔ)文件的分析，在后面專門針對(duì)HBase的存儲(chǔ)部分進(jìn)行深入的分析。

布隆過濾器

布隆過濾器解決的問題是，如何快速的發(fā)現(xiàn)一個(gè)元素是否存在于某個(gè)集合里面，最簡(jiǎn)單的辦法就是在集合或者鏈表上查找一遍，但是考慮到在大數(shù)據(jù)場(chǎng)景下，數(shù)據(jù)量非常大，即便不考慮性能，也不見得會(huì)有足夠多的機(jī)器來加載對(duì)應(yīng)的集合。所以需要一種新的思路去解決此類問題，那么布隆過濾器就是一種，它的思想為：

• 由一個(gè)長(zhǎng)度為N的數(shù)組構(gòu)成，每一個(gè)元素為0或者1，默認(rèn)都為0
• 對(duì)集合的每個(gè)元素做K次哈希，到第i次的時(shí)候?qū)取一個(gè)模，會(huì)得到一個(gè)index
• 將數(shù)組中的array[index]變?yōu)?

上圖是長(zhǎng)度為18，進(jìn)行3次哈希得到的結(jié)果，那么在HBase中是如何利用布隆過濾器的呢，首先從操作來說，HBase的Get就經(jīng)過布隆過濾器，同時(shí)HBase支持度對(duì)不同的列設(shè)置不同的布隆過濾器。

可以看到對(duì)HBase來講可以啟用或者禁用過濾器，對(duì)于不同的過濾器的實(shí)現(xiàn)分別在不同的類中，在查詢的時(shí)候分別根據(jù)不同的過濾器采用不同的實(shí)現(xiàn)類：

所以可以通過如上的代碼找到對(duì)應(yīng)的過濾器實(shí)現(xiàn)，甚至可以新增自己的過濾器。

HBase讀寫操作

前面提到HBase的相關(guān)算法，現(xiàn)在我們講一下HBase的整個(gè)操作的讀寫流程。首先，擺出HBase的架構(gòu)圖，如下所示：

從這個(gè)圖可以看到，HBase的一個(gè)寫操作，大的流程會(huì)經(jīng)過三個(gè)地方：1. 客戶端，2. RegionServer 3. Memstore刷新到磁盤。也就是說對(duì)于HBase的一次寫入操作來講，數(shù)據(jù)落到Memstore就算寫入完成，那么必然需要考慮一個(gè)問題，那就是沒有落盤的數(shù)據(jù)，萬一機(jī)器發(fā)生故障，這部分?jǐn)?shù)據(jù)如何保障不丟失。解析來我們逐步分解一下這三個(gè)部分。

客戶端：HBase的客戶端和服務(wù)器并不是單一的鏈接，而是在封裝完數(shù)據(jù)后，通過請(qǐng)求HMaster獲取該次寫入對(duì)應(yīng)的RegionServer的地址，然后直接鏈接RegionServer，進(jìn)行寫入操作，對(duì)于客戶端的數(shù)據(jù)封裝來講，HBase支持在客戶端設(shè)置本地緩存，也就是批量提交還是實(shí)時(shí)提交。因?yàn)镠Base的hbase:meta表中記錄了RegionServer的信息，HBase的數(shù)據(jù)均衡是根據(jù)rowkey進(jìn)行分配，因此客戶端會(huì)根據(jù)rowkey查找到對(duì)應(yīng)的RegionServer，定義在Connection中：

而實(shí)現(xiàn)在：AsyncRegionLocator

RegionServer寫入：當(dāng)客戶端拿到對(duì)應(yīng)的RegionServer后，便和HMaster沒有關(guān)系了，開始了直接的數(shù)據(jù)傳輸，我們前面提到一個(gè)問題，那就是HBase如何防止數(shù)據(jù)丟失，畢竟HBase的寫入是到內(nèi)存，一次請(qǐng)求就返回了，解決這個(gè)問題是通過WAL日志文件來解決的，任何一次寫入操作，首先寫入的是WAL，這類日志存儲(chǔ)格式和Kafka類似的順序追加，但是具有時(shí)效性，也就是當(dāng)數(shù)據(jù)落盤成功，并且經(jīng)過檢查無誤之后，這部分日志會(huì)清楚，以保障HBase具有一個(gè)較好的性能，當(dāng)寫完日志文件后，再寫入Memstore。

那么在RegionServer的寫入階段會(huì)發(fā)生什么呢?首先我們知道，HBase是具有鎖的能力的，也就是行鎖能力，對(duì)于HBase來講，HBase使用行鎖保障對(duì)同一行的數(shù)據(jù)的更新要么都成功要么都失敗，所以在RegionServer階段，會(huì)經(jīng)過以下步驟：

• 申請(qǐng)行鎖，用來保障本次寫入的事務(wù)性
• 更新LATEST_TIMESTAMP字段，HBase默認(rèn)會(huì)保留歷史的所有版本，但是查詢過濾的時(shí)候始終只顯示最新的數(shù)據(jù)，然后進(jìn)行寫入前提條件的檢查：

以上相關(guān)操作的代碼都在HRegion，RegionAsTable中，可以以此作為入口去查看，所以這里就不貼大部分的代碼了。

寫入WAL日志文件，在WALProvider中定義了兩個(gè)方法：

append用來對(duì)每一次的寫入操作進(jìn)行日志追蹤，因?yàn)橛惺挛餀C(jī)制，所以HBase會(huì)將一次操作中的所有的key value變成一條日志信息寫入日志文件，aync用來同步將該日志文件落盤到HDFS的文件系統(tǒng)，入場(chǎng)中間發(fā)生失敗，則立即回滾。

4. 寫入Memstore，釋放鎖，本次寫入成功。

所以可以看到對(duì)于HBase來講寫入通過日志文件再加Memstore進(jìn)行配合，最后HBase自身再通過對(duì)數(shù)據(jù)落盤，通過這樣一系列的機(jī)制來保障了寫入的一套動(dòng)作。

講完了HBase的寫入操作，再來看看HBase的讀取流程。

對(duì)于讀來講，客戶端的流程和寫一樣，HBase的數(shù)據(jù)不會(huì)經(jīng)過Master進(jìn)行轉(zhuǎn)發(fā)，客戶端通過Master查找到元信息，再根據(jù)元信息拿到meta表，找到對(duì)應(yīng)的Region Sever直接取數(shù)據(jù)。對(duì)于讀操作來講，HBase內(nèi)部歸納下來有兩種操作，一種是GET，一種是SCAN。GET為根據(jù)rowkey直接獲取一條記錄，而SCAN則是根據(jù)某個(gè)條件進(jìn)行掃描，然后返回多條數(shù)據(jù)的過程?？梢钥吹紾ET經(jīng)過一系列的判斷，例如檢查是否有coprocessor hook后，直接返回了存儲(chǔ)數(shù)據(jù)集的List：

那么我們?cè)倏碨CAN就不那么一樣了，可以看到，對(duì)于SCAN的操作來講并不是一次的返回所有數(shù)據(jù)，而是返回了一個(gè)Scanner，也就是說在HBase里面，對(duì)于Scan操作，將其分成了多個(gè)RPC操作，類似于數(shù)據(jù)的ResultSet，通過next來獲取下一行數(shù)據(jù)。

HBase文件格式

前面講了HBase的操作流程，現(xiàn)在我們看下HBase的存儲(chǔ)機(jī)制，首先HBase使用的HDFS存儲(chǔ)，也就是在文件系統(tǒng)方面沒有自身的文件管理系統(tǒng)，所以HBase僅僅需要設(shè)計(jì)的是文件格式，在HBase里面，最終的數(shù)據(jù)都是存儲(chǔ)在HFile里面，HFile的實(shí)現(xiàn)借鑒了BigTable的SSTable和Hadoop的TFile，一張圖先展示HFile的邏輯結(jié)構(gòu)：

可以看到HFie主要由四個(gè)部分構(gòu)成:

• Scanned block section： 顧名思義，表示順序掃描HFile時(shí)所有的數(shù)據(jù)塊將會(huì)被讀取，包括Leaf Index Block和Bloom Block。
• Non-scanned block section： 表示在HFile順序掃描的時(shí)候數(shù)據(jù)不會(huì)被讀取，主要包括Meta Block和* Intermediate Level Data Index Blocks兩部分。
• Load-on-open-section： 這部分?jǐn)?shù)據(jù)在HBase的region server啟動(dòng)時(shí)，需要加載到內(nèi)存中。包括FileInfo、Bloom filter block、data block index和meta block index。
• Trailer： 這部分主要記錄了HFile的基本信息、各個(gè)部分的偏移值和尋址信息。

對(duì)于一個(gè)HFile文件來講，最終落盤到磁盤上的時(shí)候會(huì)將一個(gè)大的HFile拆分成多個(gè)小文件，每一個(gè)叫做block塊，和HDFS的塊相似，每一個(gè)都可以自己重新設(shè)定大小，在HBase里面默認(rèn)為64KB，對(duì)于較大的塊，在SCAN的時(shí)候可以在連續(xù)的地址上讀取數(shù)據(jù)，因此對(duì)于順序SCAN的查詢會(huì)非常高效，對(duì)于小塊來講則更有利于隨機(jī)的查詢，所以塊大小的設(shè)置，也是HBase的調(diào)參的一個(gè)挑戰(zhàn)，相關(guān)的定義在源碼里面使用的HFileBlock類中，HFileBlock的結(jié)構(gòu)如下所示：

每一個(gè)block塊支持兩種類型，一種是支持Checksum的，一種是不支持Checksum的，通過參數(shù)usesHBaseChecksum在創(chuàng)建block的時(shí)候進(jìn)行設(shè)置：

HFileBlock主要包含兩個(gè)部分，一個(gè)是Header一個(gè)是Data，如下圖所示：

(HFileBlock結(jié)構(gòu)，來自網(wǎng)絡(luò))

BlockHeader主要存儲(chǔ)block元數(shù)據(jù)，BlockData用來存儲(chǔ)具體數(shù)據(jù)。前面提到一個(gè)大的HFile會(huì)被切分成多個(gè)小的block，每一個(gè)block的header都相同，但是data不相同，主要是通過BlockType字段來進(jìn)行區(qū)分，也就是HFile把文件按照不同使用類型，分成多個(gè)小的block文件，具體定義在BlockType中，定義了支持的Type類型：

下面我們仔細(xì)分解一下HBase的Data部分的存儲(chǔ)，HBase是一個(gè)K-V的數(shù)據(jù)庫(kù)，并且每條記錄都會(huì)默認(rèn)保留，通過時(shí)間戳進(jìn)行篩選，所以HBase的K-V的格式在磁盤的邏輯架構(gòu)如下所示：

每個(gè)KeyValue都由4個(gè)部分構(gòu)成，而Key又是一個(gè)復(fù)雜的結(jié)構(gòu)，首先是rowkey的長(zhǎng)度，接著是rowkey，然后是ColumnFamily的長(zhǎng)度，再是ColumnFamily，之后是ColumnQualifier，最后是時(shí)間戳和KeyType(keytype有四種類型，分別是Put、Delete、 DeleteColumn和DeleteFamily)，而value相對(duì)簡(jiǎn)單，是一串純粹的二進(jìn)制數(shù)據(jù)。

最開始的時(shí)候我們介紹了布隆過濾器，布隆過濾器會(huì)根據(jù)條件減少和跳過部分文件，以增加查詢速度：

每一個(gè)HFile有自己的布隆過濾器的數(shù)組，但是我們也會(huì)發(fā)現(xiàn)，這樣的一個(gè)數(shù)組，如果HBase的塊數(shù)足夠多，那么這個(gè)數(shù)組會(huì)更加的長(zhǎng)，也就意味著資源消耗會(huì)更多，為了解決這個(gè)問題，在HFile里面又定義了布隆過濾器的塊，用來檢索對(duì)應(yīng)的Key需要使用哪個(gè)數(shù)組：

一次get請(qǐng)求進(jìn)來，首先會(huì)根據(jù)key在所有的索引條目中進(jìn)行二分查找，查找到對(duì)應(yīng)的Bloom Index Entry，就可以定位到該key對(duì)應(yīng)的位數(shù)組，加載到內(nèi)存進(jìn)行過濾判斷。

HBase RegionServer

聊完了HBase的流程和存儲(chǔ)格式，現(xiàn)在我們來看一下HBase的RegionServer，RegionServer是HBase響應(yīng)用戶讀寫操作的服務(wù)器，內(nèi)部結(jié)構(gòu)如下所示：

一個(gè)RegionServer由一個(gè)HLog，一個(gè)BlockCache和多個(gè)Region組成，HLog保障數(shù)據(jù)寫入的可靠性，BlockCache緩存查詢的熱點(diǎn)數(shù)據(jù)提升效率，每一個(gè)Region是HBase中的數(shù)據(jù)表的一個(gè)分片，一個(gè)RegionServer會(huì)承擔(dān)多個(gè)Region的讀寫，而每一個(gè)Region又由多個(gè)store組成。store中存儲(chǔ)著列簇的數(shù)據(jù)。例如一個(gè)表包含兩個(gè)列簇的話，這個(gè)表的所有Region都會(huì)包含兩個(gè)Store，每個(gè)Store又包含Mem和Hfile兩部分，寫入的時(shí)候先寫入Mem，根據(jù)條件再落盤成Hfile。

RegionServer管理的HLog的文件格式如下所示：

HLog的日志文件存放在HDFS中，hbase集群默認(rèn)會(huì)在hdfs上創(chuàng)建hbase文件夾，在該文件夾下有一個(gè)WAL目錄，其中存放著所有相關(guān)的HLog，HLog并不會(huì)永久存在，在整個(gè)HBase總HLog會(huì)經(jīng)歷如下過程：

• HLog構(gòu)建： 任何寫入操作都會(huì)先記錄到HLog，因此在發(fā)生寫入操作的時(shí)候會(huì)先構(gòu)建HLog。
• HLog滾動(dòng)： 因?yàn)镠Log會(huì)不斷追加，所以整個(gè)文件會(huì)越來越大，因此需要支持滾動(dòng)日志文件存儲(chǔ)，所以HBase后臺(tái)每間隔一段時(shí)間(默認(rèn)一小時(shí))會(huì)產(chǎn)生一個(gè)新的HLog文件，歷史HLog標(biāo)記為歷史文件。
• HLog失效： 一旦數(shù)據(jù)進(jìn)入到磁盤，形成HFile后，HLog中的數(shù)據(jù)就沒有存在必要了，因?yàn)镠File存儲(chǔ)在HDFS中，HDFS文件系統(tǒng)保障了其可靠性，因此當(dāng)該HLog中的數(shù)據(jù)都落地成磁盤后，該HLog會(huì)變?yōu)槭顟B(tài)，對(duì)應(yīng)的操作是將該文件從WAL移動(dòng)到oldWAl目錄，此時(shí)文件依舊存在，并未進(jìn)行刪除。
• HLog刪除： hbase有一個(gè)后臺(tái)進(jìn)程，默認(rèn)每間隔一分鐘會(huì)對(duì)失效日志文件進(jìn)行判斷，如果沒有任何引用操作，那么此時(shí)的文件會(huì)被徹底的從物理刪除。

對(duì)于RegionServer來講，每一個(gè)RegionServer都是一個(gè)獨(dú)立的讀寫請(qǐng)求服務(wù)，因此HBase可以水平增加多個(gè)RegionServer來達(dá)到水平擴(kuò)展的效果，但是多個(gè)RegionServer之間并不存在信息共享，也就是如果一個(gè)海量任務(wù)計(jì)算失敗的時(shí)候，客戶端重試后，鏈接新的RegionServer后，整個(gè)計(jì)算會(huì)重新開始。

HBase怎么用

雖然HBase目前使用非常廣泛，并且默認(rèn)情況下，只要機(jī)器配置到位，不需要特別多的操作，HBase就可以滿足大部分情況下的海量數(shù)據(jù)處理，再配合第三方工具像phoenix，可以直接利用HBase構(gòu)建一套OLAP系統(tǒng)，但是我們還是要認(rèn)識(shí)到HBase的客觀影響，知道其對(duì)應(yīng)的細(xì)節(jié)差異，大概來說如果我們使用HBase，有以下點(diǎn)需要關(guān)心一下：

• 因?yàn)镠Base在RegionServer對(duì)寫入的檢查機(jī)制，會(huì)導(dǎo)致客戶端在符合條件的情況下出現(xiàn)重試的情況，所以對(duì)于較為頻繁的寫入操作，或者較大數(shù)據(jù)量的寫入操作，推薦使用直接產(chǎn)生HFlie然后load到HBase中的方式，不建議直接使用HBase的自身的Put API。
• 從使用來講如果業(yè)務(wù)場(chǎng)景導(dǎo)致HBase中存儲(chǔ)的列簇對(duì)應(yīng)的數(shù)據(jù)量差異巨大，那么不建議創(chuàng)建過多的列簇，因?yàn)镠Base的存儲(chǔ)機(jī)制會(huì)導(dǎo)致不同列簇的數(shù)據(jù)存儲(chǔ)在同一個(gè)HBase的HFile中，但是split機(jī)制在數(shù)據(jù)量增加較大的情況下，會(huì)發(fā)生拆分，則會(huì)導(dǎo)致小數(shù)據(jù)量的列簇被頻繁的split，反而降低了查詢性能。
• RegionServer是相互獨(dú)立的，所以如果想要讓集群更加的穩(wěn)定高效，例如如果想實(shí)現(xiàn)RegionServer集群，達(dá)到信息共享，任務(wù)增量計(jì)算，需要自己修改RegionServer的代碼。
• 對(duì)于HBase來講，很多場(chǎng)景下，像如果Region正在Split，或者M(jìn)em正在Dump，則無法進(jìn)行對(duì)應(yīng)的操作，此時(shí)錯(cuò)誤信息會(huì)被以異常的形式返回到客戶端，再由客戶端進(jìn)行重試，因此在使用過程中，需要結(jié)合我們的應(yīng)用場(chǎng)景，考慮如何設(shè)置類似于buffer大小的參數(shù)，以盡可能少的降低因?yàn)閮?nèi)部操作引起的客戶端重試，特別是在使用類似opentsdb的這類集成hhbase的數(shù)據(jù)的情況下。

結(jié)尾

HBase有著非常龐大的架構(gòu)體系，和較為不錯(cuò)的使用體驗(yàn)，因此使用一篇文章通常很難講述清楚整個(gè)HBase內(nèi)幕，但是我們可以根據(jù)理解逐步滲透到HBase內(nèi)部，了解這個(gè)組件背后的原理，這樣當(dāng)我們?cè)谑褂盟臅r(shí)候就會(huì)變得更加的得心應(yīng)手。經(jīng)驗(yàn)也不是一日構(gòu)成，需要我們?nèi)諒?fù)一日的不斷練習(xí)，在HBase不斷推出的新版下，琢磨和理解它的原理和架構(gòu)。Apache下有非常多的組件可以實(shí)現(xiàn)差不多的功能，但是每一個(gè)組件又有著自己獨(dú)特的特點(diǎn)，本章我們介紹了HBase，后續(xù)會(huì)逐步分解介紹像Kylin，HDFS，Yarn，以及Atlas等組件。