//
SQL on Hadoop技術分析（一） - 大數(shù)據(jù)和云計算技術 （歡迎關注同名微信公眾號） - ITeye技術網(wǎng)站
http://jiezhu2007.iteye.com/blog/2314063
自打Hive出現(xiàn)之后，SQL onHadoop相關系統(tǒng)已經(jīng)百花齊放似嗤，速度越來越快，功能也越來越齊全。目前比較主流的有Impala怒坯，Spark SQL凉袱，HAWQ工三，Tez架谎，Drill，Presto，Tajo等君纫。下面從技術層面梳理下一個技術統(tǒng)一的視角驯遇，來為后續(xù)在技術方案上選擇做參考。
在SQL on Hadoop系統(tǒng)中蓄髓，有兩種主流的架構妹懒，一種是基于某個運行時框架來構建查詢引擎，典型的案例就是Hive双吆，另一種是仿照MPP數(shù)據(jù)庫架構眨唬，典型的如Impala，HAWQ好乐。前者現(xiàn)有運行時框架蔚万，然后套上SQL層昵慌，后者則是一個一體化的查詢引擎斋攀，有時我們能聽到一種聲音淳蔼，說后者的架構優(yōu)于前者，至少在性能上存皂。那么是否果真如此旦袋？
從任務的運行角度來看娩怎，MPP類引擎的執(zhí)行方式其實跟DAG模型是類似的，主要的特點如下：
· DAG v.s. MR：最主要的優(yōu)勢柬讨，中間結果不寫磁盤（除非內存不夠）踩官。
· 流水線計算：上游stage一出結果馬上推送或者拉到下一個stage處理，比如多表join時前兩個表有結果直接給第三個表辩越，不像MR要等兩個表完全join完再給第三個表join黔攒。
· 高效的IO：本地查詢沒有多余的消耗，充分利用磁盤赏胚。
· 線程級別的并發(fā)：相比之下MR每個task要啟動JVM栅哀，本身就有很大延遲留拾，占用資源也多。
背景
Hadoop的誕生是劃時代的數(shù)據(jù)變革咳蔚，但關系型數(shù)據(jù)庫時代的存留也為Hadoop真正占領數(shù)據(jù)庫領域埋下了許多的障礙谈火。對SQL（尤其是PL/SQL）的支持一直是Hadoop大數(shù)據(jù)平臺在替代舊數(shù)據(jù)時代亟待解決的問題。Hadoop對SQL數(shù)據(jù)庫的支持度一直是企業(yè)用戶最關心的訴求點之一温技，也是他們選擇的Hadoop平臺的重要標準舵鳞。
自打Hive出現(xiàn)之后抛虏，SQL onHadoop相關系統(tǒng)已經(jīng)百花齊放嘉蕾，速度越來越快，功能也越來越齊全以清。目前比較主流的有Impala掷倔，Spark SQL勒葱，HAWQ，Tez凯旋，Drill至非，Presto荒椭，Tajo等。下面從技術層面梳理下一個技術統(tǒng)一的視角隔缀，來為后續(xù)在技術方案上選擇做參考。
系統(tǒng)架構：Runtime Framework vs MPP
在SQL on Hadoop系統(tǒng)中丢习，有兩種主流的架構，一種是基于某個運行時框架來構建查詢引擎见擦，典型的案例就是Hive鲤屡，另一種是仿照MPP數(shù)據(jù)庫架構酒来，典型的如Impala，HAWQ翘鸭。前者現(xiàn)有運行時框架矮固，然后套上SQL層档址，后者則是一個一體化的查詢引擎，有時我們能聽到一種聲音尼摹，說后者的架構優(yōu)于前者蠢涝，至少在性能上徘铝。那么是否果真如此惕它？
一般來說淹魄，對于SQL on Hadoop系統(tǒng)很重要的一個評價指標就是:快，低時延缤沦。在Hive逐漸普及后疚俱，就逐漸有了所謂交互式的查詢需求，因為無論是BI系統(tǒng)梁钾，還是Ad-hoc逊抡，都不能按照離線的方式來處理拇勃。很多廠商都試圖去解決這個問題方咆，于是就有了Impala瓣赂，HAWQ等，同時經(jīng)過不斷的發(fā)展妓肢，Hive也能跑在DAG框架上了，不僅有Tez放钦，還有Spark恭金。從任務的運行角度來看，MPP類引擎的執(zhí)行方式其實跟DAG模型是類似的耿焊，主要的特點如下：
· DAG v.s. MR：最主要的優(yōu)勢罗侯，中間結果不寫磁盤（除非內存不夠）。
· 流水線計算：上游stage一出結果馬上推送或者拉到下一個stage處理讲弄，比如多表join時前兩個表有結果直接給第三個表避除，不像MR要等兩個表完全join完再給第三個表join。
· 高效的IO：本地查詢沒有多余的消耗群井，充分利用磁盤蝌借。
· 線程級別的并發(fā)：相比之下MR每個task要啟動JVM菩佑，本身就有很大延遲酬荞，占用資源也多混巧。
當然MPP模式也有其劣勢咧党，一個是擴展性不是很高，這在關系數(shù)據(jù)庫時代就已經(jīng)有過結論蛙埂；另一個是容錯性差绣的，對于Impala來說一旦運行過程中出點問題屡江，整個查詢就掛了盼理。
存儲格式
主流的存儲格式有，ORC臊诊，Parquet，最近華為大數(shù)據(jù)團隊研發(fā)的CarbonData數(shù)據(jù)格式玷或，從原型測試數(shù)據(jù)偏友，CarbonData性能上比Parquet要快氛濒，這主要得益于在構建Carbon數(shù)據(jù)格式中，創(chuàng)建了很多的索引骗奖，從整個查詢掃描過程中米愿，利用索引快速過濾掉數(shù)據(jù)育苟，減少掃描的數(shù)據(jù)量违柏，類似這樣的系統(tǒng)禽篱，有騰訊的Hermes等躺率。另外Impala使用的Parquet格式存儲，現(xiàn)在又有了一種新的解決方案后添，kudu+Impala的方案馅精，Cloudera宣稱查詢分析非沉蛩唬快，并且能支持數(shù)據(jù)的更新等操作梧税。
資源控制
在SQL on Hadoop方案中沦疾，另外一個客戶關注的方面是資源控制，在Hadoop體系中第队，與Yarn的集成哮塞。比如目前的Impala版本就不支持通過Yarn來管理分布使用資源，不過從Impala的版本路標中凳谦，與Yarn的數(shù)據(jù)集成已經(jīng)是Impala的一個重要的目標。目前能與Yarn集成的有Spark SQL，HAWQ等.
總結
SQL on Hadoop的技術發(fā)展越來越快褪贵，各個廠家的競爭也是越來越激烈跟压，到底哪種技術性能更加的好喷好，查詢時延更加的低荡短，這個還是要從業(yè)務使用場景上來針對性分析選擇。
任何一種技術颂碘，都有其適合的場景靠抑，然后結合技術上分析戚宦，如何減少掃描的數(shù)據(jù)量艳汽，是提升查詢性能的關鍵。
