一次查詢

應該是有一小部分數據 需要特殊處理
嘗試90天,反覆重試3個task:
最後3個失敗task ,一個執行成功,但是suffle Spill值很大;另外兩個失敗
這3個任務不成功,一直在重試,但失敗數比不持久化好很多
其實處理很快,就是shuffle read時間很久
發現task讀入的紀錄都很大,不到2萬條600兆
第一次150天數據量嘗試後期效果:

retryTask,因爲cant fetch錯誤

can't fetch可能因爲超出內存太多
怎麼知道爲什麼會超出內存太多?
combine Persist 4096 後的結果:

另外task數本來只有4096個 但是後來變成兩萬多個?
變成兩萬多個後也是大量不成功,一直在重複嘗試,看樣子依然是shuffle內存不夠。
這裏寫圖片描述
stage失敗和task失敗的區別是?
這裏寫圖片描述
1.1.2 spark.shuffle.spill
這個參數的默認值是true,用於指定Shuffle過程中如果內存中的數據超過閾值(參考spark.shuffle.memoryFraction的設置),那麼是否需要將部分數據臨時寫入外部存儲。如果設置爲false,那麼這個過程就會一直使用內存,會有Out Of Memory的風險。因此只有在確定內存足夠使用時,纔可以將這個選項設置爲false。

  對於Hash BasedShuffle的Shuffle Write過程中使用的org.apache.spark.util.collection.AppendOnlyMap就是全內存的方式,而org.apache.spark.util.collection.ExternalAppendOnlyMap對org.apache.spark.util.collection.AppendOnlyMap有了進一步的封裝,在內存使用超過閾值時會將它spill到外部存儲,在最後的時候會對這些臨時文件進行Merge。
  而Sort BasedShuffle Write使用到的org.apache.spark.util.collection.ExternalSorter也會有類似的spill。

  而對於ShuffleRead,如果需要做aggregate,也可能在aggregate的過程中將數據spill的外部存儲。

1.1.3 spark.shuffle.memoryFraction和spark.shuffle.safetyFraction
在啓用spark.shuffle.spill的情況下,spark.shuffle.memoryFraction決定了當Shuffle過程中使用的內存達到總內存多少比例的時候開始Spill。在Spark 1.2.0裏,這個值是0.2。通過這個參數可以設置Shuffle過程佔用內存的大小,它直接影響了Spill的頻率和GC。
如果Spill的頻率太高,那麼可以適當的增加spark.shuffle.memoryFraction來增加Shuffle過程的可用內存數,進而減少Spill的頻率。當然爲了避免OOM(內存溢出),可能就需要減少RDD cache所用的內存,即需要減少spark.storage.memoryFraction的值;但是減少RDD cache所用的內存有可能會帶來其他的影響,因此需要綜合考量。

  在Shuffle過程中,Shuffle佔用的內存數是估計出來的,並不是每次新增的數據項都會計算一次佔用的內存大小,這樣做是爲了降低時間開銷。但是估計也會有誤差,因此存在實際使用的內存數比估算值要大的情況,因此參數 spark.shuffle.safetyFraction作爲一個保險係數降低實際Shuffle過程所需要的內存值,降低實際內存超出用戶配置值的風險。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章