学习学习 |
了解一下 |
luckylee 发表于 2014-12-29 13:45 快速理解 Phoenix : SQL on HBASE ==是什么 == 目标Scope EasyStandard SQL access on top of HBase 官方定义 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。 此外,通过各种定制的Filter在Hbase的RegionScanner scan过程中,尽早的将不相关的数据过滤掉。 采用JDBC接口和应用程序交互。 ==实现 == 目前支持简单的表的创建,修改,数据删减,过滤,检索等SQL语法,从语法上看,不支持多表操作,本质上应该是由于不支持多表联合类的操作如各种Join等,所以在Where部分也就不能做多表的比较。 个人认为,由于Coprocessor和 Filter自身能力的限制,如果完全不依赖Map Reduce框架,只通过HbaseClient API想要实现复杂的Query操作如多表联合操作,相对比较困难,或者大量工作需要在客户端代码中实现,性能上可能无法满足需求。 从RoadMap上来看,打算支持Hash Join,要考虑性能的话,我猜测大概的实现思路是把第一次scan的小表的结果以某种方式保存在内存中供第二次Scan时匹配用,那么应该需要在scan之间保留状态,不知道这点phoneix具体打算怎么实现。 此外,Secondary Index也在计划之中。没有Secondary Index,显然在查询效率方面要大打折扣。 然后,基于HBase的TS Basedversion和不限制qualifier等特性,大概还打算实现一些相对有趣的功能,比如动态column,嵌套数据结构,schema演进等。 适用领域 如果不能找到比较好的办法来实现Join类操作,多表相关的操作都不能高效实现,那么应该只能用于简单的过滤,排序,单表检索类工作。照官方的说法就是适用于10M-100M行规模的简单查询。 不过,考虑到HBase表的设计理念,尽量用冗余数据空间减少复杂性的思想,实际上可以把相关数据都放在同一个表里,而不需要为了减少数据冗余,拆分到多个表中,很大程度上可以规避现阶段Phoenix在多表联合操作方面的能力缺失(当然,所有数据在一个表里存储,如果带来更新操作的负担和一致性问题,那还是要拆分的) 作者:刘旭晖 Raymond 转载请注明出处 Email:colorant at 163.com BLOG:http://blog.csdn.net/colorant/ |
你好,请教个问题啊,Phoenix怎么查看hbase中已经存在的表?我用!tables命令看不到hbase中已经存在的表,谢谢! |
尝试一下,爽歪歪,感谢分享 |
没用过,感觉挺好的, 尝试下 |
fanbells 发表于 2014-1-24 08:52 简单说来phoenix封装了HBase的api,你也可以自己通过api来进行各种操作。 |
不明觉厉,拜读一下 |