Hive->Tez/Stinger未來工作的主要方向：Cost-based optimizer，基于統(tǒng)計選擇執(zhí)行策略，例如多表JOIN時按照怎樣的順序執(zhí)行效率最高。統(tǒng)計執(zhí)行過程中每個中間表的Row/Column等數(shù)目，從而決定啟動多少個MR執(zhí)行。
Impala
Impala可以看成是Google Dremel架構(gòu)和MPP (Massively Parallel Processing)結(jié)構(gòu)的混合體，目前主要是Cloudera在主導(dǎo)這個項目。
優(yōu)點：
目前支持兩種類型的JOIN：broadcast join和partition join。對于大表JOIN時由于內(nèi)存限制，裝不下時就要dump部分?jǐn)?shù)據(jù)到磁盤，那樣就會比較慢。
Impala各個任務(wù)之間傳輸數(shù)據(jù)采用的是push的方式(MR采用的是pull的方式)，也就是上游任務(wù)計算完就會push到下游，這樣能夠分散網(wǎng)絡(luò)壓力，提高job執(zhí)行效率。
Parquet列存格式，同時能夠處理嵌套數(shù)據(jù)。通過嵌套數(shù)據(jù)以及擴(kuò)展的SQL查詢語義，在某些特定的場景上避開了JOIN從而解決了一部分性能的bottleneck。
Cloudera Manager 4.6以后會有slow query的分析功能。
Runtime Code Generation
缺點：
Impala不會按照group by的列排序
目前不支持UDF，Impala 1.2即將支持Hive UDFs和Impala native UDFs and UDAs
不支持像Hive的Serializer/Deserializer，從而使得它做從非結(jié)構(gòu)化到結(jié)構(gòu)化數(shù)據(jù)的ETL工作比較麻煩。所以本質(zhì)上講Impala適合MR配合做ETL之后的查詢工作。
由于Impala的設(shè)計初衷是short query，所以不支持fault tolerance。如果參與查詢的某個node出錯，Impala將會丟棄本次查詢。
安全方面的支持還比較差。impalad之間傳輸?shù)臄?shù)據(jù)沒有加密，不支持表或者列級別的授權(quán)。
每個PlanFragment執(zhí)行盡量并行化，但是有的時候并不是很容易。例如Hash Join需要等到其中一個表完全Scan結(jié)束才能開始。
雖然有這么多缺點，但是很多公司還是開始嘗試Impala了。以百度為 例，百度嘗試把MySQL接入Impala的后端作為存儲引擎，同時實現(xiàn)相應(yīng)操作對應(yīng)的PlanFragment，那么用戶來的query還是按照原來的 解析方法解析成各種PlanFragment，然后直接調(diào)度到對應(yīng)的節(jié)點(HDFS DataNode/HBaseRegionServer/MySQL)上執(zhí)行。會把某些源數(shù)據(jù)或者中間數(shù)據(jù)放到MySQL中，用戶的query涉及到使用 這部分?jǐn)?shù)據(jù)時直接去MySQL里面拿。
Shark/Spark
由于數(shù)據(jù)能放到內(nèi)存盡量放到內(nèi)存，使用內(nèi)存非常aggressive。優(yōu)點是做JOIN時會比較快，缺點是占用內(nèi)存太大，且自行管理內(nèi)存，占用內(nèi)存后不會釋放。
由于Shark借用了Hive的codebase，所以在SQL，SerDes，UDF支持方面和Hive是完全兼容的。
支持從short query到long time query等不同粒度的查詢，所以具有fault tolerance特性。
性能：特別簡單的select…where查詢，shark性能的提升不明顯(因為hive也不怎么費時間)。但是如果查詢比較復(fù)雜 select…join…where…group by，hive的job數(shù)目會比較多，讀寫HDFS次數(shù)增多，時間自然會變長。當(dāng)內(nèi)存還足夠大的時候shark性能是最好的，如果內(nèi)存不夠裝下所有的數(shù)據(jù) 時性能會下降，但還是會比Hive好很多。
Phoenix
Salesforce開源的基于HBase的SQL查詢系統(tǒng)?；驹硎菍⒁粋€對于HBase client來說比較復(fù)雜的查詢轉(zhuǎn)換成一系列Region Scan，結(jié)合coprocessor和custom filter在多臺Region Server上進(jìn)行并行查詢，匯總各個Scan結(jié)果。種種跡象表明，Phoenix應(yīng)該不是個優(yōu)化的OLAP系統(tǒng)，更像是一個用于簡單單表查詢，過濾，排 序，檢索的OLTP系統(tǒng)。
優(yōu)點：
HBase默認(rèn)存儲的數(shù)據(jù)類型都是字符串，但Phoenix支持更多的數(shù)據(jù)類型。