什麼是HBase

Apache HBase是執行在Hadoop叢集上的資料庫。為了實現更好的可擴充套件性（scalability），HBase放鬆了對ACID（資料庫的原子性，一致性，隔離性和永續性）的要求。因此HBase並不是一個傳統的關係型資料庫。另外，與關係型資料庫不同的是，儲存在HBase中的資料也不需要遵守某種嚴格的集合格式，這使得HBase是用來儲存結構不嚴格的資料的理想工具。

HBase在大資料應用的架構中應用非常廣泛。但是基於其與關係型資料庫迥異的設計模式，實現這些應用也與基於關係型資料庫來實現非常不同。下文將會對比HBase和關係型資料庫，並淺析HBase的特性。

關係型資料庫與HBase的對比

首先我們要明白在已經存在關係型資料庫的情況下，為什麼產生了所謂的NoSQL/HBase這樣的費關係型資料庫？要解答這個問題，我們需要先了解一下關係型資料庫的優勢和缺點。

• 關係型資料庫提供了標準的資料永續性模型
• SQL語言是事實上的資料操作標準語言
• 關係型資料庫內建了併發資料操作的管理機制
• 關係型資料庫提供全面的資料操作工具

關係型資料庫是長期以來資料儲存的標準工具，那麼我們為什麼還在尋找新的資料儲存方法呢？原因是現在需要儲存的資料越來越多，工業界對資料儲存工具可伸展性的要求也越來越高。一種簡單直接的擴充套件方法是垂直擴充套件，也就是採用更大更高效的伺服器來儲存。但是這種方法成本很高，且可擴充套件性存在一個上限（單臺伺服器的效能是有限的）。

關係型資料庫的侷限性

除垂直擴充套件之外，我們也可以採用水平擴充套件的方法。也就是用伺服器叢集來滿足要求。用來叢集的伺服器可以是效能普通的伺服器。這樣就可以大大降低運營成本。如果我們要採用水平擴充套件的方法來擴充套件關係型資料庫，關係型資料庫中的資料勢必要根據row key分佈儲存，也就意味著某些row key對應的行儲存在某一臺伺服器上，另一些row key對應的行儲存在另一臺伺服器上。然而，要分割一個關係型資料庫是非常複雜的，並且關係型資料庫不具備自動分散式儲存的功能。不僅如此，分佈儲存關係型資料庫，我們將失去總體上的資料庫查詢功能及事務（transaction）的一致性。總而言之，關係型資料庫是為在單臺伺服器上執行而設計的。

除此之外，關係型資料庫中資料庫規範化（database normalization）的理念消除了資料的重複儲存，使得資料儲存更高效。在查詢時為了將資料重新組織起來，就需要需要Join操作。這也進一步使得關係型資料庫的分散式儲存更為困難。

HBase的高效，分散式，可擴充套件性的設計理念

由於HBase在設計上不支援關係和Join這樣的概念，需要一起查詢的資料就被存在一起。因此也就避免了關係型資料庫的一些侷限性。下圖表現了HBase和關係型資料庫在資料儲存模型上的不同。

由於HBase將所有需要一起查詢到資料儲存在一起這一特性，HBase叢集就自然能夠根據key來組織資料。在水平分割的時候，key值的範圍就可以被用來分割資料。每一個伺服器儲存全部資料的一個子集。同時分散式的資料還可以被同時訪問。這大大增強了HBase的可擴充套件性。HBase實際上是Google Big Table的一個實現。Big Table是Google提出的一個用來儲存大規模資料的一個分散式系統。

HBase是基於Column family data store的理念設計的：每一行根據一個row key索引。也就是我們用來查詢的主鍵。同時每一行中有若干column family。每一個column family中有若干相關的column。如下圖所示。

HBase中的row key也是HBase分散式儲存資料的主要根據。在分佈儲存資料的時候，根據row key值的範圍，每一臺伺服器儲存全部資料的一個子集。HBase提供基於行的原子性操作保證。也就是每一個row key對應的行為一個原子操作的單元。

HBase的資料模型

HBase中的資料根據row key分佈。row key類似於關係型資料庫中的主鍵（primary key）。HBase中的資料記錄根據row key的值排序。這是HBase資料儲存的一個重要原則，也是HBase設計架構的一個重要部分。

HBase中資料表根據row key的值分割為不同的區域，每個區域包含一部分連續的行。這些區域被分配給叢集中不同的稱為區域伺服器的資料結點。可擴充套件性就是通過將區域分配給叢集中的不同伺服器實現的。這一操作是自動進行的。也就是HBase如何根據水平擴充套件設計的。

下圖表示了column family是如何對映到儲存檔案的。不同的Column family被儲存在不同的檔案中。這些檔案可以被分別訪問。

資料儲存在HBase表格的cell中。cell中包含key和value以及一些其他的資訊（如version, type等）。其中key部分包括row key，column family，column qualifier, timestamp。並且對於每一個值，key部分都會與其一同被儲存。如下圖所示。

從邏輯上來看，row似乎是以表格的形式儲存的。但事實上，row是以一些cell的集合的形式儲存的。其所對應的每一個cell都儲存了其所對應的上述所有key資訊。

下圖中上半部分是HBase的資料的邏輯佈局，下半部分是檔案的物理佈局。Column family被分別儲存於不同的檔案中。我們每設定一個值，其對應的cell就會儲存所有的key資訊（row key, column family, column qualifier, timestamp）。

綜上所述，對於HBase中每一個cell的值，其完整的索引應當是Table::Row::Column family::Column::Timestamp –> Value。Hbase的表是稀疏的。如果某一列沒有資料，則其不會被儲存。表中的cell有其對應的連續改變的version。version預設參考timestamp，但我們也可以自己定製。對於每一個Table::Row::Column family::Column –> Value，資料庫中可能儲存了多個不同version的值。

Version系統是HBase自動採用的。從CRUD的角度來說，一個put操作既是插入（insert/create），也是更新（Update）操作，每一個數據都會帶有其相應的version。Delete操作並不會立即在物理上刪除資料，而是會給資料加一個刪除標籤。這個標籤會保證資料不會在查詢時被返回。Get操作根據給定的引數返回特定version的資料。預設情況下最新版本的資料將會被返回。儲存在HBase中的同一個資料的不同version的數量也可以配置。這個數量是針對同一個column family而言的。預設情況下，HBase會儲存3個不同version的資料。當資料不同的version數目超過這個數字時，最早version的資料將會被刪除。