為啥HBase需要搭建SQL引擎層

為啥HBase需要搭建SQL引擎層

現有的SQL解決方案通常都不是水平可伸縮的，因此當資料量變大時會遇到障礙。但是這樣的情況，隨著NoSQL的出現已經得到很大程度的緩解，並且隨著NoSQL技術的完善與成熟，這種情況將會從根本上解決。

我們知道NoSQL區別於關係型資料庫的一點就是NoSQL不使用SQL作為查詢語言，至於為何在NoSQL資料存放區HBase上提供SQL介面，有如下原因：

1.使用諸如SQL這樣易於理解的語言，使人們能夠更加輕鬆地使用HBase。

2.使用諸如SQL這樣更高層次的語言來編寫，減少了編寫的代碼量。

3.執行查詢時，在資料訪問與運行時執行之間加上SQL這樣一層抽象可以進行大量最佳化。例如，對於GROUP BY查詢來說，利用HBase中協同處理器，彙總可以在伺服器上進行，而不必在用戶端，這麼做會極大減少用戶端與伺服器之間傳輸的資料量。此外，也可以在用戶端並存執行GROUP BY，這是根據行健的範圍來截斷掃描而實現的。通過並存執行，結果會更快的返回。所有這些最佳化無需使用者參與，只需執行查詢即可。

基於HBase的SQL引擎實現

現階段業內有一些關於HBase SQL引擎層的嘗試，已經有一些比較穩定的解決方案和現實。

1.Hive整合HBase

Hive與HBase的整合功能從Hive0.6.0版本已經開始出現，利用兩者對外的API介面互相通訊，通訊主要依靠hive_hbase-handler.jar工具包（Hive Storage Handlers）。由於HBase有一次比較大的版本變動，所以並不是每個版本的Hive都能和現有的HBase版本進行整合，所以在使用過程中特別注意的就是兩者版本的一致性。

2.Phoenix

Phoenix由Salesforce.com開源，是構建在Apache HBase之上的一個SQL中介層，可以讓開發人員在HBase上執行SQL查詢。Phoenix 完全使用Java編寫，代碼位於Github上，並且提供了一個用戶端可嵌入的JDBC驅動。對於10w到100w行的簡單查詢來說，Phoenix要勝於Hive。

3.Kundera

Kundera 是一個JPA2.0相容的NoSQL資料存放區的對象映射架構。Kundera基於現有類庫構建，封裝出簡易的API，其主要特性有：

1）支援交叉資料存放區持久性，這意味著使用者可以在不同的資料存放區使用單一方法儲存和擷取相關實體。

2)能夠很好地管理事務，同時支援EntityTransaction和Java Transaction API（JPA）。

3) 相容JPA2.0，嚴格使用JPA注釋對象映射到資料存放區表。

4) 目前支援的NoSQL伺服器包括: HBase,MongoDB,Redis,Neo4j等。

還有其它一些解決方案，例如：Lealone,hbase-sql,Impala等，要麼不成熟，要麼停止更新了，要麼具有局限性。讀者對其感興趣，可以自行去瞭解。

Hadoop+HBase搭建雲端儲存總結 PDF

HBase 結點之間時間不一致造成regionserver啟動失敗

Hadoop+ZooKeeper+HBase叢集配置

Hadoop叢集安裝&HBase實驗環境搭建

基於Hadoop叢集的HBase叢集的配置 ‘

Hadoop安裝部署筆記之-HBase完全分布模式安裝

單機版搭建HBase環境圖文教程詳解

HBase 的詳細介紹：請點這裡
HBase 的：請點這裡

本文永久更新連結地址：