老劉是一名即將找工作的研二學生，寫部落格一方面是複習總結大資料開發的知識點，一方面是希望能夠幫助和自己一樣自學程式設計的夥伴。由於老劉是自學大資料開發，部落格中肯定會存在一些不足，還希望大家能夠批評指正，讓我們一起進步！
今天為大家帶來的內容是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資訊 。定址方式的流程如下：
- Client請求ZooKeeper獲得-ROOT-所在的RegionServer地址。
- Client請求-ROOT-所在的RS地址，獲取.META.表的地址，Client會將-ROOT-的相關資訊cache下來，以便下一次快速訪問。
- Client請求.META.表的RegionServer地址，獲取訪問資料所在RegionServer的地址，Client會將.META.的相關資訊cache下來，以便下一次快速訪問。
- Client請求訪問資料所在RegionServer的地址，獲取對應的資料。
我們可以看出，使用者需要3次請求才能知道使用者表真正的位置，這在一定程度上帶來效能的下降。在0.96之前使用3層設計的主要原因是考慮到後設資料可能需要很大。
那0.96版本之後的定址流程如下：
- Client請求ZooKeeper獲取.META.所在的RegionServer的地址。
- Client請求.META.所在的RegionServer獲取訪問資料所在的RegionServer地址，Client會
將.META.的相關資訊cache下來，以便下一次快速訪問。 - 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的架構設計這麼牛。儘管當前水平可能不及各位大佬，但老劉還是希望能夠變得更加優秀，能夠幫助更多自學程式設計的夥伴。
如果有相關問題，請聯絡公眾號：努力的老劉。如果覺得幫到了您，不妨點贊關注支援一波！
