轉自：http://blog.csdn.net/colorant/article/details/8645081
==是什么 ==
目標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在多表聯合操作方面的能力缺失（當然，所有數據在一個表里存儲，如果帶來更新操作的負擔和一致性問題，那還是要拆分的）
==相關文獻 ==
語法：http://forcedotcom.github.com/phoenix/