如何選擇滿足需求的SQL on Hadoop系統(tǒng) - 文章
http://weibo.com/p/1001603864171165928729

在批處理時代故河，Hive一枝獨秀附迷；在實時交互式查詢時代匾灶，呈現(xiàn)出的是百花齊放的局面棱烂。Hive on Tez, Hive on Spark, Spark SQL, Impala等等，目前看也沒有誰干掉誰的趨勢阶女。引用今年圖靈獎得主Michael Stonebraker的話說颊糜，現(xiàn)在的數(shù)據(jù)庫領(lǐng)域已經(jīng)不是”one size fit all”的時代了。那么面對這么多系統(tǒng)秃踩，我們改如何選擇呢衬鱼？這里談?wù)勥@些系統(tǒng)的區(qū)別和優(yōu)缺點。
Hive/Tez/Stinger目前的主要推動者是hortonworks和Yahoo!吞瞪。剛剛結(jié)束的2015 Hadoop Summit(San Jose)上馁启，Yahoo分享了他們目前生產(chǎn)環(huán)境中Hive on Tez的一些情況驾孔。顯示和Hive 0.10(RCFile)相比芍秆，目前的Hive on Tez在1TB的數(shù)據(jù)量查詢的加速比平均為6.2倍。目前的Hive on Tez已經(jīng)是production-ready翠勉。Tez這個執(zhí)行引擎和Spark比較類似妖啥，原來的MR只能執(zhí)行Map和Reduce兩種操作，現(xiàn)在的Tez可以把Job解析成DAG來執(zhí)行对碌。除此之外還有一些進一步優(yōu)化Hive執(zhí)行效率的工作荆虱，例如Vectorized Execution和ORCFile等。Dropbox也透露他們的Hive集群下一步的升級目標(biāo)就是Hive on Tez朽们。
Hive on Spark目前的主要推動者是Cloudera怀读，可以認(rèn)為是Hive社區(qū)這邊搞的”Hive on Spark”。剛剛release了第一個使用版本骑脱，目前不能用于生產(chǎn)環(huán)境菜枷。Hive on Spark既能利用到現(xiàn)在廣泛使用的Hive的前端，又能利用到廣泛使用的Spark作為后端執(zhí)行引擎叁丧。對于現(xiàn)在既部署了Hive啤誊，又部署了Spark的公司來說岳瞭，節(jié)省了運維成本。
對于上面提到的Hive on Tez和Hive on Spark兩種系統(tǒng)都具備的優(yōu)點是：
1蚊锹，現(xiàn)存的Hive jobs可以透明瞳筏、無縫遷移到Hive on ***平臺，可以利用Hive現(xiàn)有的ODBC/JDBC牡昆，metastore, hiveserver2, UDF姚炕，auditing, authorization, monitoring系統(tǒng)，不需要做任何更改和測試丢烘，遷移成本低钻心。
2，無論后端執(zhí)行引擎是MapReduce也好铅协，Tez也好捷沸，Spark也好，整個Hive SQL解析狐史、生成執(zhí)行計劃痒给、執(zhí)行計劃優(yōu)化的過程都是非常類似的。而且大部分公司都積累了一定的Hive運維和使用經(jīng)驗骏全，那么對于bug調(diào)試苍柏、性能調(diào)優(yōu)等環(huán)節(jié)會比較熟悉，降低了運維成本姜贡。
Spark SQL主要的推動者是Databricks试吁。提到Spark SQL不得不提的就是Shark。Shark可以理解為Spark社區(qū)這邊搞的一個”Hive on Spark”楼咳，把Hive的物理執(zhí)行計劃使用Spark計算引擎去執(zhí)行熄捍。這里面會有一些問題，Hive社區(qū)那邊沒有把物理執(zhí)行計劃到執(zhí)行引擎這個步驟抽象出公共API母怜，所以Spark社區(qū)這邊要自己維護一個Hive的分支余耽，而且Hive的設(shè)計和發(fā)展不太會考慮到如何優(yōu)化Spark的Job。但是前面提到的Hive on Spark卻是和Hive一起發(fā)布的苹熏，是由Hive社區(qū)控制的碟贾。
所以后來Spark社區(qū)就停止了Shark的開發(fā)轉(zhuǎn)向Spark SQL（“坑了”一部分當(dāng)時信任Shark的人）。Spark SQL是把SQL解析成RDD的transformation和action轨域，而且通過catalyst可以自由袱耽、靈活的選擇最優(yōu)執(zhí)行方案。對數(shù)據(jù)庫有深入研究的人就會知道干发，SQL執(zhí)行計劃的優(yōu)化是一個非常重要的環(huán)節(jié)朱巨，Spark SQL在這方面的優(yōu)勢非常明顯，提供了一個非常靈活铐然、可擴展的架構(gòu)蔬崩。但是Spark SQL是基于內(nèi)存的恶座，元數(shù)據(jù)放在內(nèi)存里面，不適合作為數(shù)據(jù)倉庫的一部分來使用沥阳。所以有了Spark SQL的HiveContext跨琳，就是兼容Hive的Spark SQL。它支持HiveQL, Hive Metastore, Hive SerDes and Hive UDFs以及JDBC driver桐罕。這樣看起來很完美脉让，但是實際上也有一些缺點：Spark SQL依賴于Hive的一個snapshot，所以它總是比Hive的發(fā)布晚一個版本功炮，很多Hive新的feature和bug fix它就無法包括溅潜。而且目前看Spark社區(qū)在Spark的thriftserver方面的投入不是很大，所以感覺它不是特別想朝著這個方向發(fā)展薪伏。還有一個重要的缺點就是Spark SQL目前還不能通過分析SQL來預(yù)測這個查詢需要多少資源從而申請對應(yīng)的資源滚澜，所以在共享集群上無法高效地分配資源和調(diào)度任務(wù)。
特別是目前Spark社區(qū)把Spark SQL朝向DataFrame發(fā)展嫁怀，目標(biāo)是提供一個類似R或者Pandas的接口设捐，把這個作為主要的發(fā)展方向。DataFrame這個功能使得Spark成為機器學(xué)習(xí)和數(shù)據(jù)科學(xué)領(lǐng)域不可或缺的一個組件塘淑，但是在數(shù)據(jù)倉庫（ETL萝招，交互式分析，BI查詢）領(lǐng)域感覺已經(jīng)不打算作為他們主要的發(fā)展目標(biāo)了存捺。
Impala主要的推動者是Cloudera槐沼，自從推出以來一直不溫不火。Impala是一種MPP架構(gòu)的執(zhí)行引擎捌治，查詢速度非掣诠常快，是交互式BI查詢最好的選擇具滴，即使是在并發(fā)性非常高的情況下也能保證查詢延遲凹嘲，所以在multi-tenant, shared clusters上表現(xiàn)比較好。Impala的另外一個重要的優(yōu)點就是支持的SQL是在以上這些系統(tǒng)中是最標(biāo)準(zhǔn)的构韵，也就是跟SQL99是最像的，所以對于傳統(tǒng)企業(yè)來說可能是個不錯的選擇趋艘。Impala的主要缺點是社區(qū)不活躍疲恢，由C++開發(fā)，可維護性差瓷胧，目前系統(tǒng)穩(wěn)定性還有待提高显拳。
Presto是Facebook開發(fā)的，目前也得到了Teradata的支持搓萧。目前Presto的主要使用者還是互聯(lián)網(wǎng)公司杂数，像Facebook宛畦，Netflix等。Presto的代碼用了Dependency Injection, 比較難理解和debug揍移。另外還有一些系統(tǒng)次和，像Apache Drill，Apache Tajo等那伐，都是非常小眾的系統(tǒng)了踏施。
總的來說，目前來看Hive依然是批處理/ETL 類應(yīng)用的首選罕邀。Hive on Spark能夠降低Hive的延遲畅形，但是還是達(dá)不到交互式BI查詢的需求。目前交互式BI查詢最好的選擇是Impala诉探。Spark SQL/DataFrame是Spark用戶使用SQL或者DataFrame API構(gòu)建Spark pipeline的一種選擇日熬，并不是一個通用的支持交互式查詢的引擎，更多的會用在基于Spark的機器學(xué)習(xí)任務(wù)的數(shù)據(jù)處理和準(zhǔn)備的環(huán)節(jié)肾胯。

8 SQL-on-Hadoop frameworks worth checking out
http://blog.matthewrathbone.com/2014/06/08/sql-engines-for-hadoop.html
Apache Hive
Impala
Presto (Facebook)
Shark
Apache Drill
EMC/Pivotal HAWQ
BigSQL by IBM
Apache Pheonix (for HBase)
Apache Tajo