面試題：Spark資料傾斜解決方案

在面試大資料開發崗位中，Spark是必須具備的技能之一，

最近在復習Spark時，感覺spark發生資料傾斜場景有很多，但是在面試時，說太多了感覺太廢話了，如何在面試中思維清晰的回答資料傾斜問題呢？下面是個人總結的觀點，有問題麻煩各位技術大佬指導，

資料傾斜原理：在進行shuffle的時候，必須將各個節點上相同的key拉取到某個節點上的一個task來進行處理，比如按照key進行 聚合或join等操作，此時如果某個key對應的資料量特別大的話，就會發生資料傾斜，比如大部分key對應10條資料，但是個別key卻對應了100萬條資料，那么大部分task可能就只會分配到10條資料，然后1秒鐘就運行完了；但是個別task可能分配到了100萬資料，要運行一兩個小時，因此，整個Spark作業的運行進度是由運行時間最長的那個task決定的，

資料傾斜解決方案：

發生資料傾斜一般都是出現了shuffle操作，shuffle操作一般都是由聚合算子和Join所引發，所以我們從這兩方面去解決問題，

1、兩階段聚合（區域聚合+全域聚合，針對聚合算子）

方案適用場景：對RDD執行reduceByKey等聚合類shuffle算子或者在Spark SQL中使用group by陳述句進行分組聚合時，比較適用這種方案，

方案實作思路：這個方案的核心實作思路就是進行兩階段聚合，第一次是區域聚合，先給每個key都打上一個隨機 數，比如10以內的亂數，此時原先一樣的key就變成不一樣的了，比如(hello, 1) (hello, 1) (hello, 1) (hello, 1)，就會變成(1_hello, 1) (1_hello, 1) (2_hello, 1) (2_hello, 1)，接著對打上亂數后的資料，執行reduceByKey等聚合操作，進行區域聚合，那么區域聚合結果，就會變成了(1_hello, 2) (2_hello, 2)，然后將各個key的前綴給去掉，就會變成(hello,2)(hello,2)，再次進行全域聚合操作，就可以得到最終結果了，比如(hello, 4)，

方案實作原理：將原本相同的key通過附加隨機前綴的方式，變成多個不同的key，就可以讓原本被一個task處理的資料分散到多個task上去做區域聚合，進而解決單個task處理資料量過多的問題，接著去除掉隨機前綴，再次進行全域聚合，就可以得到最終的結果，

方案優點：對于聚合類的shuffle操作導致的資料傾斜，效果是非常不錯的，通常都可以解決掉資料傾斜，或者至少是大幅度緩解資料傾斜，將Spark作業的性能提升數倍以上，

方案缺點：僅僅適用于聚合類的shuffle操作，適用范圍相對較窄，如果是join類的shuffle操作，還得用其他的解決方案，

2、將reduce join轉為map join （大表join小表）

方案適用場景：

①在對RDD使用join類操作，或者是在Spark SQL中使用join陳述句

②而且join操作中的一個RDD或表的資料量比較小（比如幾百M或者一兩G），比較適用此方案，spark.sql.autoBroadcastJoinThreshold用于配置一個表在執行 join 操作時能夠廣播給所有 worker 節點的最大位元組大小，通地將這個值設定為-1可以禁用廣播

方案實作思路：不使用join算子進行連接操作，而使用Broadcast變數與map類算子實作join操作，進而完全規避掉shuffle類的操作，徹底避免資料傾斜的發生和出現，將較小RDD中的資料直接通過collect算子拉取到Driver端的記憶體中來，然后對其創建一個Broadcast變數；接著對另外一個RDD執行map類算子，在算子函式內，從Broadcast變數中獲取較小RDD的全量 資料，與當前RDD的每一條資料按照連接key進行比對，如果連接key相同的話，那么就將兩個RDD的資料用你需要的方式連接起來，

方案實作原理：普通的join是會走shuffle程序的，而一旦shuffle，就相當于會將相同key的數 據拉取到一個shuffle read task中再進行join，此時就是reduce join，但是如果一個RDD是比較小的，則可以采用廣播小RDD全量資料+map算子來實作與join同樣的效果，也就是map join，此時就不會發生shuffle操作，也就不會發生資料傾斜，具體原理如下圖所示，

方案優點：對join操作導致的資料傾斜，效果非常好，因為根本就不會發生shuffle，也就根本不會發生資料傾斜，

