//
SQL on Hadoop技術(shù)分析（一） - 大數(shù)據(jù)和云計(jì)算技術(shù) （歡迎關(guān)注同名微信公眾號(hào)） - ITeye技術(shù)網(wǎng)站
http://jiezhu2007.iteye.com/blog/2314063

自打Hive出現(xiàn)之后，SQL onHadoop相關(guān)系統(tǒng)已經(jīng)百花齊放，速度越來(lái)越快，功能也越來(lái)越齊全。目前比較主流的有Impala，Spark SQL，HAWQ，Tez，Drill，Presto，Tajo等。下面從技術(shù)層面梳理下一個(gè)技術(shù)統(tǒng)一的視角，來(lái)為后續(xù)在技術(shù)方案上選擇做參考。

在SQL on Hadoop系統(tǒng)中，有兩種主流的架構(gòu)，一種是基于某個(gè)運(yùn)行時(shí)框架來(lái)構(gòu)建查詢引擎，典型的案例就是Hive，另一種是仿照MPP數(shù)據(jù)庫(kù)架構(gòu)，典型的如Impala，HAWQ。前者現(xiàn)有運(yùn)行時(shí)框架，然后套上SQL層，后者則是一個(gè)一體化的查詢引擎，有時(shí)我們能聽(tīng)到一種聲音，說(shuō)后者的架構(gòu)優(yōu)于前者，至少在性能上。那么是否果真如此？

從任務(wù)的運(yùn)行角度來(lái)看，MPP類引擎的執(zhí)行方式其實(shí)跟DAG模型是類似的，主要的特點(diǎn)如下：
· DAG v.s. MR：最主要的優(yōu)勢(shì)，中間結(jié)果不寫(xiě)磁盤（除非內(nèi)存不夠）。
· 流水線計(jì)算：上游stage一出結(jié)果馬上推送或者拉到下一個(gè)stage處理，比如多表join時(shí)前兩個(gè)表有結(jié)果直接給第三個(gè)表，不像MR要等兩個(gè)表完全join完再給第三個(gè)表join。
· 高效的IO：本地查詢沒(méi)有多余的消耗，充分利用磁盤。
· 線程級(jí)別的并發(fā)：相比之下MR每個(gè)task要啟動(dòng)JVM，本身就有很大延遲，占用資源也多。

背景
Hadoop的誕生是劃時(shí)代的數(shù)據(jù)變革，但關(guān)系型數(shù)據(jù)庫(kù)時(shí)代的存留也為Hadoop真正占領(lǐng)數(shù)據(jù)庫(kù)領(lǐng)域埋下了許多的障礙。對(duì)SQL（尤其是PL/SQL）的支持一直是Hadoop大數(shù)據(jù)平臺(tái)在替代舊數(shù)據(jù)時(shí)代亟待解決的問(wèn)題。Hadoop對(duì)SQL數(shù)據(jù)庫(kù)的支持度一直是企業(yè)用戶最關(guān)心的訴求點(diǎn)之一，也是他們選擇的Hadoop平臺(tái)的重要標(biāo)準(zhǔn)。

自打Hive出現(xiàn)之后，SQL onHadoop相關(guān)系統(tǒng)已經(jīng)百花齊放，速度越來(lái)越快，功能也越來(lái)越齊全。目前比較主流的有Impala，Spark SQL，HAWQ，Tez，Drill，Presto，Tajo等。下面從技術(shù)層面梳理下一個(gè)技術(shù)統(tǒng)一的視角，來(lái)為后續(xù)在技術(shù)方案上選擇做參考。

系統(tǒng)架構(gòu)：Runtime Framework vs MPP
在SQL on Hadoop系統(tǒng)中，有兩種主流的架構(gòu)，一種是基于某個(gè)運(yùn)行時(shí)框架來(lái)構(gòu)建查詢引擎，典型的案例就是Hive，另一種是仿照MPP數(shù)據(jù)庫(kù)架構(gòu)，典型的如Impala，HAWQ。前者現(xiàn)有運(yùn)行時(shí)框架，然后套上SQL層，后者則是一個(gè)一體化的查詢引擎，有時(shí)我們能聽(tīng)到一種聲音，說(shuō)后者的架構(gòu)優(yōu)于前者，至少在性能上。那么是否果真如此？

