Spark 性能相關(guān)參數(shù)配置詳解－任務(wù)調(diào)度篇

隨著Spark的逐步成熟完善, 愈來(lái)愈多的可配置參數(shù)被添加到Spark中來(lái), 本文試圖通過(guò)論述這其中部份參數(shù)的工作原理和配置思路, 和大家1起探討1下如何根據(jù)實(shí)際場(chǎng)合對(duì)Spark進(jìn)行配置優(yōu)化。

由于篇幅較長(zhǎng)，所以在這里分篇組織，如果要看最新完全的網(wǎng)頁(yè)版內(nèi)容，可以戳這里：http://spark-config.readthedocs.org/，主要是便于更新內(nèi)容

schedule調(diào)度相干

調(diào)度相干的參數(shù)設(shè)置，大多數(shù)內(nèi)容都很直白，其實(shí)不必過(guò)量的額外解釋，不過(guò)基于這些參數(shù)的經(jīng)常使用性（大概會(huì)是你針對(duì)自己的集群第1步就會(huì)配置的參數(shù)），這里多少就其內(nèi)部機(jī)制做1些解釋。

spark.cores.max

1個(gè)集群最重要的參數(shù)之1，固然就是CPU計(jì)算資源的數(shù)量。spark.cores.max 這個(gè)參數(shù)決定了在Standalone和Mesos模式下，1個(gè)Spark利用程序所能申請(qǐng)的CPU Core的數(shù)量。如果你沒(méi)有并發(fā)跑多個(gè)Spark利用程序的需求，那末可以不需要設(shè)置這個(gè)參數(shù)，默許會(huì)使用spark.deploy.defaultCores的值（而spark.deploy.defaultCores的值默許為Int.Max，也就是不限制的意思）從而利用程序可使用所有當(dāng)前可以取得的CPU資源。

針對(duì)這個(gè)參數(shù)需要注意的是，這個(gè)參數(shù)對(duì)Yarn模式不起作用，YARN模式下，資源由Yarn統(tǒng)1調(diào)度管理，1個(gè)利用啟動(dòng)時(shí)所申請(qǐng)的CPU資源的數(shù)量由另外兩個(gè)直接配置Executor的數(shù)量和每一個(gè)Executor中core數(shù)量的參數(shù)決定。（歷史緣由造成，不同運(yùn)行模式下的1些啟動(dòng)參數(shù)個(gè)人認(rèn)為還有待進(jìn)1步整合）

另外，在Standalone模式等后臺(tái)分配CPU資源時(shí)，目前的實(shí)現(xiàn)中，在spark.cores.max允許的范圍內(nèi)，基本上是優(yōu)先從每一個(gè)Worker中申請(qǐng)所能得到的最大數(shù)量的CPU core給每一個(gè)Executor，因此如果人工限制了所申請(qǐng)的Max Core的數(shù)量小于Standalone和Mesos模式所管理的CPU數(shù)量，可能產(chǎn)生利用只運(yùn)行在集群中部份節(jié)點(diǎn)上的情況（由于部份節(jié)點(diǎn)所能提供的最大CPU資源數(shù)量已滿足利用的要求），而不是平均散布在集群中。通常這不會(huì)是太大的問(wèn)題，但是如果觸及數(shù)據(jù)本地性的場(chǎng)合，有可能就會(huì)帶來(lái)1定的必須進(jìn)行遠(yuǎn)程數(shù)據(jù)讀取的情況產(chǎn)生。理論上，這個(gè)問(wèn)題可以通過(guò)兩種途徑解決：1是Standalone和Mesos的資源管理模塊自動(dòng)根據(jù)節(jié)點(diǎn)資源情況，均勻分配和啟動(dòng)Executor，2是和Yarn模式1樣，允許用戶指定和限制每一個(gè)Executor的Core的數(shù)量。 社區(qū)中有1個(gè)PR試圖走第2種途徑來(lái)解決類似的問(wèn)題，不過(guò)截至我寫下這篇文檔為止（2014.8），還沒(méi)有被Merge。

spark.task.cpus

