我們在用map /reduce程式執行時，有時候會發現reduce節點大部分執行完畢，但是有乙個或者幾個reduce節點執行很慢，導致整個程式的處理時間很長，這是因為某乙個key的條數比其他key多很多（有時是百倍或者千倍之多），這條key所在的reduce節點所處理的資料量比其他節點就大很多，從而導致某幾個節點遲遲執行不完。這種現象就是因為key分布不均勻、散度不夠導致的，也就是我們所說的資料傾斜。
在hive上執行join,group by,count distinct等操作的時候可能會發現ruduce階段卡在99.99%，一直99.99%不能結束，檢視任務監控頁面，發現只有少量（1個或幾個）reduce子任務未完成；這裡進一步檢視程序日誌或者webui會發現：有乙個多幾個reduce卡住；各種container報錯oom，讀寫的資料量極大，至少遠遠超過其它正常的reduce ，伴隨著資料傾斜，會出現任務被kill等各種詭異的表現。一般情況下hive的資料傾斜，都發生在sql中group和on上，而且和資料邏輯繫結比較深。
1)hive.groupby.skewindata變數，這個變數是用於控制負載均衡的。當資料出現傾斜時，如果該變數設定為true，那麼hive會自動進行負載均衡。
2)mapjoin方式
3)count distinct的操作，先轉成group，再count
4)hive.groupby.skewindata=true
5)left semi jioin的使用
6)設定map端輸出、中間結果壓縮
深入理解hadoop（三）
hadoop 最初是為批處理作業設計的，當時只採用了乙個簡單的fifo排程機制分配任務，隨著hadoop的普及以及應用的使用者越來越多，基於fifo的單使用者排程機制不能很好的利用集群資源 比如機器學習和資料探勘對處理耗時要求不高但i o密集，生產性作業隊實時要求高，如hive查詢統計cpu密集，即...
《深入理解Spark》之join和資料傾斜問題
package com.lyzx.day34 import org.apache.spark.class t2 對於join之前進行co partition和不進行co partition的效率測試 實測join之前進行co partition操作的效率高於直接join 注意 資料量小的時候情況不一...
Hadoop資料傾斜處理
何為資料傾斜？在弄清什麼是資料傾斜之前,我想讓大家看看資料分布的概念 正常的資料分布理論上都是傾斜的，就是我們所說的20 80原理 80 的財富集中在20 的人手中,80 的使用者只使用20 的功能 20 的使用者貢獻了80 的訪問量 不同的資料字段可能的資料傾斜一般有兩種情況 一種是唯一值非常少，...