多數(shù)介紹數(shù)據(jù)傾斜的文章都是以大篇幅的理論為主，并沒有給出具體的數(shù)據(jù)傾斜案例。當工作中遇到了傾斜問題，這些理論很難直接應用，導致我們面對傾斜時還是不知所措。

今天我們不扯大篇理論，直接以例子來實踐，排查是否出現(xiàn)了數(shù)據(jù)傾斜，具體是哪段代碼導致的傾斜，怎么解決這段代碼的傾斜。

當執(zhí)行過程中任務卡在 99%，大概率是出現(xiàn)了數(shù)據(jù)傾斜，但是通常我們的 SQL 很大，需要判斷出是哪段代碼導致的傾斜，才能利于我們解決傾斜。通過下面這個非常簡單的例子來看下如何定位產(chǎn)生數(shù)據(jù)傾斜的代碼。

表結構描述

先來了解下這些表中我們需要用的字段及數(shù)據(jù)量：

表的字段非常多，此處僅列出我們需要的字段

第一張表：user_info （用戶信息表，用戶粒度）

user_info 表的數(shù)據(jù)量：1.02 億，大?。?3.9G，所占空間：41.7G（HDFS三副本）

第二張表：user_active （用戶活躍表，用戶粒度）

user_active 表的數(shù)據(jù)量：1.1 億

第三張表：user_intend（用戶意向表，此處只取近六個月的數(shù)據(jù)，用戶粒度）

user_intend 表的數(shù)據(jù)量：800 萬

第四張表：user_order（用戶訂單表，此處只取近六個月的訂單數(shù)據(jù)，用戶粒度）

user_order 表的數(shù)據(jù)量：640 萬

1. 需求

需求非常簡單，就是將以上四張表關聯(lián)組成一張大寬表，大寬表中包含用戶的基本信息，活躍情況，購買意向及此用戶下訂單情況。

2. 代碼

根據(jù)以上需求，我們以 user_info 表為基礎表，將其余表關聯(lián)為一個寬表，代碼如下：

select
a.userkey,
a.idno,
a.phone,
a.name,
b.user_active_at,
c.intend_commodity,
c.intend_rank,
d.order_num,
d.order_amount
fromuser_infoa
leftjoinuser_activebona.userkey=b.userkey
leftjoinuser_intendcona.phone=c.phone
leftjoinuser_orderdona.idno=d.idno;

執(zhí)行上述語句，在執(zhí)行到某個 job 時任務卡在 99%：

這時我們就應該考慮出現(xiàn)數(shù)據(jù)傾斜了。其實還有一種情況可能是數(shù)據(jù)傾斜，就是任務超時被殺掉，Reduce 處理的數(shù)據(jù)量巨大，在做 full gc 的時候，stop the world。導致響應超時，超出默認的 600 秒，任務被殺掉。報錯信息一般如下：

AttemptID:attempt_1624419433039_1569885_r_000000 Timed outafter 600 secs Container killed by the ApplicationMaster. Container killed onrequest. Exit code is 143 Container exited with a non-zero exit code 143

3. 傾斜問題排查

數(shù)據(jù)傾斜大多數(shù)都是大 key 問題導致的。

如何判斷是大 key 導致的問題，可以通過下面方法：

1. 通過時間判斷

如果某個 reduce 的時間比其他 reduce 時間長的多，如下圖，大部分 task 在 1 分鐘之內完成，只有 r_000000 這個 task 執(zhí)行 20 多分鐘了還沒完成。

注意：要排除兩種情況：

1. 如果每個 reduce 執(zhí)行時間差不多，都特別長，不一定是數(shù)據(jù)傾斜導致的，可能是 reduce 設置過少導致的。

2. 有時候，某個 task 執(zhí)行的節(jié)點可能有問題，導致任務跑的特別慢。這個時候，mapreduce 的推測執(zhí)行，會重啟一個任務。如果新的任務在很短時間內能完成，通常則是由于 task 執(zhí)行節(jié)點問題導致的個別 task 慢。但是如果推測執(zhí)行后的 task 執(zhí)行任務也特別慢，那更說明該 task 可能會有傾斜問題。

2. 通過任務 Counter 判斷

Counter 會記錄整個 job 以及每個 task 的統(tǒng)計信息。counter 的 url 一般類似：

http://bd001:8088/proxy/application_1624419433039_1569885/mapreduce/singletaskcounter/task_1624419433039_1569885_r_000000/org.apache.hadoop.mapreduce.FileSystemCounter

通過輸入記錄數(shù)，普通的 task counter 如下，輸入的記錄數(shù)是 13 億多:

而 task=000000 的 counter 如下，其輸入記錄數(shù)是 230 多億。是其他任務的 100 多倍：

4. 定位 SQL 代碼

1. 確定任務卡住的 stage

• 通過 jobname 確定 stage：

  一般 Hive 默認的 jobname 名稱會帶上 stage 階段，如下通過 jobname 看到任務卡住的為 Stage-4：

