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

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

HBase 的详细介绍：请点这里
HBase 的下载地址：请点这里