快速理解 Phoenix : SQL on HBASE

作者：劉旭暉 Raymond 轉載請註明出處

Email：colorant at 163.com

BLOG：http://blog.csdn.net/colorant/

更多雲端運算相關項目快速理解文檔  http://blog.csdn.net/colorant/article/details/8255910

==是什麼 ==

 

目標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/

Wiki首頁：https://github.com/forcedotcom/phoenix/wiki

代碼：https://github.com/forcedotcom/phoenix