Hive 數據傾斜怎么發現，怎么定位，怎么解決
多數介紹數據傾斜的文章都是以大篇幅的理論為主，並沒有給出具體的數據傾斜案例。當工作中遇到了傾斜問題，這些理論很難直接應用，導致我們面對傾斜時還是不知所措。
今天我們不扯大篇理論，直接以例子來實踐，排查是否出現了數據傾斜，具體是哪段代碼導致的傾斜，怎么解決這段代碼的傾斜。
當執行過程中任務卡在 99%，大概率是出現了數據傾斜，但是通常我們的 SQL 很大，需要判斷出是哪段代碼導致的傾斜，才能利於我們解決傾斜。
傾斜問題排查
數據傾斜大多數都是大 key 問題導致的。
如何判斷是大 key 導致的問題，可以通過下面方法：
1.通過時間判斷
如果某個 reduce 的時間比其他 reduce 時間長的多，如下圖，大部分 task 在 1 分鍾之內完成，只有 r_000000 這個 task 執行 20 多分鍾了還沒完成。
注意：要排除兩種情況：
如果每個 reduce 執行時間差不多，都特別長，不一定是數據傾斜導致的，可能是 reduce 設置過少導致的。
有時候，某個 task 執行的節點可能有問題，導致任務跑的特別慢。這個時候，mapreduce 的推測執行，會重啟一個任務。如果新的任務在很短時間內能完成，大數據培訓通常則是由於 task 執行節點問題導致的個別 task 慢。但是如果推測執行后的 task 執行任務也特別慢，那更說明該 task 可能會有傾斜問題。
2.通過任務 Counter 判斷
Counter 會記錄整個 job 以及每個 task 的統計信息。counter 的 url 一般類似：
http://bd001:8088/proxy/application_1624419433039_1569885/mapreduce/singletaskcounter/task_1624419433039_1569885_r_000000/org.apache.hadoop.mapreduce.FileSystemCounter
通過輸入記錄數，普通的 task counter 如下，輸入的記錄數是 13 億多:
而 task=000000 的 counter 如下，其輸入記錄數是 230 多億。是其他任務的 100 多倍：
4.定位 SQL 代碼
1.確定任務卡住的 stage
通過 jobname 確定 stage：
一般 Hive 默認的 jobname 名稱會帶上 stage 階段，如下通過 jobname 看到任務卡住的為 Stage-4：
如果 jobname 是自定義的，那可能沒法通過 jobname 判斷 stage。需要借助於任務日志：
找到執行特別慢的那個 task，然后 Ctrl+F 搜索 “CommonJoinOperator: JOIN struct” 。Hive 在 join 的時候，會把 join 的 key 打印到日志中。如下：
上圖中的關鍵信息是：struct<_col0:string, _col1:string, _col3:string>
這時候，需要參考該 SQL 的執行計划。通過參考執行計划，可以斷定該階段為 Stage-4 階段：
2.確定 SQL 執行代碼
確定了執行階段，即 stage。通過執行計划，則可以判斷出是執行哪段代碼時出現了傾斜。還是從此圖，這個 stage 中進行連接操作的表別名是 d：
就可以推測出是在執行下面紅框中代碼時出現了數據傾斜，因為這行的表的別名是 d：