• 如果 jobname 是自定義的，那可能沒法通過 jobname 判斷 stage。需要借助于任務日志：

  找到執(zhí)行特別慢的那個 task，然后 Ctrl+F 搜索 “CommonJoinOperator: JOIN struct” 。Hive 在 join 的時候，會把 join 的 key 打印到日志中。如下：

上圖中的關鍵信息是：struct<_col0:string, _col1:string, _col3:string>

這時候，需要參考該 SQL 的執(zhí)行計劃。通過參考執(zhí)行計劃，可以斷定該階段為 Stage-4 階段：

2. 確定 SQL 執(zhí)行代碼

確定了執(zhí)行階段，即 stage。通過執(zhí)行計劃，則可以判斷出是執(zhí)行哪段代碼時出現(xiàn)了傾斜。還是從此圖，這個 stage 中進行連接操作的表別名是 d：

就可以推測出是在執(zhí)行下面紅框中代碼時出現(xiàn)了數(shù)據(jù)傾斜，因為這行的表的別名是 d：

5. 解決傾斜

我們知道了哪段代碼引起的數(shù)據(jù)傾斜，就針對這段代碼查看傾斜原因，看下這段代碼的表中數(shù)據(jù)是否有異常。

傾斜原因:

本文的示例數(shù)據(jù)中 user_info 和 user_order 通過身份證號關聯(lián)，檢查發(fā)現(xiàn) user_info 表中身份證號為空的有 7000 多萬，原因就是這 7000 多萬數(shù)據(jù)都分配到一個 reduce 去執(zhí)行，導致數(shù)據(jù)傾斜。

解決方法：

1. 可以先把身份證號為空的去除之后再關聯(lián)，最后按照 userkey 連接，因為 userkey 全部都是有值的：

witht1as(
select
  u.userkey,
  o.*
fromuser_infou
leftjoinuser_ordero
onu.idno=o.idno
whereu.idnoisnotnull
--是可以把where條件寫在后面的，hive會進行謂詞下推，先執(zhí)行where條件在執(zhí)行l(wèi)eftjoin
)

select
a.userkey,
a.idno,
a.phone,
a.name,
b.user_active_at,
c.intend_commodity,
c.intend_rank,
d.order_num,
d.order_amount
fromuser_infoa
leftjoinuser_activebona.userkey=b.userkey
leftjoinuser_intendcona.phone=c.phone
leftjoint1dona.userkey=d.userkey;

2. 也可以這樣，給身份證為空的數(shù)據(jù)賦個隨機值，但是要注意隨機值不能和表中的身份證號有重復：

select
a.userkey,
a.idno,
a.phone,
a.name,
b.user_active_at,
c.intend_commodity,
c.intend_rank,
d.order_num,
d.order_amount
fromuser_infoa
leftjoinuser_activebona.userkey=b.userkey
leftjoinuser_intendcona.phone=c.phone
leftjoinuser_orderdonnvl(a.idno,concat(rand(),'idnumber'))=d.idno;

其他的解決數(shù)據(jù)傾斜的方法：

1. 過濾掉臟數(shù)據(jù)

如果大 key 是無意義的臟數(shù)據(jù)，直接過濾掉。本場景中大 key 有實際意義，不能直接過濾掉。

2. 數(shù)據(jù)預處理

數(shù)據(jù)做一下預處理（如上面例子，對 null 值賦一個隨機值），盡量保證 join 的時候，同一個 key 對應的記錄不要有太多。

3. 增加 reduce 個數(shù)

如果數(shù)據(jù)中出現(xiàn)了多個大 key，增加 reduce 個數(shù)，可以讓這些大 key 落到同一個 reduce 的概率小很多。

配置 reduce 個數(shù)：

setmapred.reduce.tasks=15;

4. 轉換為 mapjoin

如果兩個表 join 的時候，一個表為小表，可以用 mapjoin 做。

配置 mapjoin：

sethive.auto.convert.join=true;是否開啟自動mapjoin，默認是true

sethive.mapjoin.smalltable.filesize=100000000;mapjoin的表size大小

5. 啟用傾斜連接優(yōu)化

hive 中可以設置 hive.optimize.skewjoin 將一個 join sql 分為兩個 job。同時可以設置下 hive.skewjoin.key，此參數(shù)表示 join 連接的 key 的行數(shù)超過指定的行數(shù)，就認為該鍵是偏斜連接鍵，就對 join 啟用傾斜連接優(yōu)化。默認 key 的行數(shù)是 100000。

配置傾斜連接優(yōu)化：

sethive.optimize.skewjoin=true;啟用傾斜連接優(yōu)化

sethive.skewjoin.key=200000;超過20萬行就認為該鍵是偏斜連接鍵

6. 調整內存設置

適用于那些由于內存超限任務被 kill 掉的場景。通過加大內存起碼能讓任務跑起來，不至于被殺掉。該參數(shù)不一定會明顯降低任務執(zhí)行時間。

配置內存：

setmapreduce.reduce.memory.mb=5120;設置reduce內存大小

setmapreduce.reduce.java.opts=-Xmx5000m-XX:MaxPermSize=128m;

附：Hive 配置屬性官方鏈接：https://cwiki.apache.org/confluence/display/Hive/Configuration+Properties