這個(gè)參數(shù)在字面上的意思就是分配給每一個(gè)任務(wù)的CPU的數(shù)量，默許為1。實(shí)際上，這個(gè)參數(shù)其實(shí)不能真的控制每一個(gè)任務(wù)實(shí)際運(yùn)行時(shí)所使用的CPU的數(shù)量，比如你可以通過(guò)在任務(wù)內(nèi)部創(chuàng)建額外的工作線程來(lái)使用更多的CPU（最少目前為止，將來(lái)任務(wù)的履行環(huán)境是不是能通過(guò)LXC等技術(shù)來(lái)控制還不好說(shuō)）。它所發(fā)揮的作用，只是在作業(yè)調(diào)度時(shí)，每分配出1個(gè)任務(wù)時(shí)，對(duì)已使用的CPU資源進(jìn)行計(jì)數(shù)。也就是說(shuō)只是理論上用來(lái)統(tǒng)計(jì)資源的使用情況，便于安排調(diào)度。因此，如果你期望通過(guò)修改這個(gè)參數(shù)來(lái)加快任務(wù)的運(yùn)行，那還是趕快換個(gè)思路吧。這個(gè)參數(shù)的意義，個(gè)人覺(jué)得還是在你真的在任務(wù)內(nèi)部自己通過(guò)任何手段，占用了更多的CPU資源時(shí)，讓調(diào)度行動(dòng)更加準(zhǔn)確的1個(gè)輔助手段。

spark.scheduler.mode

這個(gè)參數(shù)決定了單個(gè)Spark利用內(nèi)部調(diào)度的時(shí)候使用FIFO模式還是Fair模式。是的，你沒(méi)有看錯(cuò)，這個(gè)參數(shù)只管理1個(gè)Spark利用內(nèi)部的多個(gè)沒(méi)有依賴關(guān)系的Job作業(yè)的調(diào)度策略。

如果你需要的是多個(gè)Spark利用之間的調(diào)度策略，那末在Standalone模式下，這取決于每一個(gè)利用所申請(qǐng)和取得的CPU資源的數(shù)量（暫時(shí)沒(méi)有取得資源的利用就Pending在那里了），基本上就是FIFO情勢(shì)的，誰(shuí)先申請(qǐng)和取得資源，誰(shuí)就占用資源直到完成。而在Yarn模式下，則多個(gè)Spark利用間的調(diào)度策略由Yarn自己的策略配置文件所決定。

那末這個(gè)內(nèi)部的調(diào)度邏輯有甚么用呢？如果你的Spark利用是通過(guò)服務(wù)的情勢(shì)，為多個(gè)用戶提交作業(yè)的話，那末可以通過(guò)配置Fair模式相干參數(shù)來(lái)調(diào)劑不同用戶作業(yè)的調(diào)度和資源分配優(yōu)先級(jí)。

spark.locality.wait

spark.locality.wait和spark.locality.wait.process，spark.locality.wait.node, spark.locality.wait.rack這幾個(gè)參數(shù)影響了任務(wù)分配時(shí)的本地性策略的相干細(xì)節(jié)。

Spark中任務(wù)的處理需要斟酌所觸及的數(shù)據(jù)的本地性的場(chǎng)合，基本就兩種，1是數(shù)據(jù)的來(lái)源是HadoopRDD; 2是RDD的數(shù)據(jù)來(lái)源來(lái)自于RDD Cache（即由CacheManager從BlockManager中讀取，或Streaming數(shù)據(jù)源RDD）。其它情況下，如果不觸及shuffle操作的RDD，不構(gòu)成劃分Stage和Task的基準(zhǔn)，不存在判斷Locality本地性的問(wèn)題，而如果是ShuffleRDD，其本地性始終為No Prefer，因此其實(shí)也無(wú)所謂Locality。

在理想的情況下，任務(wù)固然是分配在可以從本地讀取數(shù)據(jù)的節(jié)點(diǎn)上時(shí)（同1個(gè)JVM內(nèi)部或同1臺(tái)物理機(jī)器內(nèi)部）的運(yùn)行時(shí)性能最好。但是每一個(gè)任務(wù)的履行速度沒(méi)法準(zhǔn)確估計(jì)，所以很難在事前取得全局最優(yōu)的履行策略，當(dāng)Spark利用得到1個(gè)計(jì)算資源的時(shí)候，如果沒(méi)有可以滿足最好本地性需求的任務(wù)可以運(yùn)行時(shí)，是退而求其次，運(yùn)行1個(gè)本地性條件稍差1點(diǎn)的任務(wù)呢，還是繼續(xù)等待下1個(gè)可用的計(jì)算資源已期望它能更好的匹配任務(wù)的本地性呢？

這幾個(gè)參數(shù)1起決定了Spark任務(wù)調(diào)度在得到分配任務(wù)時(shí)，選擇暫時(shí)不分配任務(wù)，而是等待取得滿足進(jìn)程內(nèi)部/節(jié)點(diǎn)內(nèi)部/機(jī)架內(nèi)部這樣的不同層次的本地性資源的最長(zhǎng)等待時(shí)間。默許都是3000毫秒。

