HBase的架構設計爲何這麼厲害!

老劉是一名即將找工做的研二學生，寫博客一方面是複習總結大數據開發的知識點，一方面是但願可以幫助和本身同樣自學編程的夥伴。因爲老劉是自學大數據開發，博客中確定會存在一些不足，還但願你們可以批評指正，讓咱們一塊兒進步！

 今天爲你們帶來的內容是HBase的架構設計，講講HBase的架構設計爲何這麼牛？本文內容不會很長，全是老劉總結的精華，你們不可錯過！

1 背景

咱們要提早知道兩個問題，這兩個問題的解決也剛好回答了HBase的架構設計爲何這麼牛！

第一個問題是HBase做爲一個分佈式數據庫，它是如何確保在海量數據中，作到低延時的隨機讀寫的呢？

第二個問題是Hbase是如何確保在分佈式架構中，保證數據安全的呢？

2 第一個問題解答

確保在海量數據中，低延時的隨機讀寫，HBase真的花了不少心思，作了不少設計，下面讓老劉給你們好好說一說！

2.1 內存+磁盤

這個設計在衆多框架中都存在，這樣作的好處是在數據安全性和數據操做效率之間作了一個權衡，既追求數據安全，也追求數據操做效率。

2.2 內存數據良好的數據結構

HBase爲了確保數據操做有更高的效率，也爲了保證內存中的數據刷寫出來造成有序的文件，這句話是什麼意思？什麼是數據操做更加高效？

即內存文件爲了保證插入刪除數據等操做高效，數據有序，因此用到了ConcurentSkipListMap的數據結構！

2.3 範圍分區+排序

海量數據作查詢通常採用什麼方法？

最粗暴的方式就是暴力掃描，但你們通常都不採用，道理都懂！因此咱們通常會採用先排序，再範圍分區+分段掃描的辦法。那海量數據爲了可以讓數據有序，在採用插入數據過程當中，怎麼作到數據有序的呢？

根據上圖，老劉來解釋下其中的道理，a先來c隨後，最後b也來了，但咱們如何作到把b放在a和c之間呢？

先把數據放在內存裏面，a和c已經相鄰，如今b來了，要保證abc這樣的順序，其實很容易作到，咱們能夠利用數組或鏈表，把c日後面挪，再把b插入進來，但內存有限，就須要每隔一段時間，把內存中數據寫入到磁盤文件，磁盤裏的文件就是有序，這樣就能方便之後快速定位！

2.4 跳錶Topo結構

這是什麼意思呢？其實說的是HBase的尋址方式。

HBase的尋址方式分兩種，一種是0.96版本以前，一種是0.96版本以後。

在HBase-0.96版本之前，HBase有兩個特殊的表，分別是-ROOT-表和.META.表，其中-ROOT-的位置存儲在ZooKeeper中，-ROOT-自己存儲了.META. Table的RegionInfo信息 。尋址方式的流程以下：

1. Client請求ZooKeeper得到-ROOT-所在的RegionServer地址。
2. Client請求-ROOT-所在的RS地址，獲取.META.表的地址，Client會將-ROOT-的相關信息cache下來，以便下一次快速訪問。
3. Client請求.META.表的RegionServer地址，獲取訪問數據所在RegionServer的地址，Client會將.META.的相關信息cache下來，以便下一次快速訪問。
4. Client請求訪問數據所在RegionServer的地址，獲取對應的數據。

咱們能夠看出，用戶須要3次請求才能知道用戶表真正的位置，這在必定程度上帶來性能的降低。在0.96以前使用3層設計的主要緣由是考慮到元數據可能須要很大。

那0.96版本以後的尋址流程以下：

1. Client請求ZooKeeper獲取.META.所在的RegionServer的地址。
2. Client請求.META.所在的RegionServer獲取訪問數據所在的RegionServer地址，Client會
   將.META.的相關信息cache下來，以便下一次快速訪問。
3. Client請求數據所在的RegionServer，獲取所須要的數據。

去掉-ROOT-的緣由主要就是HBase-1.x之後，默認每一個region的最大大小爲10G，以前是128M，如今就發現2層的結構已經知足集羣的需求了，性能也相對提升了。

講完Region尋址方式，回到正題跳錶Topo結構，就拿0.96版本以前的講，跳錶有三層，第一層是user table，第二層是meta table，第三層是root table，那爲何要設計這樣的跳錶呢？

假設有一張表的數據特別大，一臺服務器存不下來，就須要把這張表拆分紅好幾個部分(例如4個部分)。若是這張表再進行拆分的時候老早已經排好順序，那拆分出來的數據應該是一段一段的，每一段就包含了這一段的全部數據。

那客戶端如今來查詢數據，過來掃描數據，那它到底掃描哪一臺服務器呢？咱們不肯定，可能每臺服務器都要掃描一遍，這樣作致使效率不好！

咱們能夠先去找一箇中間機構去確認要找的數據在這4段中的哪一段，建立一個元數據表meta存真正數據的Region位置，先去找meta表。當元數據表變得特別大，也會切分多個段放在RegionServer中，這個時候就會提供一個ROOT表來肯定meta表的位置。

這就造成了一種層級關係，從ROOT表跳到meta表跳到具體RegionServer。

造成跳錶Topo結構下降了掃描次數，原來須要n次或4次掃描，如今變爲1次掃描，性能獲得提升，而且能夠管理很是多的數據。

如何理解能夠管理很是多的數據？

hbase1.0以前，每一個Region默認大小是128M，每條元數據爲1KB，那它就能存儲1千多個元數據，那3層結構就會存儲幾千萬上億的記錄。hbase1.0以後，每一個Region默認大小是10G，兩層結構可以存儲的數據也足夠大，知足集羣需求。

2.5 讀緩存+寫緩存

內存分讀緩存和寫緩存，把常常查詢的數據放在讀緩存，能夠提高效率。寫緩存怎麼掃描文件速率最高？就是利用內存+磁盤的方式，先把數據放在內存排序後，再把數據寫入到磁盤中，這樣磁盤裏的文件就是有序的了，接着對磁盤文件二分查找，效率變高。

3 第二個問題解答

爲了確保在分佈式架構中，數據的安全，HBase怎麼作？

3.1 內存+磁盤

HBase採用了內存+磁盤存儲的方式，這樣作的好處是在數據安全性和數據操做效率之間作了一個權衡，既追求數據安全，也追求數據操做效率。

3.2 WAL機制

WAL意爲Write Ahead Log，相似MySQL中的binlog，用來作災難恢復之用。HBase爲了防止數據寫入緩存以後不會因RegionServer進程發生異常致使數據丟失，在寫入緩存以前會首先將數據順序寫入到HLog(WAL)中。若是不幸一旦發生RegionServer宕機或者其餘異常，這種設計能夠從HLog中進行日誌回放進行數據補救，保證數據不丟失。HBase故障恢復的最大看點就在於如何經過HLog回放補救丟失數據。

4 總結

好啦，HBase的架構設計大體聊得差很少了，老劉主要給你們講了講爲何HBase的架構設計這麼牛。儘管當前水平可能不及各位大佬，但老劉仍是但願可以變得更加優秀，可以幫助更多自學編程的夥伴。

若是有相關問題，請聯繫公衆號：努力的老劉。若是以爲幫到了您，不妨點贊關注支持一波！