上篇主要讨论了Hive, Stinger/Tez, Impala, Shark这些SQL on Hadoop产品，这篇接着讨论Phoenix, Hadapt, Hawq。 Phoenix Salesforce开源的基于HBase的SQL查询系统，建立在HBase client API, coprocessors, custom filter的基础之上。 基本原理是将一个对于HB
上篇主要讨论了Hive, Stinger/Tez, Impala, Shark这些SQL on Hadoop产品，这篇接着讨论Phoenix, Hadapt, Hawq。
Phoenix
- Salesforce开源的基于HBase的SQL查询系统，建立在HBase client API, coprocessors, custom filter的基础之上。
- 基本原理是将一个对于HBase client来说比较复杂的查询转换成一系列Region Scan，结合create table时hook的coprocessor和custom ?filter在多台Region Server上进行并行查询， 汇总各个Scan结果输出给调用程序的ResultSet。说白了就是看大家用HBase client API开发程序太麻烦了，就弄了个JDBC包装，这样对于software engineer来说降低了开发成本，同时对于简单单表查询性能损失不大。
- 种种迹象表明，Phoenix应该不是个优化的OLAP系统，更像是一个用于简单单表查询，过滤，排序，检索的OLTP系统。
优点：
- HBase默认存储的数据类型都是字符串，但Phoenix支持更多的数据类型(int, float, char, varchar, time, date)
- 使用JDBC操作数据，而不是HBase client API
- 在RegionServer端通过coprocessor过滤where条件，执行aggregation函数。Hive on HBase把SQL转化成MapReduce去查询HBase；Impala on HBase把SQL转化成PlanFragment执行计划去查询HBase；?Phoenix把SQL转化成对HBase client API和coprocessor的调用，这三者的架构是相似的。不同点就是Hive on HBase和Impala on HBase都没有把coprocessor利用好，都是通过HBase client API把数据读到他们自己进程的内存之后才进行的filter, aggregation等操作。所以理论上讲前两种架构设计的产品性能不可能超过直接调用HBase Client的方式。
- 从查询的角度来看HBase的column主要分为两类：primary key(row key column)和other columns。主要的不同是row key column能够利用HBase Region Server的index, filter, sort等特性，而other columns没有这些特性，只能通过二级索引辅助做一些优化。Phoenix能够在HBase上创建二级索引用于优化non row key columns的条件查询（目前只支持在static table上建二级索引，一个更通用的HBase二级索引实现方法可以参考华为开源的这个实现https://github.com/Huawei-Hadoop/hindex）。
- salting of row keys to evenly distribute write load
- 如果是来&源gao@dai!ma.com搞$代^码%网row key column上的IN/OR/LIKE条件，可以通过Region Server的skip scan filter优化。
- Dynamic columns支持（跟RDBMS的dynamic schema change类似），也就是用户不需要在create table的时候指定所有的column，后面什么时候需要随时添加。这个功能主要依赖于HBase的动态添加column的功能。
- AutoCommit=false时(默认是false)把所有操作先缓存在客户端，只有你显示commit时才一次批量提交到HBase，SQL解析优化全是在客户端做，这个有点事务的意思。
缺点：
- 不支持JOIN，考虑到HBase的设计初衷是尽量用冗余数据减少复杂的JOIN操作，实际上可以把相关数据都放在同一个表里，而不需要为了减少数据冗余，拆分到多个表中，所以很大程度也可以认为这不是一个缺点。
- 从架构上看也仅是把SQL转成HBase Client的API和coprocessor的调用，而且coprocessor还不适合大规模数据的传输，所以如果中间结果的数据量还是比较大的话性能问题还是很明显的。
- 这个缺点是所有的基于HBase的SQL系统都有的（包括Hive on HBase和Impala on HBase）。不管什么请求到HBase Region Server这边都得通过RegionScanner，这个接口不是面向OLAP型应用优化的存储文件读取接口。例如RegionScanner的实现里好多条件比较，是不利于全表扫描的。所以全表扫描的应用不如一个一个地读HFile，当然前提是得离线把memstore的数据都dump到hfile。目前coprocessor也是走的RegionScanner。这部分要想改得改Region Server代码了，那就是Apache HBase社区的事了。
- 还有个问题就是coprocessor的问题了，由于coprocessor和HBase Region Server是在一个JVM里面，所以当coprocessor计算逻辑非常复杂，中间结果数据量很大的时候会占用大量内存。同时coprocessor不是流式地读取数据，某些节点数据积累过多也会造成内存不够用的问题。
搞代码网（gaodaima.com）提供的所有资源部分来自互联网，如果有侵犯您的版权或其他权益，请说明详细缘由并提供版权或权益证明然后发送到邮箱[email protected]，我们会在看到邮件的第一时间内为您处理，或直接联系QQ：872152909。本网站采用BY-NC-SA协议进行授权
转载请注明原文链接：SQL on Hadoop系统的最新进展(2)
转载请注明原文链接：SQL on Hadoop系统的最新进展(2)
