轉自：https://blog.csdn.net/xinzhi8/article/details/71455883

操作：

原因：

1)、key分佈不均勻

2)、業務資料本身的特性

3)、建表時考慮不周

4)、某些SQL語句本身就有資料傾斜

解決方案

1.引數調節：

　　hive.map.aggr = true

　　Map 端部分聚合，相當於Combiner

　　hive.groupby.skewindata=true（萬能藥膏）

　　有資料傾斜的時候進行負載均衡，當選項設定為 true，生成的查詢計劃會有兩個 MR Job。第一個 MR Job 中，Map 的輸出結果集合會隨機分佈到 Reduce 中，每個 Reduce 做部分聚合操作，

　　並輸出結果，這樣處理的結果是相同的 Group By Key 有可能被分發到不同的 Reduce 中，從而達到負載均衡的目的；第二個 MR Job 再根據預處理的資料結果按照 Group By Key 分佈到 Reduce 中

　　（這個過程可以保證相同的 Group By Key 被分佈到同一個 Reduce 中），最後完成最終的聚合操作。

2.SQL語句調節：　　

大小表Join：

使用map join讓小的維度表（1000條以下的記錄條數） 先進記憶體。在map端完成reduce.

大表Join大表：

把空值的key變成一個字串加上隨機數，把傾斜的資料分到不同的reduce上，由於null值關聯不上，處理後並不影響最終結果。

count distinct大量相同特殊值：

count distinct時，將值為空的情況單獨處理，如果是計算count distinct，可以不用處理，直接過濾，在最後結果中加1。如果還有其他計算，需要進行group by，可以先將值為空的記錄單獨處理，再和其他計算結果進行union。

group by維度過小：

採用sum() group by的方式來替換count(distinct)完成計算。

特殊情況特殊處理：

在業務邏輯優化效果的不大情況下，有些時候是可以將傾斜的資料單獨拿出來處理。最後union回去。

典型的業務場景

空值產生的資料傾斜

場景：如日誌中，常會有資訊丟失的問題，比如日誌中的 user_id，如果取其中的 user_id 和 使用者表中的user_id 關聯，會碰到資料傾斜的問題。

解決方法1： user_id為空的不參與關聯

select * from log a

  join users b

  on a.user_id is not null

  and a.user_id = b.user_id

union all

select * from log a

  where a.user_id is null;

解決方法2 ：賦與空值分新的key值

select *

  from log a

  left outer join users b

  on case when a.user_id is null then concat(‘hive’,rand() ) else a.user_id end = b.user_id;

結論：方法2比方法1效率更好，不但io少了，而且作業數也少了。解決方法1中 log讀取兩次，jobs是2。解決方法2 job數是1 。這個優化適合無效 id (比如 -99 , ’’, null 等) 產生的傾斜問題。把空值的 key 變成一個字串加上隨機數，就能把傾斜的資料分到不同的reduce上 ,解決資料傾斜問題。

不同資料型別關聯產生資料傾斜

場景：使用者表中user_id欄位為int，log表中user_id欄位既有string型別也有int型別。當按照user_id進行兩個表的Join操作時，預設的Hash操作會按int型的id來進行分配，這樣會導致所有string型別id的記錄都分配到一個Reducer中。

解決方法：把數字型別轉換成字串型別

select * from users a

  left outer join logs b

  on a.usr_id = cast(b.user_id as string)

小表不小不大，怎麼用 map join 解決傾斜問題

使用 map join 解決小表(記錄數少)關聯大表的資料傾斜問題，這個方法使用的頻率非常高，但如果小表很大，大到map join會出現bug或異常，這時就需要特別的處理。 以下例子:

select * from log a

  left outer join users b

  on a.user_id = b.user_id;

users 表有 600w+ 的記錄，把 users 分發到所有的 map 上也是個不小的開銷，而且 map join 不支援這麼大的小表。如果用普通的 join，又會碰到資料傾斜的問題。

解決方法：

select * from log a

  left outer join (

    select  d.*

      from ( select distinct user_id from log ) c

      join users d

      on c.user_id = d.user_id

    ) b

  on a.user_id = b.user_id;

假如，log裡user_id有上百萬個，這就又回到原來map join問題。所幸，每日的會員uv不會太多，有交易的會員不會太多，有點選的會員不會太多，有佣金的會員不會太多等等。所以這個方法能解決很多場景下的資料傾斜問題。

總結

使map的輸出資料更均勻的分佈到reduce中去，是我們的最終目標。由於Hash演算法的侷限性，按key Hash會或多或少的造成資料傾斜。大量經驗表明資料傾斜的原因是人為的建表疏忽或業務邏輯可以規避的。在此給出較為通用的步驟：

1、取樣log表，哪些user_id比較傾斜，得到一個結果表tmp1。由於對計算框架來說，所有的資料過來，他都是不知道資料分佈情況的，所以取樣是並不可少的。

2、資料的分佈符合社會學統計規則，貧富不均。傾斜的key不會太多，就像一個社會的富人不多，奇特的人不多一樣。所以tmp1記錄數會很少。把tmp1和users做map join生成tmp2,把tmp2讀到distribute file cache。這是一個map過程。

3、map讀入users和log，假如記錄來自log,則檢查user_id是否在tmp2裡，如果是，輸出到本地檔案a,否則生成<user_id,value>的key,value對，假如記錄來自member,生成<user_id,value>的key,value對，進入reduce階段。

4、最終把a檔案，把Stage3 reduce階段輸出的檔案合併起寫到hdfs。

如果確認業務需要這樣傾斜的邏輯，考慮以下的優化方案：

1、對於join，在判斷小表不大於1G的情況下，使用map join

2、對於group by或distinct，設定 hive.groupby.skewindata=true

3、儘量使用上述的SQL語句調節進行優化