以前在Hive on Spark跑TPCx-BB測試時，100g的數據量要跑十幾個小時，一看CPU和內存的監控，發現 POWER_TEST階段（依次執行30個查詢）CPU只用了百分之十幾，也就是沒有把整個集羣的性能利用起來，致使跑得很慢。所以，如何調整參數，使整個集羣發揮最大性能顯得尤其重要。web
Spark做業運行原理
詳細原理見上圖。咱們使用spark-submit提交一個Spark做業以後，這個做業就會啓動一個對應的Driver進程。根據你使用的部署模式（deploy-mode）不一樣，Driver進程可能在本地啓動，也可能在集羣中某個工做節點上啓動。Driver進程自己會根據咱們設置的參數，佔有必定數量的內存和CPU core。而Driver進程要作的第一件事情，就是向集羣管理器（能夠是Spark Standalone集羣，也能夠是其餘的資源管理集羣，美團•大衆點評使用的是YARN做爲資源管理集羣）申請運行Spark做業須要使用的資源，這裏的資源指的就是Executor進程。YARN集羣管理器會根據咱們爲Spark做業設置的資源參數，在各個工做節點上，啓動必定數量的Executor進程，每一個Executor進程都佔有必定數量的內存和CPU core。
緩存
Spark是根據shuffle類算子來進行stage的劃分。若是咱們的代碼中執行了某個shuffle類算子（好比reduceByKey、join等），那麼就會在該算子處，劃分出一個stage界限來。能夠大體理解爲，shuffle算子執行以前的代碼會被劃分爲一個stage，shuffle算子執行以及以後的代碼會被劃分爲下一個stage。所以一個stage剛開始執行的時候，它的每一個task可能都會從上一個stage的task所在的節點，去經過網絡傳輸拉取須要本身處理的全部key，而後對拉取到的全部相同的key使用咱們本身編寫的算子函數執行聚合操做（好比reduceByKey()算子接收的函數）。這個過程就是shuffle。微信
task的執行速度是跟每一個Executor進程的CPU core數量有直接關係的。一個CPU core同一時間只能執行一個線程。而每一個Executor進程上分配到的多個task，都是以每一個task一條線程的方式，多線程併發運行的。若是CPU core數量比較充足，並且分配到的task數量比較合理，那麼一般來講，能夠比較快速和高效地執行完這些task線程。網絡
以上就是Spark做業的基本運行原理的說明，你們能夠結合上圖來理解。理解做業基本原理，是咱們進行資源參數調優的基本前提。多線程
瞭解完了Spark做業運行的基本原理以後，對資源相關的參數就容易理解了。所謂的Spark資源參數調優，其實主要就是對Spark運行過程當中各個使用資源的地方，經過調節各類參數，來優化資源使用的效率，從而提高Spark做業的執行性能。如下參數就是Spark中主要的資源參數，每一個參數都對應着做業運行原理中的某個部分。併發
num-executors/spark.executor.instancesapp
參數說明：該參數用於設置Spark做業總共要用多少個Executor進程來執行。Driver在向YARN集羣管理器申請資源時，YARN集羣管理器會盡量按照你的設置來在集羣的各個工做節點上，啓動相應數量的Executor進程。這個參數很是之重要，若是不設置的話，默認只會給你啓動少許的Executor進程，此時你的Spark做業的運行速度是很是慢的。函數
參數調優建議：每一個Spark做業的運行通常設置50~100個左右的Executor進程比較合適，設置太少或太多的Executor進程都很差。設置的太少，沒法充分利用集羣資源；設置的太多的話，大部分隊列可能沒法給予充分的資源。性能
executor-memory/spark.executor.memory測試
參數說明：該參數用於設置每一個Executor進程的內存。Executor內存的大小，不少時候直接決定了Spark做業的性能，並且跟常見的JVM OOM異常，也有直接的關聯。
參數調優建議：每一個Executor進程的內存設置4G8G較爲合適。可是這只是一個參考值，具體的設置仍是得根據不一樣部門的資源隊列來定。能夠看看本身團隊的資源隊列的最大內存限制是多少，num-executors乘以executor-memory，是不能超過隊列的最大內存量的。此外，若是你是跟團隊裏其餘人共享這個資源隊列，那麼申請的內存量最好不要超過資源隊列最大總內存的1/31/2，避免你本身的Spark做業佔用了隊列全部的資源，致使別的同窗的做業沒法運行。
executor-cores/spark.executor.cores
參數說明：該參數用於設置每一個Executor進程的CPU core數量。這個參數決定了每一個Executor進程並行執行task線程的能力。由於每一個CPU core同一時間只能執行一個task線程，所以每一個Executor進程的CPU core數量越多，越可以快速地執行完分配給本身的全部task線程。
參數調優建議：Executor的CPU core數量設置爲2~4個較爲合適。一樣得根據不一樣部門的資源隊列來定，能夠看看本身的資源隊列的最大CPU core限制是多少，再依據設置的Executor數量，來決定每一個Executor進程能夠分配到幾個CPU core。一樣建議，若是是跟他人共享這個隊列，那麼num-executors * executor-cores不要超過隊列總CPU core的1/3~1/2左右比較合適，也是避免影響其餘同窗的做業運行。
driver-memory
參數說明：該參數用於設置Driver進程的內存。
參數調優建議：Driver的內存一般來講不設置，或者設置1G左右應該就夠了。惟一須要注意的一點是，若是須要使用collect算子將RDD的數據所有拉取到Driver上進行處理，那麼必須確保Driver的內存足夠大，不然會出現OOM內存溢出的問題。
spark.default.parallelism
參數說明：該參數用於設置每一個stage的默認task數量。這個參數極爲重要，若是不設置可能會直接影響你的Spark做業性能。
參數調優建議：Spark做業的默認task數量爲500~1000個較爲合適。不少同窗常犯的一個錯誤就是不去設置這個參數，那麼此時就會致使Spark本身根據底層HDFS的block數量來設置task的數量，默認是一個HDFS block對應一個task。一般來講，Spark默認設置的數量是偏少的（好比就幾十個task），若是task數量偏少的話，就會致使你前面設置好的Executor的參數都前功盡棄。試想一下，不管你的Executor進程有多少個，內存和CPU有多大，可是task只有1個或者10個，那麼90%的Executor進程可能根本就沒有task執行，也就是白白浪費了資源！所以Spark官網建議的設置原則是，設置該參數爲num-executors * executor-cores的2~3倍較爲合適，好比Executor的總CPU core數量爲300個，那麼設置1000個task是能夠的，此時能夠充分地利用Spark集羣的資源。
spark.storage.memoryFraction
參數說明：該參數用於設置RDD持久化數據在Executor內存中能佔的比例，默認是0.6。也就是說，默認Executor 60%的內存，能夠用來保存持久化的RDD數據。根據你選擇的不一樣的持久化策略，若是內存不夠時，可能數據就不會持久化，或者數據會寫入磁盤。
參數調優建議：若是Spark做業中，有較多的RDD持久化操做，該參數的值能夠適當提升一些，保證持久化的數據可以容納在內存中。避免內存不夠緩存全部的數據，致使數據只能寫入磁盤中，下降了性能。可是若是Spark做業中的shuffle類操做比較多，而持久化操做比較少，那麼這個參數的值適當下降一些比較合適。此外，若是發現做業因爲頻繁的gc致使運行緩慢（經過spark web ui能夠觀察到做業的gc耗時），意味着task執行用戶代碼的內存不夠用，那麼一樣建議調低這個參數的值。
spark.shuffle.memoryFraction
參數說明：該參數用於設置shuffle過程當中一個task拉取到上個stage的task的輸出後，進行聚合操做時可以使用的Executor內存的比例，默認是0.2。也就是說，Executor默認只有20%的內存用來進行該操做。shuffle操做在進行聚合時，若是發現使用的內存超出了這個20%的限制，那麼多餘的數據就會溢寫到磁盤文件中去，此時就會極大地下降性能。
參數調優建議：若是Spark做業中的RDD持久化操做較少，shuffle操做較多時，建議下降持久化操做的內存佔比，提升shuffle操做的內存佔比比例，避免shuffle過程當中數據過多時內存不夠用，必須溢寫到磁盤上，下降了性能。此外，若是發現做業因爲頻繁的gc致使運行緩慢，意味着task執行用戶代碼的內存不夠用，那麼一樣建議調低這個參數的值。
調優過程
數據量：10g
能夠看出：
隨着每一個executor佔用的CPU core數增長，q04查詢的時間顯著降低，q03也降低，但幅度沒那麼大。
本次調優只設置了spark.executor.memory和spark.executor.cores兩個參數，沒有涉及到spark.executor.instances參數，而默認的spark.executor.instances爲2，也就是每一個做業只用到2個executor，所以還沒將性能發揮到最佳。
接下來採用100g的數據量，而且增長spark.executor.instances參數的設置。
數據量：100g
能夠看出：
調優先後查詢時間有了很大的飛躍；
增長
spark.executor.instances設置項指定每一個做業佔用的executor個數後性能又有很大提高（經過監控咱們發現此時CPU利用率平均有好幾十，甚至能夠高到百分之九十幾）；至此，咱們終於將整個集羣性能充分發揮出來，達到目的。
最後一列配置項是根據美團技術團隊博客的建議設置的，能夠看出性能相比咱們以前本身的設置仍是有必定提高的，至少該博客裏建議的設置是比較通用的，所以以後咱們都採起最後一列的設置來跑TPCx-BB測試。
最後來張大圖展現調優前和調優後跑100g數據的對比：
能夠看出：
絕大多數查詢調優先後查詢時間有了極大的飛躍；
可是像q01/q04/q14...這幾個查詢，可能由於查詢涉及到的表比較小，調優前時間就很短，所以調優後也看不出不少差異，若是想看到大的差異，可能須要提升數據量，好比1T，3T；
q10和q18調優先後時間都較長，並且調優後性能沒有提高，須要再深刻探索下是什麼緣由。
最後，用調優後的集羣，分別跑10g、30g、100g的數據，結果以下：
10g、30g、100g.jpg.png
能夠看出：
隨着數據量增大，不少查詢時間並無明顯增長，多是由於集羣性能太強，並且數據量還不夠大，能夠增大數據量繼續觀察
對於q十、q18和q30，隨着數據量增大，時間明顯增大，需再深刻分析
有收穫就點個「在看」吧 ▼
本文分享自微信公衆號 - 老懞大數據（simon_bigdata）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。