Hbase和Hive的區別，Hbase與傳統資料庫的區別
HBase 於 Hive 的區別，我們簡單的梳理一下 Hive 和 HBase 的應用場景：
Hive 適合用來對一段時間內的資料進行分析查詢，例如，用來計算趨勢或者網站的日誌。Hive 不應該用來進行實時的查詢（Hive 的設計目的，也不是支援實時的查詢）。因為它需要很長時間才可以返回結果；HBase 則非常適合用來進行大資料的實時查詢，例如 Facebook 用 HBase 進行訊息和實時的分析。對於 Hive 和 HBase 的部署來說，也有一些區別，Hive 一般只要有 Hadoop 便可以工作。而 HBase 則還需要 Zookeeper 的幫助（Zookeeper，是一個用來進行分散式協調的服務，這些服務包括配置服務，維護元資訊和名稱空間服務）。再而，HBase 本身只提供了 Java 的 API 介面，並不直接支援 SQL 的語句查詢，
HBase 與傳統關係資料庫的區別
首先讓我們瞭解下什麼是 ACID。ACID 是指資料庫事務正確執行的四個基本要素的縮寫，其包含：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）以及永續性（Durability）。對於一個支援事務（Transaction）的資料庫系統，必需要具有這四種特性，否則在事務過程（Transaction Processing）當中無法保證資料的正確性，交易過程極可能達不到交易方的要求。下面，我們就簡單的介紹下這 4 個特性的含義。
- 原子性(Atomicity)是指一個事務要麼全部執行,要麼全部不執行。換句話說，一個事務不可能只執行了一半就停止了。比如一個事情分為兩步完成才可以完成，那麼這兩步必須同時完成，要麼一步也不執行，絕不會停留在某一箇中間狀態。如果事物執行過程中，發生錯誤，系統會將事物的狀態回滾到最開始的狀態。
- 一致性(Consistency)是指事務的執行並不改變資料庫中資料的一致性。也就是說，無論併發事務有多少個，但是必須保證資料從一個一致性的狀態轉換到另一個一致性的狀態。例如有 a、b 兩個賬戶，分別都是 10。當 a 增加 5 時，b 也會隨著改變，總值 20 是不會改變的。
- 隔離性（Isolation）是指兩個以上的事務不會出現交錯執行的狀態。因為這樣可能會導致資料不一致。如果有多個事務，執行在相同的時間內，執行相同的功能，事務的隔離性將確保每一事務在系統中認為只有該事務在使用系統。這種屬性有時稱為序列化，為了防止事務操作間的混淆，必須序列化或序列化請求，使得在同一時間僅有一個請求用於同一資料。
- 永續性(Durability)指事務執行成功以後,該事務對資料庫所作的更改便是持久的儲存在資料庫之中，不會無緣無故的回滾。
在具體的介紹 HBase 之前，我們先簡單對比下 HBase 與傳統關係資料庫的（RDBMS，全稱為 Relational Database Management System）區別。如表 1 所示。
表 1. HBase 與 RDBMS 的區別
| HBase | RDBMS | |
|---|---|---|
| 硬體架構 | 類似於 Hadoop 的分散式叢集，硬體成本低廉 | 傳統的多核系統，硬體成本昂貴 |
| 容錯性 | 由軟體架構實現，由於由多個節點組成，所以不擔心一點或幾點宕機 | 一般需要額外硬體裝置實現 HA 機制 |
| 資料庫大小 | PB | GB、TB |
| 資料排布方式 | 稀疏的、分佈的多維的 Map | 以行和列組織 |
| 資料型別 | Bytes | 豐富的資料型別 |
| 事物支援 | ACID 只支援單個 Row 級別 | 全面的 ACID 支援，對 Row 和表 |
| 查詢語言 | 只支援 Java API （除非與其他框架一起使用，如 Phoenix、Hive） | SQL |
| 索引 | 只支援 Row-key，除非與其他技術一起應用，如 Phoenix、Hive | 支援 |
| 吞吐量 | 百萬查詢/每秒 | 數千查詢/每秒 |
理解了上面的表格之後，我們在看看資料是如何在 HBase 以及 RDBMS 中排布的。首先，資料在 RDBMS 的排布大致如表 2。
表 2. 資料在 RDBMS 中的排布示例
| ID | 姓 | 名 | 密碼 | 時間戳 |
|---|---|---|---|---|
| 1 | 張 | 三 | 111 | 20160719 |
| 2 | 李 | 四 | 222 | 20160720 |
那麼資料在 HBase 中的排佈會是什麼樣子呢？如表 3 所示（這只是邏輯上的排布）。
表 3. 資料在 HBase 中的排布（邏輯上）
| Row-Key | Value（CF、Qualifier、Version） |
|---|---|
| 1 | info{'姓': '張'，'名':'三'} pwd{'密碼': '111'} |
| 2 | Info{'姓': '李'，'名':'四'} pwd{'密碼': '222'} |
從上面示例表中，我們可以看出，在 HBase 中首先會有 Column Family 的概念，簡稱為 CF。CF 一般用於將相關的列（Column）組合起來。在物理上 HBase 其實是按 CF 儲存的，只是按照 Row-key 將相關 CF 中的列關聯起來。物理上的資料排布大致可以如表 4 所示。
表 4. 資料在 HBase 中的排布
| Row-Key | CF:Column-Key | 時間戳 | Cell Value |
|---|---|---|---|
| 1 | info:fn | 123456789 | 三 |
| 1 | info:ln | 123456789 | 張 |
| 2 | info:fn | 123456789 | 四 |
| 2 | info:ln | 123456789 | 李 |
我們已經提到 HBase 是按照 CF 來儲存資料的。在表 3 中，我們看到了兩個 CF，分別是 info 和 pwd。info 儲存著姓名相關列的資料，而 pwd 則是密碼相關的資料。上表便是 info 這個 CF 儲存在 Hbase 中的資料排布。Pwd 的資料排布是類似的。上表中的 fn 和 ln 稱之為 Column-key 或者 Qulifimer。在 Hbase 中，Row-key 加上 CF 加上 Qulifier 再加上一個時間戳才可以定位到一個單元格資料（Hbase 中每個單元格預設有 3 個時間戳的版本資料）。初學者，在一開始接觸這些概念是很容易混淆。其實不管是 CF 還是 Qulifier 都是客戶定義出來的。也就是說在 HBase 中建立表格時，就需要指定表格的 CF、Row-key 以及 Qulifier。我們會在後續的介紹中，嘗試指定這些相關的概念，以便加深理解。這裡我們先通過下圖理解下 HBase 中，邏輯上的資料排布與物理上的資料排布之間的關係。
圖 1. Hbase 中邏輯上資料的排布與物理上排布的關聯
從上圖我們看到 Row1 到 Row5 的資料分佈在兩個 CF 中，並且每個 CF 對應一個 HFile。並且邏輯上每一行中的一個單元格資料，對應於 HFile 中的一行，然後當用戶按照 Row-key 查詢資料的時候，HBase 會遍歷兩個 HFile，通過相同的 Row-Key 標識，將相關的單元格組織成行返回，這樣便有了邏輯上的行資料。講解到這，我們就大致瞭解 HBase 中的資料排布格式，以及與 RDBMS 的一些區別。
對於 RDBMS 來說，一般都是以 SQL 作為為主要的訪問方式。而 HBase 是一種"NoSQL"資料庫。"NoSQL"是一個通用詞表示該資料庫並不是 RDBMS 。現在的市面上有許多種 NoSQL 資料庫，如 BerkeleyDB 是本地 NoSQL 資料庫的例子, HBase 則為大型分散式 NoSql 資料庫。從技術上來說，Hbase 更像是"資料儲存"而非"資料庫"（HBase 和 HDFS 都屬於大資料的儲存層）。因此，HBase 缺少很多 RDBMS 特性，如列型別，二級索引，觸發器和高階查詢語言等。然而, HBase 也具有許多其他特徵同時支援線性化和模組化擴充。最明顯的方式，我們可以通過增加 Region Server 的數量擴充套件 HBase。並且 HBase 可以放在普通的伺服器中，例如將叢集從 5 個擴充到 10 個 Region Server 時，儲存空間和處理容量都可以同時翻倍。當然 RDBMS 也能很好的擴充，但僅對一個點，尤其是對一個單獨資料庫伺服器而言，為了更好的效能，往往需要特殊的硬體和儲存裝置（往往價格也非常昂貴）。