在批處理時代，Hive一枝獨秀；在實時交互式查詢時代，呈現出的是百花齊放的局面。Hive on Tez, Hive on Spark, Spark SQL, Impala等等，目前看也沒有誰幹掉誰的趨勢。引用今年圖靈獎得主Michael Stonebraker的話說，現在的數據庫領域已經不是”one size fit all”的時代了。那麼面對這麼多系統，我們改如何選擇呢？這裏談談這些系統的區別和優缺點。
Hive/Tez/Stinger目前的主要推動者是hortonworks和Yahoo!。剛剛結束的2015 Hadoop Summit(San Jose)上，Yahoo分享了他們目前生產環境中Hive on Tez的一些情況。顯示和Hive 0.10(RCFile)相比，目前的Hive on Tez在1TB的數據量查詢的加速比平均爲6.2倍。目前的Hive on Tez已經是production-ready。Tez這個執行引擎和Spark比較類似，原來的MR只能執行Map和Reduce兩種操作，現在的Tez可以把Job解析成DAG來執行。除此之外還有一些進一步優化Hive執行效率的工作，例如Vectorized Execution和ORCFile等。Dropbox也透露他們的Hive集羣下一步的升級目標就是Hive on Tez。
Hive on Spark目前的主要推動者是Cloudera，可以認爲是Hive社區這邊搞的”Hive on Spark”。剛剛release了第一個使用版本，目前不能用於生產環境。Hive on Spark既能利用到現在廣泛使用的Hive的前端，又能利用到廣泛使用的Spark作爲後端執行引擎。對於現在既部署了Hive，又部署了Spark的公司來說，節省了運維成本。
對於上面提到的Hive on Tez和Hive on Spark兩種系統都具備的優點是：
1，現存的Hive jobs可以透明、無縫遷移到Hive on ***平臺，可以利用Hive現有的ODBC/JDBC，metastore, hiveserver2, UDF，auditing, authorization, monitoring系統，不需要做任何更改和測試，遷移成本低。
2，無論後端執行引擎是MapReduce也好，Tez也好，Spark也好，整個HiveSQL解析、生成執行計劃、執行計劃優化的過程都是非常類似的。而且大部分公司都積累了一定的Hive運維和使用經驗，那麼對於bug調試、性能調優等環節會比較熟悉，降低了運維成本。
Spark SQL主要的推動者是Databricks。提到Spark SQL不得不提的就是Shark。Shark可以理解爲Spark社區這邊搞的一個”Hive on Spark”，把Hive的物理執行計劃使用Spark計算引擎去執行。這裏面會有一些問題，Hive社區那邊沒有把物理執行計劃到執行引擎這個步驟抽象出公共API，所以Spark社區這邊要自己維護一個Hive的分支，而且Hive的設計和發展不太會考慮到如何優化Spark的Job。但是前面提到的Hiveon Spark卻是和Hive一起發佈的，是由Hive社區控制的。
所以後來Spark社區就停止了Shark的開發轉向Spark SQL（“坑了”一部分當時信任Shark的人）。SparkSQL是把SQL解析成RDD的transformation和action，而且通過catalyst可以自由、靈活的選擇最優執行方案。對數據庫有深入研究的人就會知道，SQL執行計劃的優化是一個非常重要的環節，Spark SQL在這方面的優勢非常明顯，提供了一個非常靈活、可擴展的架構。但是SparkSQL是基於內存的，元數據放在內存裏面，不適合作爲數據倉庫的一部分來使用。所以有了Spark SQL的HiveContext，就是兼容Hive的Spark SQL。它支持HiveQL, Hive Metastore, HiveSerDes and Hive UDFs以及JDBC driver。這樣看起來很完美，但是實際上也有一些缺點：Spark SQL依賴於Hive的一個snapshot，所以它總是比Hive的發佈晚一個版本，很多Hive新的feature和bug fix它就無法包括。而且目前看Spark社區在Spark的thriftserver方面的投入不是很大，所以感覺它不是特別想朝着這個方向發展。還有一個重要的缺點就是Spark SQL目前還不能通過分析SQL來預測這個查詢需要多少資源從而申請對應的資源，所以在共享集羣上無法高效地分配資源和調度任務。特別是目前Spark社區把Spark SQL朝向DataFrame發展，目標是提供一個類似R或者Pandas的接口，把這個作爲主要的發展方向。DataFrame這個功能使得Spark成爲機器學習和數據科學領域不可或缺的一個組件，但是在數據倉庫（ETL，交互式分析，BI查詢）領域感覺已經不打算作爲他們主要的發展目標了。
Impala主要的推動者是Cloudera，自從推出以來一直不溫不火。Impala是一種MPP架構的執行引擎，查詢速度非常快，是交互式BI查詢最好的選擇，即使是在併發性非常高的情況下也能保證查詢延遲，所以在multi-tenant,shared clusters上表現比較好。Impala的另外一個重要的優點就是支持的SQL是在以上這些系統中是最標準的，也就是跟SQL99是最像的，所以對於傳統企業來說可能是個不錯的選擇。Impala的主要缺點是社區不活躍，由C++開發，可維護性差，目前系統穩定性還有待提高。
Presto是Facebook開發的，目前也得到了Teradata的支持。目前Presto的主要使用者還是互聯網公司，像Facebook，Netflix等。Presto的代碼用了Dependency Injection, 比較難理解和debug。另外還有一些系統，像Apache Drill，Apache Tajo等，都是非常小衆的系統了。
總的來說，目前來看Hive依然是批處理/ETL 類應用的首選。Hive on Spark能夠降低Hive的延遲，但是還是達不到交互式BI查詢的需求。目前交互式BI查詢最好的選擇是Impala。SparkSQL/DataFrame是Spark用戶使用SQL或者DataFrame API構建Spark pipeline的一種選擇，並不是一個通用的支持交互式查詢的引擎，更多的會用在基於Spark的機器學習任務的數據處理和準備的環節。
