一、架構思路
Hbase是基於Hadoop的項目，所以一般情況下我們使用的直接就是HDFS文件系統，這裏我們不深談HDFS如何構造其分佈式的文件系統，只需要知道雖然Hbase中有多個RegionServer的概念，並不意味着數據是持久化在RegionServer上的，事實上，RegionServer是調度者，管理Regions，但是數據是持久化在HDFS上的。明確這一點，在後面的討論中，我們直接把文件系統抽象爲HDFS，不再深究。
Hbase是一個分佈式的數據庫，使用Zookeeper來管理集羣。在架構層面上分爲Master（Zookeeper中的leader）和多個RegionServer，基本架構如圖：
在Hbase的概念中，RegionServer對應於集羣中的一個節點，而一個RegionServer負責管理多個Region。一個Region代表一張表的一部分數據，所以在Hbase中的一張表可能會需要很多個Region來存儲其數據，但是每個Region中的數據並不是雜亂無章的，Hbase在管理Region的時候會給每個Region定義一個Rowkey的範圍，落在特定範圍內的數據將交給特定的Region，從而將負載分攤到多個節點上，充分利用分佈式的優點。另外，Hbase會自動的調節Region處在的位置，如果一個RegionServer變得Hot（大量的請求落在這個Server管理的Region上），Hbase就會把Region移動到相對空閒的節點，依次保證集羣環境被充分利用。
二、存儲模型
有了架構層面的保證，接下來的事情就只是關注於數據的具體存儲了。這裏就是每個Region所承擔的工作了。我們知道一個Region代表的是一張Hbase表中特定Rowkey範圍內的數據，而Hbase是面向列存儲的數據庫，所以在一個Region中，有多個文件來存儲這些列。Hbase中數據列是由列簇來組織的，所以每一個列簇都會有對應的一個數據結構，Hbase將列簇的存儲數據結構抽象爲Store，一個Store代表一個列簇。
所以在這裏也可以看出爲什麼在我們查詢的時候要儘量減少不需要的列，而經常一起查詢的列要組織到一個列簇裏：因爲要需要查詢的列簇越多，意味着要掃描越多的Store文件，這就需要越多的時間。
我們來深入Store中存儲數據的方式。Hbase的實現是用了一種LSM 樹的結構，LSM樹是由B+樹改進而來，所以我們首先來簡單的看看B+樹。
這是一顆簡單的B+樹，含義不言而喻，這裏不多分析，但是這種數據結構並不適合Hbase中的應用場景。這樣的數據結構在內存中效率是很高的，但是Hbase中數據是存儲在文件中的，如果按照這樣的結構來存儲，意味着我們每一次插入數據都要由一級索引找到文件再在文件中間作操作來保證數據的有序性，這無疑是效率低下的。所以Hbase採用的是LSM樹的結構，這種結構的關鍵是，每一次的插入操作都會先進入MemStore（內存緩衝區），當MemStore達到上限的時候，Hbase會將內存中的數據輸出爲有序的StoreFile文件數據（根據Rowkey、版本、列名排序，這裏已經和列簇無關了因爲Store裏都屬於同一個列簇）。這樣會在Store中形成很多個小的StoreFile，當這些小的File數量達到一個閥值的時候，Hbase會用一個線程來把這些小File合併成一個大的File。這樣，Hbase就把效率低下的文件中的插入、移動操作轉變成了單純的文件輸出、合併操作。
由上可知，在Hbase底層的Store數據結構中，每個StoreFile內的數據是有序的，但是StoreFile之間不一定是有序的，Store只需要管理StoreFile的索引就可以了。這裏也可以看出爲什麼指定版本和Rowkey可以加強查詢的效率，因爲指定版本和Rowkey的查詢可以利用StoreFile的索引跳過一些肯定不包含目標數據的數據。
