資源描述：
《Spark入門實戰(zhàn)系列》由會員上傳分享，免費在線閱讀，更多相關(guān)內(nèi)容在教育資源-天天文庫。
1、Spark入門實戰(zhàn)系列--6.SparkSQL（上）--SparkSQL簡介【注】該系列文章以及使用到安裝包/測試數(shù)據(jù)可以在《傾情大奉送--Spark入門實戰(zhàn)系列》獲取1、SparkSQL的發(fā)展歷程1.1?HiveandSharkSparkSQL的前身是Shark，給熟悉RDBMS但又不理解MapReduce的技術(shù)人員提供快速上手的工具，Hive應(yīng)運而生，它是當(dāng)時唯一運行在Hadoop上的SQL-on-Hadoop工具。但是MapReduce計算過程中大量的中間磁盤落地過程消耗了大量的I/O，降低的運行效率，為了提高SQL-on-Hadoop的效率，大量的SQL-on-Had
2、oop工具開始產(chǎn)生，其中表現(xiàn)較為突出的是：l?MapR的Drilll?Cloudera的Impalal?Shark其中Shark是伯克利實驗室Spark生態(tài)環(huán)境的組件之一，它修改了下圖所示的右下角的內(nèi)存管理、物理計劃、執(zhí)行三個模塊，并使之能運行在Spark引擎上，從而使得SQL查詢的速度得到10-100倍的提升。1.2?Shark和SparkSQL?但是，隨著Spark的發(fā)展，對于野心勃勃的Spark團(tuán)隊來說，Shark對于Hive的太多依賴（如采用Hive的語法解析器、查詢優(yōu)化器等等），制約了Spark的OneStackRuleThemAll的既定方針，制約了Spark各個
3、組件的相互集成，所以提出了SparkSQL項目。SparkSQL拋棄原有Shark的代碼，汲取了Shark的一些優(yōu)點，如內(nèi)存列存儲（In-MemoryColumnarStorage）、Hive兼容性等，重新開發(fā)了SparkSQL代碼；由于擺脫了對Hive的依賴性，SparkSQL無論在數(shù)據(jù)兼容、性能優(yōu)化、組件擴(kuò)展方面都得到了極大的方便，真可謂“退一步，海闊天空”。l數(shù)據(jù)兼容方面??不但兼容Hive，還可以從RDD、parquet文件、JSON文件中獲取數(shù)據(jù)，未來版本甚至支持獲取RDBMS數(shù)據(jù)以及cassandra等NOSQL數(shù)據(jù)；l性能優(yōu)化方面??除了采取In-MemoryC
4、olumnarStorage、byte-codegeneration等優(yōu)化技術(shù)外、將會引進(jìn)CostModel對查詢進(jìn)行動態(tài)評估、獲取最佳物理計劃等等；l組件擴(kuò)展方面??無論是SQL的語法解析器、分析器還是優(yōu)化器都可以重新定義，進(jìn)行擴(kuò)展。2014年6月1日Shark項目和SparkSQL項目的主持人ReynoldXin宣布：停止對Shark的開發(fā)，團(tuán)隊將所有資源放SparkSQL項目上，至此，Shark的發(fā)展畫上了句話，但也因此發(fā)展出兩個直線：SparkSQL和HiveonSpark。其中SparkSQL作為Spark生態(tài)的一員繼續(xù)發(fā)展，而不再受限于Hive，只是兼容Hive；
5、而HiveonSpark是一個Hive的發(fā)展計劃，該計劃將Spark作為Hive的底層引擎之一，也就是說，Hive將不再受限于一個引擎，可以采用Map-Reduce、Tez、Spark等引擎。1.3?SparkSQL的性能Shark的出現(xiàn)，使得SQL-on-Hadoop的性能比Hive有了10-100倍的提高：那么，擺脫了Hive的限制，SparkSQL的性能又有怎么樣的表現(xiàn)呢？雖然沒有Shark相對于Hive那樣矚目地性能提升，但也表現(xiàn)得非常優(yōu)異：為什么SparkSQL的性能會得到怎么大的提升呢？主要SparkSQL在下面幾點做了優(yōu)化：A：內(nèi)存列存儲（In-MemoryCo
6、lumnarStorage）SparkSQL的表數(shù)據(jù)在內(nèi)存中存儲不是采用原生態(tài)的JVM對象存儲方式，而是采用內(nèi)存列存儲，如下圖所示。該存儲方式無論在空間占用量和讀取吞吐率上都占有很大優(yōu)勢。對于原生態(tài)的JVM對象存儲方式，每個對象通常要增加12-16字節(jié)的額外開銷，對于一個270MB的TPC-Hlineitemtable數(shù)據(jù)，使用這種方式讀入內(nèi)存，要使用970MB左右的內(nèi)存空間（通常是2～5倍于原生數(shù)據(jù)空間）；另外，使用這種方式，每個數(shù)據(jù)記錄產(chǎn)生一個JVM對象，如果是大小為200B的數(shù)據(jù)記錄，32G的堆棧將產(chǎn)生1.6億個對象，這么多的對象，對于GC來說，可能要消耗幾分鐘的時間來
7、處理（JVM的垃圾收集時間與堆棧中的對象數(shù)量呈線性相關(guān)）。顯然這種內(nèi)存存儲方式對于基于內(nèi)存計算的Spark來說，很昂貴也負(fù)擔(dān)不起。對于內(nèi)存列存儲來說，將所有原生數(shù)據(jù)類型的列采用原生數(shù)組來存儲，將Hive支持的復(fù)雜數(shù)據(jù)類型（如array、map等）先序化后并接成一個字節(jié)數(shù)組來存儲。這樣，每個列創(chuàng)建一個JVM對象，從而導(dǎo)致可以快速的GC和緊湊的數(shù)據(jù)存儲；額外的，還可以使用低廉CPU開銷的高效壓縮方法（如字典編碼、行長度編碼等壓縮方法）降低內(nèi)存開銷；更有趣的是，對于分析查詢中頻繁使用的聚合特定列，性能會得到很