基本上，如果你的任務(wù)數(shù)量較大和單個(gè)任務(wù)運(yùn)行時(shí)間比較長(zhǎng)的情況下，單個(gè)任務(wù)是不是在數(shù)據(jù)本地運(yùn)行，代價(jià)區(qū)分可能比較顯著，如果數(shù)據(jù)本地性不理想，那末調(diào)大這些參數(shù)對(duì)性能優(yōu)化可能會(huì)有1定的好處。反之如果等待的代價(jià)超過(guò)帶來(lái)的收益，那就不要斟酌了。

特別值得注意的是：在處理利用剛啟動(dòng)后提交的第1批任務(wù)時(shí)，由于當(dāng)作業(yè)調(diào)度模塊開(kāi)始工作時(shí)，處理任務(wù)的Executors可能還沒(méi)有完全注冊(cè)終了，因此1部份的任務(wù)會(huì)被放置到No Prefer的隊(duì)列中，這部份任務(wù)的優(yōu)先級(jí)僅次于數(shù)據(jù)本地性滿足Process級(jí)別的任務(wù)，從而被優(yōu)先分配到非本地節(jié)點(diǎn)履行，如果的確沒(méi)有Executors在對(duì)應(yīng)的節(jié)點(diǎn)上運(yùn)行，或的確是No Prefer的任務(wù)（如shuffleRDD），這樣做確切是比較優(yōu)化的選擇，但是這里的實(shí)際情況只是這部份Executors還沒(méi)來(lái)得及注冊(cè)上而已。這類情況下，即便加大本節(jié)中這幾個(gè)參數(shù)的數(shù)值也沒(méi)有幫助。針對(duì)這個(gè)情況，有1些已完成的和正在進(jìn)行中的PR通過(guò)例如動(dòng)態(tài)調(diào)劑No Prefer隊(duì)列，監(jiān)控節(jié)點(diǎn)注冊(cè)比例等等方式試圖來(lái)給出更加智能的解決方案。不過(guò)，你也能夠根據(jù)本身集群的啟動(dòng)情況，通過(guò)在創(chuàng)建SparkContext以后，主動(dòng)Sleep幾秒的方式來(lái)簡(jiǎn)單的解決這個(gè)問(wèn)題。

spark.speculation

spark.speculation和spark.speculation.interval,spark.speculation.quantile, spark.speculation.multiplier等參數(shù)調(diào)劑Speculation行動(dòng)的具體細(xì)節(jié)，Speculation是在任務(wù)調(diào)度的時(shí)候，如果沒(méi)有合適當(dāng)前本地性要求的任務(wù)可供運(yùn)行，將跑得慢的任務(wù)在空閑計(jì)算資源上再度調(diào)度的行動(dòng)，這些參數(shù)調(diào)劑這些行動(dòng)的頻率和判斷指標(biāo)，默許是不使用Speculation的。

通常來(lái)講很難正確的判斷是不是需要Speculation，能真正發(fā)揮Speculation用途的場(chǎng)合，常常是某些節(jié)點(diǎn)由于運(yùn)行環(huán)境緣由，比如CPU資源由于某種緣由被占用，磁盤破壞致使IO緩慢造成任務(wù)履行速度異常的情況，固然條件是你的分區(qū)任務(wù)不存在僅能被履行1次，或不能同時(shí)履行多個(gè)拷貝等情況。Speculation任務(wù)參照的指標(biāo)通常是其它任務(wù)的履行時(shí)間，而實(shí)際的任務(wù)可能由于分區(qū)數(shù)據(jù)尺寸不均勻，本來(lái)就會(huì)有時(shí)間差異，加上1定的調(diào)度和IO的隨機(jī)性，所以如果1致性指標(biāo)定得過(guò)嚴(yán)，Speculation可能其實(shí)不能真的發(fā)現(xiàn)問(wèn)題，反而增加了沒(méi)必要要的任務(wù)開(kāi)消，定得過(guò)寬，大概又基本相當(dāng)于沒(méi)用。

個(gè)人覺(jué)得，如果你的集群范圍比較大，運(yùn)行環(huán)境復(fù)雜，的確可能常常產(chǎn)生履行異常，加上數(shù)據(jù)分區(qū)尺寸差異不大，為了程序運(yùn)行時(shí)間的穩(wěn)定性，那末可以斟酌仔細(xì)調(diào)劑這些參數(shù)。否則還是斟酌如何排除造成任務(wù)履行速度異常的因數(shù)比較靠鋪1些。

固然，我沒(méi)有實(shí)際在很大范圍的集群上運(yùn)行過(guò)Spark，所以如果看法有些偏頗，還請(qǐng)有實(shí)際經(jīng)驗(yàn)的XD指正。

生活不易，碼農(nóng)辛苦
如果您覺(jué)得本網(wǎng)站對(duì)您的學(xué)習(xí)有所幫助,可以手機(jī)掃描二維碼進(jìn)行捐贈(zèng)