原因： 大部分是因key分布不均勻，也有map端或reduce端傾斜或因資料本身特徵問題，只要涉及key的操作都可能出現傾斜。
容易出現的情況：a.group by不搭配聚合函式使用 b.count（distinct）資料量大時，因為此操作是根據group by分組按distinct欄位排序的 c.小表關聯大表的join操作
解析：大資料裡的資料一般都是map型別，key-value形式的，拿到hive來說，一般就是關聯條件為key，其它欄位為value，groupby後的字段就是key
表現：其他key執行完了，乙個key一直未執行完，reducer的資料分布不均勻，有乙個或少數reduce未完成，進度一直卡在99%（比如0-10，有11個key,0的資料量有100w記錄，而其它它10個key只有100條記錄。分到11個節點去執行，負責0那個key的節點就會執行很慢很慢）
大部分傾斜的key 都是0 或者null（這兩個值是比較常見的，預設值經常給0。不給的情況下就是null）
處理：找出發生資料傾斜的key作單獨處理。a.key值中包含空值或異常值時若不需要該值提前過濾掉，若需要則使用select case when city_id is null thenconcat('000000',round(rand()*100000)) city_id from *** 進行轉換。b.若group by欄位中有空值，調整相關hive引數設定。 c.資料傾斜非常嚴重時且不好處理時用distribute by rand() 使key完全隨機，各個節點都存在很多key，但會降低效率。
關於資料傾斜的知識學習
分組 注 group by 優於distinct group 情形 group by 維度過小，某值的數量過多 後果 處理某值的reduce非常耗時 去重 distinct count distinct xx 情形 某特殊值過多 後果 處理此特殊值的reduce耗時 連線 join 情形1 其中乙個...
mysql資料傾斜 Hive SQL 資料傾斜總結
在海量資料下的資料查詢中，資料傾斜是乙個很恐怖的場景。常常看似很普通的資料查詢，執行了幾個小時也沒有結果，其原因往往是發生了資料傾斜。如果真對資料傾斜採取相應的解決方法，那麼查詢效率將會大大提高。所以，分析資料傾斜是一件相當有意義的任務。本文總結不同情況下的資料傾斜，並分別給出解決方法。資料傾斜 資...
什麼是資料傾斜，怎麼解決資料傾斜？
相信很多接觸mapreduce的朋友對 資料傾斜 這四個字並不陌生，那麼究竟什麼是資料傾斜？又改怎樣解決這種該死的情況呢？何為資料傾斜？正常的資料分布理論上都是傾斜的，就是我們所說的2 8原理 80 的財富集中在20 的人手中，80 的使用者只使用20 的功能，20 的使用者貢獻了80 的訪問量，不...