南國在最開始學習hadoop的時候，一直其他人說的資料傾斜及資料傾斜的解決辦法沒有完全弄明白。通過這段時間的學習，看了許多資料，這裡參考網上資料 以及自己的理解。這篇部落格 寫乙個有關於資料傾斜的歸納總結。話不多說，乾貨馬上送到。。。
在弄清什麼是資料傾斜之前,我想讓大家看看資料分布的概念:
正常的資料分布理論上都是傾斜的，就是我們所說的20-80原理：80%的財富集中在20%的人手中, 80%的使用者只使用20%的功能 , 20%的使用者貢獻了80%的訪問量 , 不同的資料字段可能的
資料傾斜一般有兩種情況:
資料傾斜在mapreduce程式設計模型中十分常見,它是key分布不均勻，導致分發到不同的reduce上，個別reduce任務特別重，導致其他reduce都完成，而這些個別的reduce遲遲不完成的情況。用最通俗易懂的話來說,資料傾斜無非就是大量的相同key被partition分配到乙個分割槽裡,造成了』乙個人累死,其他人閒死』的情況,這種情況是我們不能接受的,這也違背了平行計算的初衷,首先乙個節點要承受著巨大的壓力,而其他節點計算完畢後要一直等待這個忙碌的節點,也拖累了整體的計算時間,可以說效率是十分低下的。
在map端和reduce端都有可能發生資料傾斜。在map端的資料傾斜會讓多樣化的資料集的處理效率更低。在reduce端的資料傾斜常常**於mapreduce的預設分割槽器。
分割槽：常見的mapreduce分割槽方式為hash 和range ，
hash partition 的好處是比較彈性，跟資料型別無關，實現簡單（設定reduce個數就好，一般不需要自己實現）
range partition 需要實現者自己了解資料分布, 有時候需要手工做sample取樣. 同時也不夠彈性, 表現在幾個方面，
對同乙個表的不同欄位都需要實現不同的range partition, 對於時間這種字段根據查詢型別的不同或者過濾條件的不同切分range 的大小都不一定.
有時候可能設計使用多個字段組合的情況, 這時候又不能使用之前單個欄位的partition 類, 並且多個字段組合之間有可能有隱含的聯絡，比如出生日期和星座，商品和季節.
手工做sample 非常耗時間，需要使用者對查詢使用的資料集的分布有領域知識.
分配方式是死的，reduce 個數是確定的，一旦某種情況下發生傾斜，調整引數
其他的分割槽型別還有hbase 的hregionpartitioner 或者totalorder partitioner 等.
發生資料傾斜的原因有：
解決方案:
注意：資料傾斜沒有一勞永逸的方式可以解決，了解你的資料集的分布情況，然後了解你所使用計算框架的執行機制和瓶頸，針對特定的情況做特定的優化，做多種嘗試，觀察是否有效.
參考文章：
Hadoop資料傾斜處理
何為資料傾斜？在弄清什麼是資料傾斜之前,我想讓大家看看資料分布的概念 正常的資料分布理論上都是傾斜的，就是我們所說的20 80原理 80 的財富集中在20 的人手中,80 的使用者只使用20 的功能 20 的使用者貢獻了80 的訪問量 不同的資料字段可能的資料傾斜一般有兩種情況 一種是唯一值非常少，...
深入理解hadoop資料傾斜
我們在用map reduce程式執行時，有時候會發現reduce節點大部分執行完畢，但是有乙個或者幾個reduce節點執行很慢，導致整個程式的處理時間很長，這是因為某乙個key的條數比其他key多很多 有時是百倍或者千倍之多 這條key所在的reduce節點所處理的資料量比其他節點就大很多，從而導致...
資料傾斜處理方法
資料傾斜處理方法 對於不平衡資料的分類，為了解決上述準確率失真的問題，我們要換用 f 值取代準確率作為評價指標。用不平衡資料訓練，召回率很低導致 f 值也很低。這時候有兩種不同的方法。第一種方法是修改訓練演算法，使之能夠適應不平衡資料。著名的代價敏感學習就是這種方法。另一種方法是運算元據，人為改變正...