一般來(lái)說(shuō)，對(duì)于SQL on Hadoop系統(tǒng)很重要的一個(gè)評(píng)價(jià)指標(biāo)就是:快，低時(shí)延。在Hive逐漸普及后，就逐漸有了所謂交互式的查詢需求，因?yàn)闊o(wú)論是BI系統(tǒng)，還是Ad-hoc，都不能按照離線的方式來(lái)處理。很多廠商都試圖去解決這個(gè)問(wèn)題，于是就有了Impala，HAWQ等，同時(shí)經(jīng)過(guò)不斷的發(fā)展，Hive也能跑在DAG框架上了，不僅有Tez，還有Spark。從任務(wù)的運(yùn)行角度來(lái)看，MPP類引擎的執(zhí)行方式其實(shí)跟DAG模型是類似的，主要的特點(diǎn)如下：
· DAG v.s. MR：最主要的優(yōu)勢(shì)，中間結(jié)果不寫(xiě)磁盤（除非內(nèi)存不夠）。
· 流水線計(jì)算：上游stage一出結(jié)果馬上推送或者拉到下一個(gè)stage處理，比如多表join時(shí)前兩個(gè)表有結(jié)果直接給第三個(gè)表，不像MR要等兩個(gè)表完全join完再給第三個(gè)表join。
· 高效的IO：本地查詢沒(méi)有多余的消耗，充分利用磁盤。
· 線程級(jí)別的并發(fā)：相比之下MR每個(gè)task要啟動(dòng)JVM，本身就有很大延遲，占用資源也多。

當(dāng)然MPP模式也有其劣勢(shì)，一個(gè)是擴(kuò)展性不是很高，這在關(guān)系數(shù)據(jù)庫(kù)時(shí)代就已經(jīng)有過(guò)結(jié)論；另一個(gè)是容錯(cuò)性差，對(duì)于Impala來(lái)說(shuō)一旦運(yùn)行過(guò)程中出點(diǎn)問(wèn)題，整個(gè)查詢就掛了。

存儲(chǔ)格式

主流的存儲(chǔ)格式有，ORC，Parquet，最近華為大數(shù)據(jù)團(tuán)隊(duì)研發(fā)的CarbonData數(shù)據(jù)格式，從原型測(cè)試數(shù)據(jù)，CarbonData性能上比Parquet要快，這主要得益于在構(gòu)建Carbon數(shù)據(jù)格式中，創(chuàng)建了很多的索引，從整個(gè)查詢掃描過(guò)程中，利用索引快速過(guò)濾掉數(shù)據(jù)，減少掃描的數(shù)據(jù)量，類似這樣的系統(tǒng)，有騰訊的Hermes等。另外Impala使用的Parquet格式存儲(chǔ)，現(xiàn)在又有了一種新的解決方案，kudu+Impala的方案，Cloudera宣稱查詢分析非?？?，并且能支持?jǐn)?shù)據(jù)的更新等操作。

資源控制

在SQL on Hadoop方案中，另外一個(gè)客戶關(guān)注的方面是資源控制，在Hadoop體系中，與Yarn的集成。比如目前的Impala版本就不支持通過(guò)Yarn來(lái)管理分布使用資源，不過(guò)從Impala的版本路標(biāo)中，與Yarn的數(shù)據(jù)集成已經(jīng)是Impala的一個(gè)重要的目標(biāo)。目前能與Yarn集成的有Spark SQL，HAWQ等.

總結(jié)

SQL on Hadoop的技術(shù)發(fā)展越來(lái)越快，各個(gè)廠家的競(jìng)爭(zhēng)也是越來(lái)越激烈，到底哪種技術(shù)性能更加的好，查詢時(shí)延更加的低，這個(gè)還是要從業(yè)務(wù)使用場(chǎng)景上來(lái)針對(duì)性分析選擇。
任何一種技術(shù)，都有其適合的場(chǎng)景，然后結(jié)合技術(shù)上分析，如何減少掃描的數(shù)據(jù)量，是提升查詢性能的關(guān)鍵。