使用JDBC操作數據，而不是HBase client API
在RegionServer端通過coprocessor過濾where條件，執(zhí)行aggregation函數。比較Hive on HBase,Impala on HBase和Phoenix這三者的架構是相似的，不同點就是Hive on HBase和Impala on HBase都沒有把coprocessor利用好，都是通過HBase client API把數據讀到他們自己進程的內存之后才進行的filter, aggregation等操作。
從查詢的角度來看HBase的column主要分為兩類：primary key(row key column)和other columns。主要的不同是row key column能夠利用Region Server的index, filter, sort等特性，而other columns沒有這些特性，只能通過二級索引輔助做一些優(yōu)化。Phoenix能夠在HBase上創(chuàng)建二級索引用于優(yōu)化條件查詢(目前只支持在 static table上建二級索引，一個更通用的HBase二級索引實現方法參考 https://github.com/Huawei-Hadoop/hindex)。
如果是row key column上的IN/OR/LIKE條件，可以通過Region Server的skip scan filter優(yōu)化。
Dynamic columns支持。
AutoCommit=false時(默認是false)把所有操作先緩存在客戶端，只有你顯示commit時才一次批量提交到HBase，SQL解析優(yōu)化全是在客戶端做，這個有點事務的意思。
缺點：
不支持JOIN，考慮到HBase的設計初衷是盡量用冗余數據減少復雜的JOIN操作，實際上可以把相關數據都放在同一個表里，而不需要為了減少數據冗余，拆分到多個表中，所以很大程度也可以認為這不是一個缺點。
從架構上看也僅是把SQL轉成HBase Client的API和coprocessor的調用，而且coprocessor還不適合大規(guī)模數據的傳輸，所以如果中間結果的數據量還是比較大的話性能問題還是很明顯的。
這個缺點是所有的基于HBase的SQL系統(tǒng)都有的(包括Hive on HBase和Impala on HBase)。不管什么請求到HBase Region Server這邊都得通過RegionScanner，這個接口不是面向OLAP型應用優(yōu)化的存儲文件讀取接口。例如RegionScanner的實現里 好多條件比較，是不利于全表掃描的。
還有個問題就是coprocessor的問題了，由于coprocessor和HBase Region Server是在一個JVM里面，所以當coprocessor計算邏輯非常復雜，中間結果數據量很大的時候會占用大量內存。同時coprocessor 不是流式地讀取數據，某些節(jié)點數據積累過多也會造成內存不夠用的問題。
RoadMap:
JOIN支持，雖然有點不符合設計初衷，但是大家都支持，就我不支持，太過時了吧。
Transaction支持，通過參考 https://github.com/yahoo/omid的方法。
Online Schema Evolution，動態(tài)改變column的類型，rename等。
Hadapt/HadoopDB
架構和Hive相似，底層存儲引擎有兩種：HDFS和RDBMS(PostgreSQL)，一個DataNode節(jié)點上有一個RDBMS節(jié)點。
提供兩種接口：SQL和MR，SQL也是解析成MR job來執(zhí)行的，所以總的來說執(zhí)行引擎都是MR。
把多個MR任務，轉換成單node上的SQL+一個MR(data shuffle)，這個跟水平壓縮，垂直壓縮類似，盡量減少SQL解析出的MR task個數，減少任務之間寫HDFS的IO數據量。把一個SQL拆解成兩部分：適合SQL做的用單機SQL，不適合的用MR(data shuffle)
和Hive的不同點在于Hive只能操控HDFS上的數據，而Hadapt可以操控HDFS和RDBMS兩種數據來源。對于RDBMS這個數據 源來說，數據被預先load到分布式的RDBMS節(jié)點中，有統(tǒng)一的Catalog管理所有RDBMS中的數據。例如Map中的有些執(zhí)行邏輯直接通過一個在 RDBMS上執(zhí)行的SQL來獲得(修改InputFormat)，然后使用MR來做JOIN/Group By。而且如果在數據被load到分布式PG節(jié)點上時分布情況正好符合group by/order by的條件，那么還省得通過MR的shuffle來做了。
Hadapt的本質還是把SQL解析成MR任務來做，所以Hive的有些缺點(啟動時間長，JOIN效率較低)它也是具有的。還有如果想要join/group by/order by能夠在RDBMS數據源之間高效執(zhí)行，還得考慮數據預分布的問題。