背景：
資料傾斜是大資料領域繞經常遇到的問題，當你所需處理的資料量到達了上億甚至是千億條的時候，資料傾斜將是橫在你面前一道巨大的坎，這也是大資料處理的乙個**的bug。最近在用hadoop跑批的時候經常遇到，一條hivesql要跑好久才能跑完。
相信大部分做資料的童鞋們都會遇到資料傾斜，資料傾斜會發生在資料開發的各個環節中，比如：
用hive算資料的時候reduce階段卡在99.99% 用sparkstreaming做實時演算法時候，一直會有executor出現oom的錯誤，但是其餘的executor記憶體使用率卻很低
一、什麼是資料傾斜以及資料傾斜是怎麼產生的？
簡單來說資料傾斜就是資料的key的分化嚴重不均，造成一部分資料很多，一部分資料很少的局面。 舉個 word count 的入門例子，它的map 階段就是形成 （「aaa」,1）的形式，然後在reduce 階段進行 value 相加，得出 「aaa」 出現的次數。若進行 word count 的文字有100g，其中 80g 全部是 「aaa」 剩下 20g 是其餘單詞，那就會形成 80g 的資料量交給乙個 reduce 進行相加，其餘 20g 根據 key 不同分散到不同 reduce 進行相加的情況。如此就造成了資料傾斜，臨床反應就是 reduce 跑到 99%然後一直在原地等著 那80g 的reduce 跑完。
一、hadoop中的資料傾斜
hadoop中直接貼近使用者使用使用的時mapreduce程式和hive程式，雖說hive最後也是用mr來執行（至少目前hive記憶體計算並不普及），但是畢竟寫的內容邏輯區別很大，乙個是程式，乙個是sql，因此這裡稍作區分。
hadoop中的資料傾斜主要表現在、ruduce階段卡在99.99%，一直99.99%不能結束。
這裡如果詳細的看日誌或者和監控介面的話會發現：
有乙個多幾個reduce卡住
各種container報錯oom
讀寫的資料量極大，至少遠遠超過其它正常的reduce
伴隨著資料傾斜，會出現任務被kill等各種詭異的表現。
經驗：hive的資料傾斜，一般都發生在sql中group和on上，而且和資料邏輯繫結比較深。
二、spark中的資料傾斜
spark中的資料傾斜也很常見，這裡包括spark streaming和spark sql，表現主要有下面幾種：
executor lost，oom，shuffle過程出錯
driver oom
單個executor執行時間特別久，整體任務卡在某個階段不能結束
正常執行的任務突然失敗
補充一下，在spark streaming程式中，資料傾斜更容易出現，特別是在程式中包含一些類似sql的join、group這種操作的時候。 因為spark streaming程式在執行的時候，我們一般不會分配特別多的記憶體，因此一旦在這個過程**現一些資料傾斜，就十分容易造成oom。
0x03 資料傾斜的原理
一、資料傾斜產生的原因
我們以spark和hive的使用場景為例。他們在做資料運算的時候會設計到，countdistinct、group by、join等操作，這些都會觸發shuffle動作，一旦觸發，所有相同key的值就會拉到乙個或幾個節點上，就容易發生單點問題。
二、萬惡的shuffle
Hive資料傾斜問題
資料傾斜問題一直是大資料計算中普遍存在的現象，針對這種現象一般都是從兩方面解決，從資料本身和應用軟體進行優化。由於hive中計算任務是轉化成mapreduce進行的，當sql執行緩慢或者某幾個reduce任務一直卡在99 時，說明資料有傾斜現象。根本原因就是資料在map或者reduce中分布不均勻，...
Hive解決資料傾斜問題
簡單來說資料傾斜就是資料的key 的分化嚴重不均，造成一部分資料很多，一部分資料很少的局面。舉個 word count 的入門例子，它的map 階段就是形成 aaa 1 的形式，然後在reduce 階段進行 value 相加，得出 aaa 出現的次數。若進行 word count 的文字有100g，...
Hive解決資料傾斜問題
什麼是資料傾斜以及資料傾斜式怎麼產生的？簡單來說資料傾斜就是資料的key的分化嚴重不均，造成一部資料很多，一部分資料很少的局面。舉個 word count 的入門例子，它的map 階段就是形成 aaa 1 的形式，然後在reduce 階段進行 value 相加，得出 aaa 出現的次數。若進行 wo...