這篇文章主要介紹了Hive on Spark如何調(diào)優(yōu)，具有一定借鑒價(jià)值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。
目前創(chuàng)新互聯(lián)已為近千家的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)站空間、成都網(wǎng)站托管、企業(yè)網(wǎng)站設(shè)計(jì)、宣漢網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長(zhǎng)，共同發(fā)展。
之前在Hive on Spark跑TPCx-BB測(cè)試時(shí)，100g的數(shù)據(jù)量要跑十幾個(gè)小時(shí)，一看CPU和內(nèi)存的監(jiān)控，發(fā)現(xiàn) POWER_TEST階段（依次執(zhí)行30個(gè)查詢）CPU只用了百分之十幾，也就是沒有把整個(gè)集群的性能利用起來(lái)，導(dǎo)致跑得很慢。因此，如何調(diào)整參數(shù)，使整個(gè)集群發(fā)揮最大性能顯得尤為重要。
詳細(xì)原理見上圖。我們使用spark-submit提交一個(gè)Spark作業(yè)之后，這個(gè)作業(yè)就會(huì)啟動(dòng)一個(gè)對(duì)應(yīng)的Driver進(jìn)程。根據(jù)你使用的部署模式（deploy-mode）不同，Driver進(jìn)程可能在本地啟動(dòng)，也可能在集群中某個(gè)工作節(jié)點(diǎn)上啟動(dòng)。Driver進(jìn)程本身會(huì)根據(jù)我們?cè)O(shè)置的參數(shù)，占有一定數(shù)量的內(nèi)存和CPU core。而Driver進(jìn)程要做的第一件事情，就是向集群管理器（可以是Spark Standalone集群，也可以是其他的資源管理集群，美團(tuán)?大眾點(diǎn)評(píng)使用的是YARN作為資源管理集群）申請(qǐng)運(yùn)行Spark作業(yè)需要使用的資源，這里的資源指的就是Executor進(jìn)程。YARN集群管理器會(huì)根據(jù)我們?yōu)镾park作業(yè)設(shè)置的資源參數(shù)，在各個(gè)工作節(jié)點(diǎn)上，啟動(dòng)一定數(shù)量的Executor進(jìn)程，每個(gè)Executor進(jìn)程都占有一定數(shù)量的內(nèi)存和CPU core。
Spark是根據(jù)shuffle類算子來(lái)進(jìn)行stage的劃分。如果我們的代碼中執(zhí)行了某個(gè)shuffle類算子（比如reduceByKey、join等），那么就會(huì)在該算子處，劃分出一個(gè)stage界限來(lái)?？梢源笾吕斫鉃椋瑂huffle算子執(zhí)行之前的代碼會(huì)被劃分為一個(gè)stage，shuffle算子執(zhí)行以及之后的代碼會(huì)被劃分為下一個(gè)stage。因此一個(gè)stage剛開始執(zhí)行的時(shí)候，它的每個(gè)task可能都會(huì)從上一個(gè)stage的task所在的節(jié)點(diǎn)，去通過網(wǎng)絡(luò)傳輸拉取需要自己處理的所有key，然后對(duì)拉取到的所有相同的key使用我們自己編寫的算子函數(shù)執(zhí)行聚合操作（比如reduceByKey()算子接收的函數(shù)）。這個(gè)過程就是shuffle。
task的執(zhí)行速度是跟每個(gè)Executor進(jìn)程的CPU core數(shù)量有直接關(guān)系的。一個(gè)CPU core同一時(shí)間只能執(zhí)行一個(gè)線程。而每個(gè)Executor進(jìn)程上分配到的多個(gè)task，都是以每個(gè)task一條線程的方式，多線程并發(fā)運(yùn)行的。如果CPU core數(shù)量比較充足，而且分配到的task數(shù)量比較合理，那么通常來(lái)說(shuō)，可以比較快速和高效地執(zhí)行完這些task線程。
以上就是Spark作業(yè)的基本運(yùn)行原理的說(shuō)明，大家可以結(jié)合上圖來(lái)理解。理解作業(yè)基本原理，是我們進(jìn)行資源參數(shù)調(diào)優(yōu)的基本前提。
了解完了Spark作業(yè)運(yùn)行的基本原理之后，對(duì)資源相關(guān)的參數(shù)就容易理解了。所謂的Spark資源參數(shù)調(diào)優(yōu)，其實(shí)主要就是對(duì)Spark運(yùn)行過程中各個(gè)使用資源的地方，通過調(diào)節(jié)各種參數(shù)，來(lái)優(yōu)化資源使用的效率，從而提升Spark作業(yè)的執(zhí)行性能。以下參數(shù)就是Spark中主要的資源參數(shù)，每個(gè)參數(shù)都對(duì)應(yīng)著作業(yè)運(yùn)行原理中的某個(gè)部分。
num-executors/spark.executor.instances
參數(shù)說(shuō)明：該參數(shù)用于設(shè)置Spark作業(yè)總共要用多少個(gè)Executor進(jìn)程來(lái)執(zhí)行。Driver在向YARN集群管理器申請(qǐng)資源時(shí)，YARN集群管理器會(huì)盡可能按照你的設(shè)置來(lái)在集群的各個(gè)工作節(jié)點(diǎn)上，啟動(dòng)相應(yīng)數(shù)量的Executor進(jìn)程。這個(gè)參數(shù)非常之重要，如果不設(shè)置的話，默認(rèn)只會(huì)給你啟動(dòng)少量的Executor進(jìn)程，此時(shí)你的Spark作業(yè)的運(yùn)行速度是非常慢的。
參數(shù)調(diào)優(yōu)建議：每個(gè)Spark作業(yè)的運(yùn)行一般設(shè)置50~100個(gè)左右的Executor進(jìn)程比較合適，設(shè)置太少或太多的Executor進(jìn)程都不好。設(shè)置的太少，無(wú)法充分利用集群資源；設(shè)置的太多的話，大部分隊(duì)列可能無(wú)法給予充分的資源。
executor-memory/spark.executor.memory
參數(shù)說(shuō)明：該參數(shù)用于設(shè)置每個(gè)Executor進(jìn)程的內(nèi)存。Executor內(nèi)存的大小，很多時(shí)候直接決定了Spark作業(yè)的性能，而且跟常見的JVM OOM異常，也有直接的關(guān)聯(lián)。
參數(shù)調(diào)優(yōu)建議：每個(gè)Executor進(jìn)程的內(nèi)存設(shè)置4G8G較為合適。但是這只是一個(gè)參考值，具體的設(shè)置還是得根據(jù)不同部門的資源隊(duì)列來(lái)定。可以看看自己團(tuán)隊(duì)的資源隊(duì)列的最大內(nèi)存限制是多少，num-executors乘以executor-memory，是不能超過隊(duì)列的最大內(nèi)存量的。此外，如果你是跟團(tuán)隊(duì)里其他人共享這個(gè)資源隊(duì)列，那么申請(qǐng)的內(nèi)存量最好不要超過資源隊(duì)列最大總內(nèi)存的1/31/2，避免你自己的Spark作業(yè)占用了隊(duì)列所有的資源，導(dǎo)致別的同學(xué)的作業(yè)無(wú)法運(yùn)行。
executor-cores/spark.executor.cores
參數(shù)說(shuō)明：該參數(shù)用于設(shè)置每個(gè)Executor進(jìn)程的CPU core數(shù)量。這個(gè)參數(shù)決定了每個(gè)Executor進(jìn)程并行執(zhí)行task線程的能力。因?yàn)槊總€(gè)CPU core同一時(shí)間只能執(zhí)行一個(gè)task線程，因此每個(gè)Executor進(jìn)程的CPU core數(shù)量越多，越能夠快速地執(zhí)行完分配給自己的所有task線程。
參數(shù)調(diào)優(yōu)建議：Executor的CPU core數(shù)量設(shè)置為2~4個(gè)較為合適。同樣得根據(jù)不同部門的資源隊(duì)列來(lái)定，可以看看自己的資源隊(duì)列的最大CPU core限制是多少，再依據(jù)設(shè)置的Executor數(shù)量，來(lái)決定每個(gè)Executor進(jìn)程可以分配到幾個(gè)CPU core。同樣建議，如果是跟他人共享這個(gè)隊(duì)列，那么num-executors * executor-cores不要超過隊(duì)列總CPU core的1/3~1/2左右比較合適，也是避免影響其他同學(xué)的作業(yè)運(yùn)行。
driver-memory
參數(shù)說(shuō)明：該參數(shù)用于設(shè)置Driver進(jìn)程的內(nèi)存。
參數(shù)調(diào)優(yōu)建議：Driver的內(nèi)存通常來(lái)說(shuō)不設(shè)置，或者設(shè)置1G左右應(yīng)該就夠了。唯一需要注意的一點(diǎn)是，如果需要使用collect算子將RDD的數(shù)據(jù)全部拉取到Driver上進(jìn)行處理，那么必須確保Driver的內(nèi)存足夠大，否則會(huì)出現(xiàn)OOM內(nèi)存溢出的問題。
spark.default.parallelism
參數(shù)說(shuō)明：該參數(shù)用于設(shè)置每個(gè)stage的默認(rèn)task數(shù)量。這個(gè)參數(shù)極為重要，如果不設(shè)置可能會(huì)直接影響你的Spark作業(yè)性能。
參數(shù)調(diào)優(yōu)建議：Spark作業(yè)的默認(rèn)task數(shù)量為500~1000個(gè)較為合適。很多同學(xué)常犯的一個(gè)錯(cuò)誤就是不去設(shè)置這個(gè)參數(shù)，那么此時(shí)就會(huì)導(dǎo)致Spark自己根據(jù)底層HDFS的block數(shù)量來(lái)設(shè)置task的數(shù)量，默認(rèn)是一個(gè)HDFS block對(duì)應(yīng)一個(gè)task。通常來(lái)說(shuō)，Spark默認(rèn)設(shè)置的數(shù)量是偏少的（比如就幾十個(gè)task），如果task數(shù)量偏少的話，就會(huì)導(dǎo)致你前面設(shè)置好的Executor的參數(shù)都前功盡棄。試想一下，無(wú)論你的Executor進(jìn)程有多少個(gè)，內(nèi)存和CPU有多大，但是task只有1個(gè)或者10個(gè)，那么90%的Executor進(jìn)程可能根本就沒有task執(zhí)行，也就是白白浪費(fèi)了資源！因此Spark官網(wǎng)建議的設(shè)置原則是，設(shè)置該參數(shù)為num-executors * executor-cores的2~3倍較為合適，比如Executor的總CPU core數(shù)量為300個(gè)，那么設(shè)置1000個(gè)task是可以的，此時(shí)可以充分地利用Spark集群的資源。
spark.storage.memoryFraction
參數(shù)說(shuō)明：該參數(shù)用于設(shè)置RDD持久化數(shù)據(jù)在Executor內(nèi)存中能占的比例，默認(rèn)是0.6。也就是說(shuō)，默認(rèn)Executor 60%的內(nèi)存，可以用來(lái)保存持久化的RDD數(shù)據(jù)。根據(jù)你選擇的不同的持久化策略，如果內(nèi)存不夠時(shí)，可能數(shù)據(jù)就不會(huì)持久化，或者數(shù)據(jù)會(huì)寫入磁盤。
參數(shù)調(diào)優(yōu)建議：如果Spark作業(yè)中，有較多的RDD持久化操作，該參數(shù)的值可以適當(dāng)提高一些，保證持久化的數(shù)據(jù)能夠容納在內(nèi)存中。避免內(nèi)存不夠緩存所有的數(shù)據(jù)，導(dǎo)致數(shù)據(jù)只能寫入磁盤中，降低了性能。但是如果Spark作業(yè)中的shuffle類操作比較多，而持久化操作比較少，那么這個(gè)參數(shù)的值適當(dāng)降低一些比較合適。此外，如果發(fā)現(xiàn)作業(yè)由于頻繁的gc導(dǎo)致運(yùn)行緩慢（通過spark web ui可以觀察到作業(yè)的gc耗時(shí)），意味著task執(zhí)行用戶代碼的內(nèi)存不夠用，那么同樣建議調(diào)低這個(gè)參數(shù)的值。
spark.shuffle.memoryFraction
參數(shù)說(shuō)明：該參數(shù)用于設(shè)置shuffle過程中一個(gè)task拉取到上個(gè)stage的task的輸出后，進(jìn)行聚合操作時(shí)能夠使用的Executor內(nèi)存的比例，默認(rèn)是0.2。也就是說(shuō)，Executor默認(rèn)只有20%的內(nèi)存用來(lái)進(jìn)行該操作。shuffle操作在進(jìn)行聚合時(shí)，如果發(fā)現(xiàn)使用的內(nèi)存超出了這個(gè)20%的限制，那么多余的數(shù)據(jù)就會(huì)溢寫到磁盤文件中去，此時(shí)就會(huì)極大地降低性能。
參數(shù)調(diào)優(yōu)建議：如果Spark作業(yè)中的RDD持久化操作較少，shuffle操作較多時(shí)，建議降低持久化操作的內(nèi)存占比，提高shuffle操作的內(nèi)存占比比例，避免shuffle過程中數(shù)據(jù)過多時(shí)內(nèi)存不夠用，必須溢寫到磁盤上，降低了性能。此外，如果發(fā)現(xiàn)作業(yè)由于頻繁的gc導(dǎo)致運(yùn)行緩慢，意味著task執(zhí)行用戶代碼的內(nèi)存不夠用，那么同樣建議調(diào)低這個(gè)參數(shù)的值。
可以看出：
隨著每個(gè)executor占用的CPU core數(shù)增加，q04查詢的時(shí)間顯著下降，q03也下降，但幅度沒那么大。
本次調(diào)優(yōu)只設(shè)置了spark.executor.memory和spark.executor.cores兩個(gè)參數(shù)，沒有涉及到spark.executor.instances參數(shù)，而默認(rèn)的spark.executor.instances為2，也就是每個(gè)作業(yè)只用到2個(gè)executor，因此還沒將性能發(fā)揮到最佳。
接下來(lái)采用100g的數(shù)據(jù)量，并且增加spark.executor.instances參數(shù)的設(shè)置。
可以看出：
調(diào)優(yōu)前后查詢時(shí)間有了很大的飛躍；
增加spark.executor.instances設(shè)置項(xiàng)指定每個(gè)作業(yè)占用的executor個(gè)數(shù)后性能又有很大提升（通過監(jiān)控我們發(fā)現(xiàn)此時(shí)CPU利用率平均有好幾十，甚至可以高到百分之九十幾）；
至此，我們終于將整個(gè)集群性能充分發(fā)揮出來(lái)，達(dá)到目的。
最后一列配置項(xiàng)是根據(jù)美團(tuán)技術(shù)團(tuán)隊(duì)博客的建議設(shè)置的，可以看出性能相比我們之前自己的設(shè)置還是有一定提升的，至少該博客里建議的設(shè)置是比較通用的，因此之后我們都采取最后一列的設(shè)置來(lái)跑TPCx-BB測(cè)試。
最后來(lái)張大圖展示調(diào)優(yōu)前和調(diào)優(yōu)后跑100g數(shù)據(jù)的對(duì)比：
可以看出：
絕大多數(shù)查詢調(diào)優(yōu)前后查詢時(shí)間有了極大的飛躍；
但是像q01/q04/q14...這幾個(gè)查詢，可能因?yàn)椴樵兩婕暗降谋肀容^小，調(diào)優(yōu)前時(shí)間就很短，因此調(diào)優(yōu)后也看不出很多差別，如果想看到大的差別，可能需要提高數(shù)據(jù)量，比如1T，3T；
q10和q18調(diào)優(yōu)前后時(shí)間都較長(zhǎng)，而且調(diào)優(yōu)后性能沒有提升，需要再深入探索下是什么原因。
最后，用調(diào)優(yōu)后的集群，分別跑10g、30g、100g的數(shù)據(jù)，結(jié)果如下：
10g、30g、100g.jpg.png
可以看出：
隨著數(shù)據(jù)量增大，很多查詢時(shí)間并沒有明顯增加，可能是因?yàn)榧盒阅芴珡?qiáng)，而且數(shù)據(jù)量還不夠大，可以增大數(shù)據(jù)量繼續(xù)觀察
對(duì)于q10、q18和q30，隨著數(shù)據(jù)量增大，時(shí)間明顯增大，需再深入分析
感謝你能夠認(rèn)真閱讀完這篇文章，希望小編分享的“Hive on Spark如何調(diào)優(yōu)”這篇文章對(duì)大家有幫助，同時(shí)也希望大家多多支持創(chuàng)新互聯(lián)，關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，更多相關(guān)知識(shí)等著你來(lái)學(xué)習(xí)!
重慶分公司
重慶分公司
