A SQL layer over HBase delivered as a client-embedded JDBC drivertargeting low latency queries over HBase data
不同于Hive on HBase的方式，Phoenix将Query Plan直接使用HBaseAPI实现，目的是规避MapReduce框架，减少查询的时间延迟
Phoenix中SQL Query Plan的执行，基本上是通过构建一系列的Hbase scan来完成。
为了尽可能减少数据传输，在Region Server使用Coprocessor来尽可能的执行Aggregate相关工作，基本思想是使用RegionObserver在PostScannerOpen hook中将RegionScanner替换成支持Aggregation工作的定制化的Scanner，具体的Aggregate操作通过custom的scan属性传递给RegionScanner。与基于MapReduce的框架执行Plan的思想比较，基本上就是通过Coprocessor，使用RegionServer自身来在各个节点上执行Aggregation。
采用JDBC接口和应用程序交互。
二、hbase建表、phoenix格式数据导入
创建表结构、rowkey索引确定
根据业务需求建表、rowkey、索引列，前期规划设计对后期查询性能的优化尤为重要。
表字段类型要前期规划好，比如要排序的字段，最好是用int或者bigint，要确定常用查询列。确定rowkey，确定hbase分区规则，防止后面数据倾斜。
为了查询性能尽量的好，分区规则是有规则的，简单的hash分区，效果是不好的。
注意：目前支持了不同数据格式的phoenix格式，但是建表的时候还是需要考虑的，比如排序字段尽量考虑int，事先要确定一些常用列，都死为了优化查询。
数据灌入
有三种数据灌入的方式：
1.简单phoenix接口put数据
通过java代码，插入数据进hbase，几条记录写入
HTable table = new HTable(conf, “tableName”);
Put put = new Put(rowkey);
table.put(put);
2.datax少量数据导入
传统的etl开发根据建表sql将云梯生产的数据转换成phoenix格式的文件导入，但文件大小控制在几百M大小，不易过大。
3.hfile超大数据量bulkload
在这里我们遇到了比较大的坎，云梯1、odps对自动脚本灌数据支持的不够好，需要进行个性化需求的开发，中间搞了个收到bulkload到hbase的方法是。
找了台机器单独弄了个 gateway，部署了hadoop客户端，手动bulkload数据。
下载并、配置好环境，搞2个手动bulkload和load的脚本，即可搞了。
（一）bulkload脚本如下图：
alt
（二）bulkload完成后还需要将数据load到hbase的库里，脚本如下：
${HBASE_HOME}/bin/hbase org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles hdfs://hdfscluster-1/group/aplus-48/201403211000/ TABLE_NAME
三、应用层phoenix接口开发、调试
类jdbc数据源、查询等接口开发
需要注意的是：
1.日常环境搭建，因为测试环境没有dns转发，所以需要进行host绑定到相应的zk服务器，
2.应用的预发生产环境都是连hbase的生产环境
2.1 但是必须确保生产环境有正确格式的数据在hbase里面，否则会报一系列的让你难以捉摸的异常。
2.2 因为初期对phoenix语法的不熟悉，你需要搭建一个phoenix的客户端，进行sql查询。
否则java应用启动发布、查错、改sql，这活菊有的你苦了。
你只需要下载一tar包到随便一台能连phoenix生产的机器，一般为预发环境，就可以。
它支持单sql执行，切记要在sql结尾加上分号。
也支持批量的sql执行，psql同时会将sql的执行时间打印出来，如下
alt
3.phoenix的语法和sql基本类似，但是也是有点区别的，比如：
3.1 分页不行mysql那样的limit 1，10 ;
phoenix的格式是where (field1,field2) > ('75','47') limit 10
这里的列值就是上次分页最后一条记录的某个列值。
3.2 join查询的性能会慢
3.3 order by只能在内存里做，limit也是
3.4 当查询结果集大到一定程度，rs读取的速度会降低减慢
3.5 因为很多排序、查询计算会在内存里做，所以phoenix会在应用服务器/tmp目录产生很多临时文件，如果代码中没有将 rs.close(),那么那些临时文件会很快撑爆硬盘。如图：
alt
四、hbase存储结合phoenix优势
1.海量低成本的存储空间
2.快速敏捷接入hbase解决方案phoenix
3.业务逻辑优化过后的匹配特征的高查询性能（一个月4T数据查询速度在毫秒级别）
4.云梯数据快速导入hbase（4T一个小时bulkload完成datax传统导入是它几倍）
4.强大的sql语法、功能支持
5.专业团队持续维护、改进