我們知道，google 發表 gfs、mapreduce、bigtable 三篇**，號稱「三駕馬車」，開啟了大資料的時代。那和這「三駕馬車」對應的有哪些開源產品呢？我們前面已經講過了 gfs 對應的 hadoop 分布式檔案系統 hdfs，以及 mapreduce 對應的 hadoop 分布式計算框架 mapreduce，今天我們就來領略一下bigtable 對應的 nosql 系統 hbase，看看它是如何大規模處理海量資料的。
在計算機資料儲存領域，一直是關聯式資料庫（rdbms）的天下，以至於在傳統企業的應用領域，許多應用系統設計都是面向資料庫設計，也就是先設計資料庫然後設計程式，從導致關係模型綁架物件模型，並由此引申出曠日持久的業務物件貧血模型與充血模型之爭。
業界為了解決關聯式資料庫的不足，提出了諸多方案，比較有名的是物件資料庫，但是這些資料庫的出現似乎只是進一步證明關聯式資料庫的優越而已。直到人們遇到了關聯式資料庫難以克服的缺陷——糟糕的海量資料處理能力及僵硬的設計約束，局面才有所改善。從 google 的 bigtable 開始，一系列的可以進行海量資料儲存與訪問的資料庫被設計出來，更進一步說，nosql 這一概念被提了出來。
nosql，主要指非關係的、分布式的、支援海量資料儲存的資料庫設計模式。也有許多專家將 nosql 解讀為 not only sql，表示 nosql 只是關聯式資料庫的補充，而不是替代方案。其中，hbase 是這一類 nosql 系統的傑出代表。
hbase 之所以能夠具有海量資料處理能力，其根本在於和傳統關係型資料庫設計的不同思路。傳統關係型資料庫對儲存在其上的資料有很多約束，學習關聯式資料庫都要學習資料庫設計正規化，事實上，是在資料儲存中包含了一部分業務邏輯。而 nosql 資料庫則簡單暴力地認為，資料庫就是儲存資料的，業務邏輯應該由應用程式去處理，有時候不得不說，簡單暴力也是一種美。
hregion 是 hbase 負責資料儲存的主要程序，應用程式對資料的讀寫操作都是通過和 hregion 通訊完成。上面是 hbase 架構圖，我們可以看到在 hbase 中，資料以 hregion 為單位進行管理，也就是說應用程式如果想要訪問乙個資料，必須先找到 hregion，然後將資料讀寫操作提交給 hregion，由 hregion 完成儲存層面的資料操作。
hregionserver 是物理伺服器，每個 hregionserver 上可以啟動多個 hregion 例項。當乙個 hregion 中寫入的資料太多，達到配置的閾值時，乙個 hregion 會**成兩個 hregion，並將 hregion 在整個集群中進行遷移，以使 hregionserver 的負載均衡。
每個 hregion 中儲存一段 key 值區間 [key1, key2) 的資料，所有 hregion 的資訊，包括儲存的 key 值區間、所在 hregionserver 位址、訪問埠號等，都記錄在 hmaster 伺服器上。為了保證 hmaster 的高可用，hbase 會啟動多個 hmaster，並通過 zookeeper 選舉出乙個主伺服器。
下面是一張呼叫時序圖，應用程式通過 zookeeper 獲得主 hmaster 的位址，輸入 key 值獲得這個 key 所在的 hregionserver 位址，然後請求 hregionserver 上的 hregion，獲得所需要的資料。
資料寫入過程也是一樣，需要先得到 hregion 才能繼續操作。hregion 會把資料儲存在若干個 hfile 格式的檔案中，這些檔案使用 hdfs 分布式檔案系統儲存，在整個集群內分布並高可用。當乙個 hregion 中資料量太多時，這個 hregion 連同 hfile 會**成兩個 hregion，並根據集群中伺服器負載進行遷移。如果集群中有新加入的伺服器，也就是說有了新的 hregionserver，由於其負載較低，也會把 hregion 遷移過去並記錄到 hmaster，從而實現 hbase 的線性伸縮。
先小結一下上面的內容，hbase 的核心設計目標是解決海量資料的分布式儲存，和 memcached 這類分布式快取的路由演算法不同，hbase 的做法是按 key 的區域進行分片，這個分片也就是 hregion。應用程式通過 hmaster 查詢分片，得到 hregion 所在的伺服器 hregionserver，然後和該伺服器通訊，就得到了需要訪問的資料。
傳統的關聯式資料庫為了保證關係運算（通過 sql 語句）的正確性，在設計資料庫表結構的時候，需要指定表的 schema 也就是欄位名稱、資料型別等，並要遵循特定的設計正規化。這些規範帶來了乙個問題，就是僵硬的資料結構難以面對需求變更帶來的挑戰，有些應用系統設計者通過預先設計一些冗餘欄位來應對，但顯然這種設計也很糟糕。
那有沒有辦法能夠做到可擴充套件的資料結構設計呢？不用修改表結構就可以新增欄位呢？當然有的，許多 nosql 資料庫使用的列族（columnfamily）設計就是其中乙個解決方案。列族最早在 google 的 bigtable 中使用，這是一種面向列族的稀疏矩陣儲存格式，如下圖所示。
這是乙個學生的基本資訊表，表中不同學生的****各不相同，選修的課程也不同， 而且將來還會有更多****和課程加入到這張表裡，如果按照傳統的關聯式資料庫設計，無論提前預設多少冗餘欄位都會捉襟見肘、疲於應付。
而使用支援列族結構的 nosql 資料庫，在建立表的時候，只需要指定列族的名字，無需指定字段（column）。那什麼時候指定欄位呢？可以在資料寫入時再指定。通過這種方式，資料表可以包含數百萬的字段，這樣就可以隨意擴充套件應用程式的資料結構了。並且這種資料庫在查詢時也很方便，可以通過指定任意欄位名稱和值進行查詢。
hbase 這種列族的資料結構設計，實際上是把字段的名稱和字段的值，以 key-value 的方式一起儲存在 hbase 中。實際寫入的時候，可以隨意指定欄位名稱，即使有幾百萬個欄位也能輕鬆應對。
還記得專欄第 5 期講 raid 時我留給你的思考題嗎？當時很多同學答得都很棒。傳統的機械式磁碟的訪問特性是連續讀寫很快，隨機讀寫很慢。這是因為機械磁碟靠電機驅動訪問磁碟上的資料，電機要將磁頭落到資料所在的磁軌上，這個過程需要較長的定址時間。如果資料不連續儲存，磁頭就要不停的移動，浪費了大量的時間。
為了提高資料寫入速度，hbase 使用了一種叫作lsm 樹的資料結構進行資料儲存。lsm 樹的全名是 log structed merge tree，翻譯過來就是 log 結構合併樹。資料寫入的時候以 log 方式連續寫入，然後非同步對磁碟上的多個 lsm 樹進行合併。
lsm 樹可以看作是乙個 n 階合併樹。資料寫操作（包括插入、修改、刪除）都在記憶體中進行，並且都會建立乙個新記錄（修改會記錄新的資料值，而刪除會記錄乙個刪除標誌）。這些資料在記憶體中仍然還是一棵排序樹，當資料量超過設定的記憶體閾值後，會將這棵排序樹和磁碟上最新的排序樹合併。當這棵排序樹的資料量也超過設定閾值後，會和磁碟上下一級的排序樹合併。合併過程中，會用最新更新的資料覆蓋舊的資料（或者記錄為不同版本）。
在需要進行讀操作時，總是從記憶體中的排序樹開始搜尋，如果沒有找到，就從磁碟 上的排序樹順序查詢。
在 lsm 樹上進行一次資料更新不需要磁碟訪問，在記憶體即可完成。當資料訪問以寫操作為主，而讀操作則集中在最近寫入的資料上時，使用 lsm 樹可以極大程度地減少磁碟的訪問次數，加快訪問速度。
最後，總結一下我們今天講的內容。hbase 作為 google bigtable 的開源實現，完整地繼承了 bigtable 的優良設計。架構上通過資料分片的設計配合 hdfs，實現了資料的分布式海量儲存；資料結構上通過列族的設計，實現了資料表結構可以在執行期自定義；儲存上通過 lsm 樹的方式，使資料可以通過連續寫磁碟的方式儲存資料，極大地提高了資料寫入效能。
這些優良的設計結合 apache 開源社群的高質量開發，使得 hbase 在 nosql 眾多競爭產品中保持領先優勢，逐步成為 nosql 領域最具影響力的產品。
Hbase 學習筆記 Hbase 概覽
hbase構建在 hdfs 之上，hbase內部管理的檔案全部儲存在hdfs 中 行鍵，table的主鍵，table中的記錄按照row key排序。型別為byte array 列簇，table在水平方向有乙個或者多個column family組成，乙個column family中可以由任意多個col...
Hbase學習筆記
1.table中行是按照row key的字典序排列的 2.在行的方向上分隔為多個region 3.hregion是hbase 中分布式儲存和負載均衡的最小單位，這表示不同的region可以分布在不同的regionserver上 當乙個region足夠大時，現在是256m 就會split，乙個regi...
HBase學習筆記
hbase簡介 1 hbase定義 hbase是一種分布式 面向列的開源資料庫。具有良好的擴充套件性 低寫入 查詢延遲的特點。2 hbase與傳統的關聯式資料庫的區別 hbase rdb 資料型別 簡單的，儲存為未經解釋的字串 豐富的資料型別和儲存方式 資料操作 只有簡單的插入 查詢 刪除和清空等 ...