為啥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引擎層的嘗試，已經有一些比較穩定的解決方案和現實。

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，其主要特性有：

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