Spark---Shuffle調優之調節map端記憶體緩衝與reduce端記憶體佔比
1、map端記憶體緩衝,reduce端記憶體佔比概述
map端記憶體緩衝,reduce端記憶體佔比;很多資料、網上視訊,都會說,這兩個引數,是調節shuffle效能的不二選擇,很有效果的樣子,實際上,不是這樣的。
以實際的生產經驗來說,這兩個引數沒有那麼重要,往往來說,shuffle的效能不是因為這方面的原因導致的但是,有一點點效果的,broadcast,資料本地化等待時長;這兩個shuffle調優的小點,其實也是需要跟其他的大量的小點配合起來使用,一點一點的提升效能,最終很多個性能調優的小點的效果,彙集在一起之後,那麼就會有可以看見的還算不錯的效能調優的效果。
spark.shuffle.file.buffer,預設32k
spark.shuffle.memoryFraction,0.2
2.、原理圖及分析
預設情況下,shuffle的map task,輸出到磁碟檔案的時候,統一都會先寫入每個task自己關聯的一個記憶體緩衝區。
這個緩衝區大小,預設是32kb。
每一次,當記憶體緩衝區滿溢之後,才會進行spill操作,溢寫操作,溢寫到磁碟檔案中去。
reduce端task,在拉取到資料之後,會用hashmap的資料格式,來對各個key對應的values進行匯聚。
針對每個key對應的values,執行我們自定義的聚合函式的程式碼,比如_ + _(把所有values累加起來)
reduce task,在進行匯聚、聚合等操作的時候,實際上,使用的就是自己對應的executor的記憶體,executor(jvm程序,堆),預設executor記憶體中劃分給reduce task進行聚合的比例,是0.2。
問題來了,因為比例是0.2,所以,理論上,很有可能會出現,拉取過來的資料很多,那麼在記憶體中,放不下;這個時候,預設的行為,就是說,將在記憶體放不下的資料,都spill(溢寫)到磁碟檔案中去。
3、不調優會出現什麼問題
預設,map端記憶體緩衝是每個task,32kb。
預設,reduce端聚合記憶體比例,是0.2,也就是20%。
如果map端的task,處理的資料量比較大,但是呢,你的記憶體緩衝大小是固定的。可能會出現什麼樣的情況?
每個task就處理320kb,32kb,總共會向磁碟溢寫320 / 32 = 10次。
每個task處理32000kb,32kb,總共會向磁碟溢寫32000 / 32 = 1000次。
在map task處理的資料量比較大的情況下,而你的task的記憶體緩衝預設是比較小的,32kb。可能會造成多次的map端往磁碟檔案的spill溢寫操作,發生大量的磁碟IO,從而降低效能。
reduce端聚合記憶體,佔比。預設是0.2。如果資料量比較大,reduce task拉取過來的資料很多,那麼就會頻繁發生reduce端聚合記憶體不夠用,頻繁發生spill操作,溢寫到磁碟上去。而且最要命的是,磁碟上溢寫的資料量越大,後面在進行聚合操作的時候,很可能會多次讀取磁碟中的資料,進行聚合。
預設不調優,在資料量比較大的情況下,可能頻繁地發生reduce端的磁碟檔案的讀寫。
這兩個點之所以放在一起講,是因為他們倆是有關聯的。資料量變大,map端肯定會出點問題;reduce端肯定也會出點問題;出的問題是一樣的,都是磁碟IO頻繁,變多,影響效能。
4、調優
調優:
調節map task記憶體緩衝:spark.shuffle.file.buffer,預設32k(spark 1.3.x不是這個引數,後面還有一個字尾,kb;spark 1.5.x以後,變了,就是現在這個引數)
調節reduce端聚合記憶體佔比:spark.shuffle.memoryFraction,0.2
在實際生產環境中,我們在什麼時候來調節兩個引數?
看Spark UI,如果你的公司是決定採用standalone模式,那麼狠簡單,你的spark跑起來,會顯示一個Spark UI的地址,4040的埠,進去看,依次點選進去,可以看到,你的每個stage的詳情,有哪些executor,有哪些task,每個task的shuffle write和shuffle read的量,shuffle的磁碟和記憶體,讀寫的資料量;如果是用的yarn模式來提交,課程最前面,從yarn的介面進去,點選對應的application,進入Spark UI,檢視詳情。
如果發現shuffle 磁碟的write和read,很大。這個時候,就意味著最好調節一些shuffle的引數。進行調優。首先當然是考慮開啟map端輸出檔案合併機制。
調節上面說的那兩個引數。調節的時候的原則。spark.shuffle.file.buffer,每次擴大一倍,然後看看效果,64,128;spark.shuffle.memoryFraction,每次提高0.1,看看效果。
不能調節的太大,太大了以後過猶不及,因為記憶體資源是有限的,你這裡調節的太大了,其他環節的記憶體使用就會有問題了。
調節了以後,效果?map task記憶體緩衝變大了,減少spill到磁碟檔案的次數;reduce端聚合記憶體變大了,減少spill到磁碟的次數,而且減少了後面聚合讀取磁碟檔案的數量。
相關推薦
Spark---Shuffle調優之調節map端記憶體緩衝與reduce端記憶體佔比
1、map端記憶體緩衝,reduce端記憶體佔比概述 map端記憶體緩衝,reduce端記憶體佔比;很多資料、網上視訊,都會說,這兩個引數,是調節shuffle效能的不二選擇,很有效果的樣子,實際上,
Shuffle調優之合併map端輸出檔案(三)
什麼樣的情況下,會發生shuffle? 在spark中,觸發Action運算元就會發生shuffle,主要是以下幾個運算元:groupByKey、reduceByKey、countByKey、join等等。 什麼是shuffle? groupByKey,要把分佈
Spark效能調優之原理分析
spark效能調優之前先明白原理,具體如下: 使用spark-submit提交一個Spark作業之後,這個作業就會啟動一個對應的Driver程序。根據使用的部署模式(deploy-mode)不同,Driver程序可能在本地啟動,也可能在叢集中某個工作節點上啟動。Driver程序本身會根
spark.shuffle調優
1.1.1 spark.shuffle.managerSpark1.2.0官方支援兩種方式的Shuffle,即Hash Based Shuffle和Sort Based Shuffle。其中在Spark 1.0之前僅支援Hash Based Shuffle。Spark 1.1的時候引入了
Spark shuffle調優
ces 傳輸 shuff res spark性能 模式 shuffle過程 圖片 連接 Spark shuffle是什麽Shuffle在Spark中即是把父RDD中的KV對按照Key重新分區,從而得到一個新的RDD。也就是說原本同屬於父RDD同一個分區的數據需要進入到子RD
Spark效能調優之廣播變數
廣播變數概述及其優勢廣播變數(groadcast varible)為只讀變數,它有執行SparkContext的driver程式建立後傳送給參與計算的節點。對那些需要讓工作節點高效地訪問相同資料的應用場景,比如機器學習。我們可以在SparkContext上呼叫broadcas
spark JVM調優之原理概述以及降低cache操作的記憶體佔比
每一次放物件的時候,都是放入eden區域,和其中一個survivor區域;另外一個survivor區域是空閒的。 當eden區域和一個survivor區域放滿了以後(spark執行過程中,產生的物件實在太多了),就會觸發minor gc,小型垃圾回收。把不再使用的物件,從記憶體中清空,給後面新建立
spark效能調優之重構RDD架構,RDD持久化
當第一次對RDD2執行運算元,獲取RDD3的時候,就會從RDD1開始計算,就是讀取HDFS檔案,然後對RDD1執行運算元,獲取到RDD2,然後再計算,得到RDD3 預設情況下,多次對一個RDD執行運算元,去獲取不同的RDD;都會對這個RDD以及之前的父RDD,全部重新計算
Spark效能調優之廣播大變數
本篇blog講述在實際spark專案中可能需要注意的一個性能調優的一個點,就是broadcast大變數。 預設的在spark作業中,task執行的運算元中,使用了外部的變數,每個task都會獲取一份變數的副本,有什麼缺點呢?<br>map,本身是不小
Spark效能調優之——在實際專案中重構RDD架構以及RDD持久化
一、RDD架構重構與優化是什麼。 儘量去複用RDD,差不多的RDD,可以抽取為一個共同的RDD,供後面的RDD計算時,反覆使用。 二、怎麼做? 快取級別: case "NONE" => NONE case "DISK_ONL
Spark效能調優之道——解決Spark資料傾斜(Data Skew)的N種姿勢
為何要處理資料傾斜(Data Skew) 什麼是資料傾斜 對Spark/Hadoop這樣的大資料系統來講,資料量大並不可怕,可怕的是資料傾斜。 何謂資料傾斜?資料傾斜指的是,並行處理的資料集中,某一部分(如Spark或Kafka的一個Partition)的資料顯著多於其它
Spark 效能調優 Rdd 之 reduceByKey 本地聚合(也就是map端聚合運算元)
簡單程式碼 val lines = sc.textFile("hdfs://") val words = lines.flatMap(_.split(" ")) val pairs = words.map((_, 1)) val counts = pairs.reduceByKey(_
spark效能調優(三)shuffle的map端記憶體緩衝reduce端記憶體佔比
效能優化 shuffle spark.shuffle.file.buffer,預設32k spark.shuffle.memoryFraction,0.2 map端記憶體緩衝,reduce端記憶體佔比;很多資料、網上視訊,都會說,這兩個引數, 是調節shuff
Spark調優之Shuffle調優
原理概述: 什麼樣的情況下,會發生shuffle? 在spark中,主要是以下幾個運算元:groupByKey、reduceByKey、countByKey、join(分情況,先groupByKey後再join是不會發生shuffle的),等等。 什麼是shuffle? groupByKey
Spark效能優化之資料傾斜調優與shuffle調優
一、資料傾斜發生的原理 原理:在進行shuffle的時候,必須將各個節點上相同的key拉取到某個節點上的一個task來進行處理,比如按照key進行聚合或join等操作。此時如果某個key對應的資料量特別大的話,就會發生資料傾斜。資料傾斜只會發生在shuffle過程中。常用的並且可能會觸
Spark效能調優 troubleshooting shuffle調優 reduce端緩衝大小以避免OOM
reduce導致 記憶體溢位原因 reduce端拉取map端task,是map端寫一點資料,reduce端taskk就會拉取一小部分資料,立即進行後面的聚合、運算元函式應用 每次拉取資料量大小是有buffer決定的,而預設大小是48M,有時候,map端的資料量很大的情況下,reduce端
Spark性能調優之道——解決Spark數據傾斜(Data Skew)的N種姿勢
sca ace 便是 triplet 大小 spark 構建 由於 itl 原文:http://blog.csdn.net/tanglizhe1105/article/details/51050974 背景 很多使用Spark的朋友很想知道rdd
spark性能調優之資源調優
重要 cnblogs logs 做的 參數說明 span 分配 比例 drive 轉https://tech.meituan.com/spark-tuning-basic.html spark作業原理 使用spark-submit提交一個Spark作業之後,這個作
【Spark篇】---Spark調優之代碼調優,數據本地化調優,內存調優,SparkShuffle調優,Executor的堆外內存調優
左右 任務調度 combiner flight 觸發 年齡 ans minor 序列化機制 一、前述 Spark中調優大致分為以下幾種 ,代碼調優,數據本地化,內存調優,SparkShuffle調優,調節Executor的堆外內存。 二、具體 1、代碼調優 1、避免創
Spark學習之路 (十一)SparkCore的調優之Spark內存模型
精準 規模 memory 此外 結構定義 申請 管理方式 存儲 內部 摘抄自:https://www.ibm.com/developerworks/cn/analytics/library/ba-cn-apache-spark-memory-management/index