大數(shù)據(jù)是現(xiàn)在非常熱門的一個(gè)話題，從工程或者技術(shù)的角度來(lái)看，大數(shù)據(jù)的核心是如何存儲(chǔ)、分析、挖掘海量的數(shù)據(jù)解決實(shí)際的問(wèn)題。那么對(duì)于一個(gè)工程師或者分析師來(lái)說(shuō)，如何查詢和分析TB/PB級(jí)別的數(shù)據(jù)是在大數(shù)據(jù)時(shí)代不 可回避的問(wèn)題。SQL on Hadoop就成為了一個(gè)重要的工具。為什么非要把SQL放到Hadoop上？ SQL易于使用;那為什么非得基于Hadoop呢？Hadoop架構(gòu)具備很強(qiáng)的魯棒性和可擴(kuò)展性。本文從技術(shù)架構(gòu)和最新進(jìn)展兩個(gè)角度分析一下各種SQL on Hadoop產(chǎn)品的優(yōu)缺點(diǎn)和適用范圍：Hive、Tez/Stinger、Impala、Shark/Spark、Phoenix、 Hdapt/HadoopDB、Hawq/Greenplum。
在互聯(lián)網(wǎng)企業(yè)和有大數(shù)據(jù)處理需求的傳統(tǒng)企業(yè)中，基于Hadoop構(gòu)建的數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)來(lái)源主要有以下幾個(gè)：
通過(guò)Flume/Scribe/Chukwa這樣的日志收集和分析系統(tǒng)把來(lái)自Apache/Nginx的日志收集到HDFS上，然后通過(guò)Hive查詢。
通過(guò)Sqoop這樣的工具把用戶和業(yè)務(wù)維度數(shù)據(jù)(一般存儲(chǔ)在Oracle/MySQL中)定期導(dǎo)入Hive，那么OLTP數(shù)據(jù)就有了一個(gè)用于OLAP的副本了。
通過(guò)ETL工具從其他外部DW數(shù)據(jù)源里導(dǎo)入的數(shù)據(jù)。
目前所有的SQL on Hadoop產(chǎn)品其實(shí)都是在某個(gè)或者某些特定領(lǐng)域內(nèi)適合的，沒有silver bullet。像當(dāng)年Oracle/Teradata這樣的滿足幾乎所有企業(yè)級(jí)應(yīng)用的產(chǎn)品在大數(shù)據(jù)時(shí)代是不現(xiàn)實(shí)的。所以每一種SQL on Hadoop產(chǎn)品都在盡量滿足某一類應(yīng)用的特征。典型需求：
interactive query (ms~3min)
data analyst，reporting query (3min~20min)
data mining，modeling and large ETL (20 min ~ hr ~ day)
機(jī)器學(xué)習(xí)需求(通過(guò)MapReduce/MPI/Spark等計(jì)算模型來(lái)滿足)
Hive
Hive是目前互聯(lián)網(wǎng)企業(yè)中處理大數(shù)據(jù)、構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)最常用的解決方案，甚至在很多公司部署了Hadoop集群不是為了跑原生MapReduce程序，而全用來(lái)跑Hive SQL的查詢?nèi)蝿?wù)。
對(duì)于有很多data scientist和analyst的公司，會(huì)有很多相同表的查詢需求。那么顯然每個(gè)人都從Hive中查數(shù)據(jù)速度既慢又浪費(fèi)資源。如果能把經(jīng)常訪問(wèn)的數(shù)據(jù)放到內(nèi)存組成的集群中供用戶查詢那樣效率就會(huì)高很多。Facebook針對(duì)這一需求開發(fā)了Presto，一個(gè)把熱數(shù)據(jù)放到內(nèi)存中供SQL查詢的系統(tǒng)。這個(gè)設(shè)計(jì)思路跟Impala和Stinger非常類似了。使用Presto進(jìn)行簡(jiǎn)單查詢只需要幾百毫秒，即使是非常復(fù)雜的查詢，也只需數(shù)分鐘即可完成，它在內(nèi)存中運(yùn)行，并且不會(huì)向磁盤寫入。Facebook有超過(guò)850名工程師每天用它來(lái)掃描超過(guò)320TB的數(shù)據(jù)，滿足了80%的ad-hoc查詢需求。
目前Hive的主要缺點(diǎn)：
data shuffle時(shí)網(wǎng)絡(luò)瓶頸，Reduce要等Map結(jié)束才能開始，不能高效利用網(wǎng)絡(luò)帶寬。
一般一個(gè)SQL都會(huì)解析成多個(gè)MR job，Hadoop每次Job輸出都直接寫HDFS，大量磁盤IO導(dǎo)致性能比較差。
每次執(zhí)行Job都要啟動(dòng)Task，花費(fèi)很多時(shí)間，無(wú)法做到實(shí)時(shí)。
由于把SQL轉(zhuǎn)化成MapReduce job時(shí)，map、shuffle和reduce所負(fù)責(zé)執(zhí)行的SQL解析出得功能不同。那么就有Map->MapReduce或者 MapReduce->Reduce這樣的需求，這樣可以降低寫HDFS的IO數(shù)量，從而提高性能。但是目前MapReduce框架還不支持 M->MR或者M(jìn)R->R這樣的任務(wù)執(zhí)行。
目前Hive主要的改進(jìn)(主要是體現(xiàn)在 Hive 0.11版本上)：
1. 同一條hive sql解析出的多個(gè)MR任務(wù)的合并。由Hive解析出來(lái)的MR jobs中有非常多的Map->MapReduce類型的job，可以考慮把這個(gè)過(guò)程合并成一個(gè)MRjob。 https://issues.apache.org/jira/browse/HIVE-3952
2. Hive query optimizer(查詢優(yōu)化器是Hive需要持續(xù)不斷優(yōu)化的一個(gè)topic)
例如JOIN順序的優(yōu)化，就是原來(lái)一個(gè)大表和多個(gè)小表在不同column匹配的條件下JOIN需要解析成多個(gè)Map join + MR job，現(xiàn)在可以合并成一個(gè)MR job。