Hadoop上時實類SQL查詢系統對比

以前只用過Hive與impala兩個類SQL查詢系統，最近又將Hortonworks開源的Stinger與Apache的Drill做了些調研。累死累活搞了一天的資料，頭都大了。為了紀念我那逝去的腦細胞，特將這些信息整理出來。

由于調查時間比較短（一天的時間都頭暈眼花了，再長點估計我就要過勞死了），所寫之處難免會有差錯，歡迎大家指正

總體來說雖然impala、stinger、drill三個系統都是類SQL實時查詢系統，但是它們的側重點完全不同。而且它們也不是為了替換Hive而生，hive在做數據倉庫時還是很有價值的。

目前來說只有impala比較成熟（人家標稱要使用CDH版本hadoop，如果要使用apache的，要做好測試的心里準備）。

其它兩個系統還都處理孵化狀態，但是前景非常不錯。

Impala

這個系統是Cloudera開源的，時間大約是在12年下半年。雖然到現在才一年的時間但是已經有很多人在使用。社區也比較活躍，大家可以在github上面看到項目的開發人員與代碼提交情況（地址：https://github.com/cloudera/impala）。個人感覺開發者雖然有其它幾個公司，但是還是以cloudera為主。這樣也造就了impala開發的比較快速，雖然到現在才一年左右的時間，但是impala已經可以很穩定的運行。

impala主要是為hdfs與hbase數據提供實時SQL查詢。它是根據google的dremel論文實現的一套分布式系統，自用戶提交的SQL開始都是基于自身的分析器與執行器。下圖是其架構圖

（圖片來源自impala安裝使用說明書）

由 于完全脫離了M/R技術，自身根據HDFS的文件分布來調整計算，所以速度較Hive有很大提升。根據我個人使用部分TPC基準測（為什么是部分？沒理 由，我只選了一部分SQL來跑），impala雖然性能提升不像Cloudera標稱的達到hive的一百倍，但是在比較復雜的情況下達到40-70倍性 能提高還是有的。

就日常使用來說，標稱是支持大部分SQL-92標準（我也不清楚這個標準到底有多少，專業的童鞋給點解讀唄！！）。根據我 是測試，日常用的SQL都沒有問題。并且impala支持JDBC與ODBC的連接，這對于我們的使用也是很必要的，基于此特點我們可以開發對應業務系統 的UI部分，從而不用要求業務人員自己下SQL了（這是為數不多的展現工作成果的時候了）。

其次就是impala支持的文件格式，我們存取 數據的時候肯定要應景的選擇壓縮與否以及文件的存儲格式。impala支持常用的Text、Sequence、avro格式，壓縮方面支持Snappy、 bzip、gzip以及deflate壓縮應該可以滿足我們大部分的使用場景了。

而最棒的是它的UDF功能可以直接使用hive的udf庫，而不需要修改任何代碼，使用hive的童鞋可以慶祝了，很多任務不需要任何改變即可平滑切換 impala。不過因為impala使用的是C開發的，所以impala還是鼓勵大家寫一個c下面的udf來提高性能。

drill

開源時間跟impala差不多，只不過屬于Apache,。這個系統的目標很宏大--抽象所有數據源，做成統一接口。底層支持hbase、mongoDB、HDFS、Cassandra等數據源。

它的數據接口都是插件化，理論上支持各種查詢語言，SQL自然也不例外，不過目前這個系統還是Apache的一個孵化項目，很多功能尚未完成與穩定。但是可以預見，這個系統如果完成是很有影響力的。下圖為drill的架構圖。

（圖片來源https://cwiki.apache.org/confluence/display/DRILL/High-level+Architecture）

Stinger

Hortonworks開源的一個實時類SQL查詢系統，也是聲稱可以提升較hive 100倍的速度（悲崔的hive，都拿它來當反面教材）。目前處于其計劃中三個階段的最后一個階段。

綜合來看Hortonwork做的事是在hive等分析系統的現有基上加了一個優化層，所有的事都要經過它的優化層Tez（此框架是基于Yarn）來處 理，以減少不必要的工作以及資源開銷。雖然它也對HIVE進行了很多的優化與加強，但是這個效果就要看子系統Tez的表現的了。Tez目前也是 apache的孵化項目，Stringer如果要穩定可以商用依然還有很多路要走。

從下面的示意圖大家可以了解Tez所處的位置。

（圖片來源：http://hortonworks.com/hadoop/tez/）

來自：http://my.oschina.net/Senger/blog/180140