老劉是一名即將找工作的研二學生，寫部落格一方面是複習總結大資料開發的知識點，一方面是希望能夠幫助和自己一樣自學程式設計的夥伴。由於老劉是自學大資料開發，部落格中肯定會存在一些不足，還希望大家能夠批評指正，讓我們一起進步！我們要提前知道兩個問題，這兩個問題的解決也恰好回答了hbase的架構設計為什麼這麼牛！
第乙個問題是hbase作為乙個分布式資料庫，它是如何確保在海量資料中，做到低延時的隨機讀寫的呢？
第二個問題是hbase是如何確保在分布式架構中，保證資料安全的呢？
這個設計在眾多框架中都存在，這樣做的好處是在資料安全性和資料操作效率之間做了乙個權衡，既追求資料安全，也追求資料操作效率。
hbase為了確保資料操作有更高的效率，也為了保證記憶體中的資料刷寫出來形成有序的檔案，這句話是什麼意思？什麼是資料操作更加高效？
即記憶體檔案為了保證插入刪除資料等操作高效，資料有序，所以用到了concurentskiplistmap的資料結構！
海量資料做查詢一般採用什麼方法？
最粗暴的方式就是暴力掃瞄，但大家一般都不採用，道理都懂！所以我們一般會採用先排序，再範圍分割槽+分段掃瞄的辦法。那海量資料為了能夠讓資料有序，在採用插入資料過程中，怎麼做到資料有序的呢？
根據上圖，老劉來解釋下其中的道理，a先來c隨後，最後b也來了，但我們如何做到把b放在a和c之間呢？
先把資料放在記憶體裡面，a和c已經相鄰，現在b來了，要保證abc這樣的順序，其實很容易做到，我們可以利用陣列或鍊錶，把c往後面挪，再把b插入進來，但記憶體有限，就需要每隔一段時間，把記憶體中資料寫入到磁碟檔案，磁碟裡的檔案就是有序，這樣就能方便以後快速定位！
這是什麼意思呢？其實說的是hbase的定址方式。
hbase的定址方式分兩種，一種是0.96版本之前，一種是0.96版本之後。
在hbase-0.96版本以前，hbase有兩個特殊的表，分別是-root-表和.meta.表，其中-root-的位置儲存在zookeeper中，-root-本身儲存了.meta. table的regioninfo資訊 。定址方式的流程如下：
client請求zookeeper獲得-root-所在的regionserver位址。
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，兩層結構能夠儲存的資料也足夠大，滿足集群需求。
記憶體分讀快取和寫快取，把經常查詢的資料放在讀快取，可以提公升效率。寫快取怎麼掃瞄檔案速率最高？就是利用記憶體+磁碟的方式，先把資料放在記憶體排序後，再把資料寫入到磁碟中，這樣磁碟裡的檔案就是有序的了，接著對磁碟檔案二分查詢，效率變高。
為了確保在分布式架構中，資料的安全，hbase怎麼做？
hbase採用了記憶體+磁碟儲存的方式，這樣做的好處是在資料安全性和資料操作效率之間做了乙個權衡，既追求資料安全，也追求資料操作效率。
wal意為write ahead log，類似mysql中的binlog，用來做災難恢復之用。hbase為了防止資料寫入快取之後不會因regionserver程序發生異常導致資料丟失，在寫入快取之前會首先將資料順序寫入到hlog(wal)中。如果不幸一旦發生regionserver宕機或者其他異常，這種設計可以從hlog中進行日誌回放進行資料補救，保證資料不丟失。hbase故障恢復的最大看點就在於如何通過hlog回放補救丟失資料。
好啦，hbase的架構設計大致聊得差不多了，老劉主要給大家講了講為什麼hbase的架構設計這麼牛。儘管當前水平可能不及各位大佬，但老劉還是希望能夠變得更加優秀，能夠幫助更多自學程式設計的夥伴。
為什麼要做架構設計
架構設計的目標 減少重複 重複是萬惡之源！這是從結構化程式設計時代就存在的格言，在物件導向時代依然是金玉良言。方便理解邏輯 清晰簡潔的結構能夠讓人以最快的速度理解和掌握程式 的邏輯，因此也就便於維護和擴充套件。適應需求變化 因此有了各種設計模式，大多都是針對某種需求發生變化的可能性而提出。便於分工協...
Hbase小記 架構設計
負責hbase的table region的管理 rs的region的負載均衡 region的 及 後的region的分配 rs掛的時候 region遷移負責資料的路由 資料讀寫和資料的持久化 hregionserver dn部署同一臺 乙個rs節點包含多個region,乙個region根據cf劃分為...
為什麼要關注架構設計？
因為假如你不關心架構，那麼總有一天，需要在同乙個龐大的類中除錯若干複雜的事情，你會發現在這樣的條件下，根本不可能在這個類中快速的找到以及有效的修改任何bug.當然，把這樣的乙個類想象為乙個整體是困難的，因此，有可能一些重要的細節總會在這個過程中會被忽略。如果現在的你正是處於這樣乙個開發環境中，很有可...