Spark Storage性能相關參數配置是怎樣的

本篇文章為大家展示了 Spark Storage性能相關參數配置是怎樣的，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

隨著Spark的逐漸成熟完善, 越來越多的可配置參數被添加到Spark中來, 小編試圖通過闡述這其中部分參數的工作原理和配置思路, 和大家一起探討一下如何根據實際場合對Spark進行配置優化。

Storage相關配置參數

spark.local.dir

這個看起來很簡單，就是Spark用于寫中間數據，如RDD Cache，Shuffle，Spill等數據的位置，那么有什么可以注意的呢。

首先，最基本的當然是我們可以配置多個路徑（用逗號分隔）到多個磁盤上增加整體IO帶寬，這個大家都知道。

其次，目前的實現中，Spark是通過對文件名采用hash算法分布到多個路徑下的目錄中去，如果你的存儲設備有快有慢，比如SSD+HDD混合使用，那么你可以通過在SSD上配置更多的目錄路徑來增大它被Spark使用的比例，從而更好地利用SSD的IO帶寬能力。當然這只是一種變通的方法，終極解決方案還是應該像目前HDFS的實現方向一樣，讓Spark能夠感知具體的存儲設備類型，針對性的使用。

需要注意的是，在Spark 1.0 以后，SPARK_LOCAL_DIRS(Standalone, Mesos) or LOCAL_DIRS (YARN)參數會覆蓋這個配置。比如Spark On YARN的時候，Spark Executor的本地路徑依賴于Yarn的配置，而不取決于這個參數。

spark.executor.memory

Executor 內存的大小，和性能本身當然并沒有直接的關系，但是幾乎所有運行時性能相關的內容都或多或少間接和內存大小相關。這個參數最終會被設置到Executor的JVM的heap尺寸上，對應的就是Xmx和Xms的值

理論上Executor 內存當然是多多益善，但是實際受機器配置，以及運行環境，資源共享，JVM GC效率等因素的影響，還是有可能需要為它設置一個合理的大小。 多大算合理，要看實際情況

Executor的內存基本上是Executor內部所有任務共享的，而每個Executor上可以支持的任務的數量取決于Executor所管理的CPU Core資源的多少，因此你需要了解每個任務的數據規模的大小，從而推算出每個Executor大致需要多少內存即可滿足基本的需求。

如何知道每個任務所需內存的大小呢，這個很難統一的衡量，因為除了數據集本身的開銷，還包括算法所需各種臨時內存空間的使用，而根據具體的代碼算法等不同，臨時內存空間的開銷也不同。但是數據集本身的大小，對最終所需內存的大小還是有一定的參考意義的。

通常來說每個分區的數據集在內存中的大小，可能是其在磁盤上源數據大小的若干倍（不考慮源數據壓縮，Java對象相對于原始裸數據也還要算上用于管理數據的數據結構的額外開銷），需要準確的知道大小的話，可以將RDD cache在內存中，從BlockManager的Log輸出可以看到每個Cache分區的大?。ㄆ鋵嵰彩枪浪愠鰜淼?，并不完全準確）

如： BlockManagerInfo: Added rdd_0_1 on disk on sr438:41134(size: 495.3 MB)

反過來說，如果你的Executor的數量和內存大小受機器物理配置影響相對固定，那么你就需要合理規劃每個分區任務的數據規模，例如采用更多的分區，用增加任務數量（進而需要更多的批次來運算所有的任務）的方式來減小每個任務所需處理的數據大小。

spark.storage.memoryFraction

如前面所說spark.executor.memory決定了每個Executor可用內存的大小，而spark.storage.memoryFraction則決定了在這部分內存中有多少可以用于Memory Store管理RDD Cache數據，剩下的內存用來保證任務運行時各種其它內存空間的需要。

spark.executor.memory默認值為0.6，官方文檔建議這個比值不要超過JVM Old Gen區域的比值。這也很容易理解，因為RDD Cache數據通常都是長期駐留內存的，理論上也就是說最終會被轉移到Old Gen區域（如果該RDD還沒有被刪除的話），如果這部分數據允許的尺寸太大，勢必把Old Gen區域占滿，造成頻繁的FULL GC。

如何調整這個比值，取決于你的應用對數據的使用模式和數據的規模，粗略的來說，如果頻繁發生Full GC，可以考慮降低這個比值，這樣RDD Cache可用的內存空間減少（剩下的部分Cache數據就需要通過Disk Store寫到磁盤上了），會帶來一定的性能損失，但是騰出更多的內存空間用于執行任務，減少Full GC發生的次數，反而可能改善程序運行的整體性能

spark.streaming.blockInterval

這個參數用來設置Spark Streaming里Stream Receiver生成Block的時間間隔，默認為200ms。具體的行為表現是具體的Receiver所接收的數據，每隔這里設定的時間間隔，就從Buffer中生成一個StreamBlock放進隊列，等待進一步被存儲到BlockManager中供后續計算過程使用。理論上來說，為了每個StreamingBatch 間隔里的數據是均勻的，這個時間間隔當然應該能被Batch的間隔時間長度所整除?？傮w來說，如果內存大小夠用，Streaming的數據來得及處理，這個blockInterval時間間隔的影響不大，當然，如果數據Cache Level是Memory+Ser，即做了序列化處理，那么BlockInterval的大小會影響序列化后數據塊的大小，對于Java 的GC的行為會有一些影響。

此外spark.streaming.blockQueueSize決定了在StreamBlock被存儲到BlockMananger之前，隊列中最多可以容納多少個StreamBlock。默認為10，因為這個隊列Poll的時間間隔是100ms，所以如果CPU不是特別繁忙的話，基本上應該沒有問題。

上述內容就是 Spark Storage性能相關參數配置是怎樣的，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。