方案缺點：適用場景較少，因為這個方案只適用于一個大表和一個小表的情況，畢竟我們需要將小表進行廣播，此時會 比較消耗記憶體資源，driver和每個Executor記憶體中都會駐留一份小RDD的全量資料，如果我們廣播出去的RDD資料比較大，比如10G以上，那么就可能發生記憶體溢位了，因此并不適合兩個都是大表的情況，

3、采樣傾斜key并分拆join操作（大表join大表，少數key出現資料傾斜）

方案適用場景的條件：

1、兩個RDD/Hive表進行join的時候，如果資料量都比較大，無法采用“解決方案二”，那么此時可以看一下兩個RDD/Hive表中的key分布情況，

2、如果出現資料傾斜，是因為其中某一個RDD/Hive表中的少數幾個key的資料量過大，而另一個RDD/Hive表中的所有key都分布比較均勻，那么采用這個解決方案是比較合適的，

方案實作思路：

?對包含少數幾個資料量過大的key的那個RDD，通過sample算子采樣出一份樣本來，然后統計一下每個key的數量，計算出來資料量最大的是哪幾個key，

?然后將這幾個key對應的資料從原來的RDD中拆分出來，形成一個單獨的RDD，并給每個key都打上n以內的亂數作為前綴，而不會導致傾斜的大部分key形成另外一個RDD，

?接著將需要join的另一個RDD，也過濾出來那幾個傾斜key對應的資料并形成一個單獨的RDD，將每條資料膨脹成n條資料，這n條資料都按順序附加一個0~n的前綴，不會導致傾斜的大部分key也形成另外一個RDD，

?再將附加了隨機前綴的獨立RDD與另一個膨脹n倍的獨立RDD進行join，此時就可以將原先相同的key打散成n份，分散到多個task中去進行join了，

?而另外兩個普通的RDD就照常join即可，

?最后將兩次join的結果使用union算子合并起來即可，就是最終的join結果，

方案實作原理：對于join導致的資料傾斜，如果只是某幾個key導致了傾斜，可以將少數幾個key分拆成獨立RDD，并附加隨機前綴打散成n份去進行join，此時這幾個key對應的資料就不會集中在少數幾個task上，而是分散到多個task進行join了，

方案優點：對于join導致的資料傾斜，如果只是某幾個key導致了傾斜，采用該方式可以用最有效的方式打散key進行join，而且只需要針對少數傾斜key對應的資料進行擴容n倍，不需要對全量資料進行擴容，避免了占用過多記憶體，

方案缺點：如果導致傾斜的key特別多的話，比如成千上萬個key都導致資料傾斜，那么這種方式也不適合，

4、使用隨機前綴和擴容RDD進行join （大表join大表，大量key出現資料傾斜）

方案適用場景：如果在進行join操作時，RDD中有大量的key導致資料傾斜，那么進行分拆key也沒什么意義，此時就只能使用最后一種方案來解決問題了，

方案實作思路：

?該方案的實作思路基本和“解決方案三”類似，首先查看RDD/Hive表中的資料分布情況，找到那個造成資料傾斜的RDD/Hive表，比如有多個key都對應了超過1萬條資料，

?然后將該RDD的每條資料都打上一個n以內的隨機前綴，

?同時對另外一個正常的RDD進行擴容，將每條資料都擴容成n條資料，擴容出來的每條資料都依次打上一個0~n的前綴，

?最后將兩個處理后的RDD進行join即可，

方案實作原理：將原先一樣的key通過附加隨機前綴變成不一樣的key，然后就可以將這些處理后的“不同 key”分散到多個task中去處理，而不是讓一個task處理大量的相同key，該方案與“解決方案六”的不同之處就在于，上一種方案是盡量只對少數傾 斜key對應的資料進行特殊處理，由于處理程序需要擴容RDD，因此上一種方案擴容RDD后對記憶體的占用并不大；而這一種方案是針對有大量傾斜key的情 況，沒法將部分key拆分出來進行單獨處理，因此只能對整個RDD進行資料擴容，對記憶體資源要求很高，

方案優點：對join型別的資料傾斜基本都可以處理，而且效果也相對比較顯著，性能提升效果非常不錯，

方案缺點：該方案更多的是緩解資料傾斜，而不是徹底避免資料傾斜，而且需要對整個RDD進行擴容，對記憶體資源要求很高，

方案實踐經驗：曾經開發一個資料需求的時候，發現一個join導致了資料傾斜，優化之前，作業的執行時間大約是60分鐘左右；使用該方案優化之后，執行時間縮短到10分鐘左右，性能提升了6倍，