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

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

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

表結(jié)構(gòu)描述

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

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

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

user_info 表的數(shù)據(jù)量：1.02 億，大小：13.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. 需求

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

2. 代碼

根據(jù)以上需求，我們以 user_info 表為基礎(chǔ)表，將其余表關(guān)聯(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 時任務(wù)卡在 99%：

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

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 問題導(dǎo)致的。

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

1. 通過時間判斷

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

注意：要排除兩種情況：

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

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

2. 通過任務(wù) 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 多億。是其他任務(wù)的 100 多倍：

4. 定位 SQL 代碼

1. 確定任務(wù)卡住的 stage

• 通過 jobname 確定 stage：

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

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

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

上圖中的關(guān)鍵信息是：struct<_col0:string, _col1:string, _col3:string>

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

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

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

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

5. 解決傾斜

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

傾斜原因:

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

解決方法：

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

witht1as(
select
  u.userkey,
  o.*
fromuser_infou
leftjoinuser_ordero
onu.idno=o.idno
whereu.idnoisnotnull
--是可以把where條件寫在后面的，hive會進(jìn)行謂詞下推，先執(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ù)賦個隨機(jī)值，但是要注意隨機(jī)值不能和表中的身份證號有重復(fù)：

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 有實(shí)際意義，不能直接過濾掉。

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

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

3. 增加 reduce 個數(shù)

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

配置 reduce 個數(shù)：

setmapred.reduce.tasks=15;

4. 轉(zhuǎn)換為 mapjoin

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

配置 mapjoin：

sethive.auto.convert.join=true;是否開啟自動mapjoin，默認(rèn)是true

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

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

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

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

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

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

6. 調(diào)整內(nèi)存設(shè)置

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

配置內(nèi)存：

setmapreduce.reduce.memory.mb=5120;設(shè)置reduce內(nèi)存大小

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

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