最近一段時間主要在用Hive，前幾天終於還是沒有逃過經典的資料傾斜問題，備受煎熬，最後終於成功解決，這裡記錄一下心得。

直接上乾貨：解決資料傾斜問題，最大的難點在於知道為什麼會傾斜！！！

一般會造成資料傾斜的情況無外乎在使用 group by 或者 distinct 或 join 等的情況中，由於資料分佈不均所引起，尤其是Join的情況居多，我這次是使用group by的時候發生的資料傾斜，其實其他情況都可以用一樣的處理方法。

情景復現：

    一個很長很長的HQL語句，最終結果是把多個數據源的資料union 起來，然後寫入目的表，執行指令碼，HIVE劃分成多個階段，大概執行到後半部分的某個任務時，出現map 100%, reduce 99%的情況，然後一直是reduce 99%，直到一定時間之後，HIVE最終無法執行完成，報錯。

分析過程：

日誌平臺是很好的幫助分析問題的工具，起碼可以看到Map和Reduce階段的進度，在我的例子中，最後只剩一個reducer在執行（實際是兩個，因為叢集會在只剩下一個reducer執行一段時間沒有結束後，在另一個結點起相同的任務，兩個結點有一個先跑完，就執行完成，但這兩個階段之間也會競爭資源，比如網路頻寬等等），細看會發現，該reducer分配的資料量過多——典型的傾斜問題。

發現問題之後，我嘗試了把多個數據源的資料分別單獨執行，發現執行到其中一個數據源的時候，傾斜問題復現了，確認了一下這個資料來源的資料量其實並沒有比別的資料來源大多少，說明不是資料量太多的問題（如果是因為資料量的話，還有可能報GC over limit之類的錯誤，這種錯誤可以通過設定hive引數，或者化整為零的思路解決）。

好，找到問題來源，根據group by的欄位，寫個簡單的sql語句，就能看出來，每個執行結點大概能分到多少資料，一看就驚呆了，group by 的欄位中，有一個全為null的組合，且為null的資料量太大，是其他組合的數十倍，而根據我寫的語句，這些null的資料會被分到一起，由此導致了資料傾斜問題。

解決方法：

把這些全為null的資料拿出來單獨處理（全為null的資料一般都比較好處理，通常都會丟棄），剩下的有效資料再進行處理，問題解決。

友情提示：

遇到資料傾斜問題是個很煩人的問題，不是HQL的語法問題，也不是邏輯問題（其實換個角度也可以說是邏輯問題），就是執行不了，這時通常會很煩躁，我當時因為時間緊，任務中，遇到這個問題很頭疼，瞬間蒙圈了，有點不知所措，結果就是拖了兩天才解決這個問題。所以，遇到傾斜問題不要擔心，靜下心來，按照常規思路，先定期問題，然後分析原因，知道了原因，解決方案也就自然有了