一、背景
1、第一個(gè)和第二個(gè)方案，都不適合做。
2、第三個(gè)方案，提高shuffle操作的reduce并行度
將reduce task的數(shù)量，變多，就可以讓每個(gè)reduce task分配到更少的數(shù)據(jù)量，這樣的話，也許就可以緩解，或者甚至是基本解決掉數(shù)據(jù)傾斜的問(wèn)題。
提升shuffle reduce端并行度，怎么來(lái)操作？
1、很簡(jiǎn)單，主要給我們所有的shuffle算子，比如groupByKey、countByKey、reduceByKey。在調(diào)用的時(shí)候，傳入進(jìn)去一個(gè)參數(shù)。一個(gè)數(shù)字。那個(gè)數(shù)字，就代表了那個(gè)shuffle操作的reduce端的并行度。那么在進(jìn)行shuffle操作的時(shí)候，就會(huì)對(duì)應(yīng)著創(chuàng)建指定數(shù)量的reduce task。
2、這樣的話，就可以讓每個(gè)reduce task分配到更少的數(shù)據(jù)?；究梢跃徑鈹?shù)據(jù)傾斜的問(wèn)題。
3、比如說(shuō)，原本某個(gè)task分配數(shù)據(jù)特別多，直接OOM，內(nèi)存溢出了，程序沒(méi)法運(yùn)行，直接掛掉。按照l(shuí)og，找到發(fā)生數(shù)據(jù)傾斜的shuffle操作，給它傳入一個(gè)并行度數(shù)字，這樣的話，原先那個(gè)task分配到的數(shù)據(jù)，肯定會(huì)變少。就至少可以避免OOM的情況，程序至少是可以跑的。
流程圖解
spark.default.parallelism，100
提升shuffle reduce并行度的缺陷
治標(biāo)不治本的意思，因?yàn)?，它沒(méi)有從根本上改變數(shù)據(jù)傾斜的本質(zhì)和問(wèn)題。不像第一個(gè)和第二個(gè)方案（直接避免了數(shù)據(jù)傾斜的發(fā)生）。原理沒(méi)有改變，只是說(shuō)，盡可能地去緩解和減輕shuffle reduce task的數(shù)據(jù)壓力，以及數(shù)據(jù)傾斜的問(wèn)題。
實(shí)際生產(chǎn)環(huán)境中的經(jīng)驗(yàn)。
1、如果最理想的情況下，提升并行度以后，減輕了數(shù)據(jù)傾斜的問(wèn)題，或者甚至可以讓數(shù)據(jù)傾斜的現(xiàn)象忽略不計(jì)，那么就最好。就不用做其他的數(shù)據(jù)傾斜解決方案了。
2、不太理想的情況下，就是比如之前某個(gè)task運(yùn)行特別慢，要5個(gè)小時(shí)，現(xiàn)在稍微快了一點(diǎn)，變成了4個(gè)小時(shí)；或者是原先運(yùn)行到某個(gè)task，直接OOM，現(xiàn)在至少不會(huì)OOM了，但是那個(gè)task運(yùn)行特別慢，要5個(gè)小時(shí)才能跑完。
那么，如果出現(xiàn)第二種情況的話，各位，就立即放棄第三種方案，開(kāi)始去嘗試和選擇后面的四種方案。
