解決reduce拉取map數據的時候key設計的不均衡問題

什麼是數據傾斜及數據傾斜是怎麼產生?

簡單來說數據傾斜就是數據的key 的分化嚴重不均,造成一部分數據很多,大部分數據很少的局面。

舉個 word count 的入門例子,它的map 階段就是形成 (“aaa”,1)的形式,然後在reduce 階段進行 value 相加,得出 “aaa” 出現的次數。若進行 word count 的文本有100G,其中 80G 全部是 “aaa” 剩下 20G 是其餘單詞,那就會形成 80G 的數據量交給一個 reduce 進行相加,其餘 20G 根據 key 不同分散到不同 reduce 進行相加的情況。如此就造成了數據傾斜,臨牀反應就是 reduce 跑到 99%然後一直在原地等着 那80G 的reduce 跑完。

說起來不好理解的話可以看下圖:


這樣就能清楚看到,數據經過 map後,由於不同key 的數據量分佈不均,在shuffle 階段中通過 partition 將相同的 key 的數據打上發往同一個 reducer 的標記,然後開始 spill (溢寫)寫入磁盤,最後merge成最終map階段輸出文件。

如此一來 80G 的 aaa 將發往同一個 reducer ,由此就可以知道 reduce 最後 1% 的工作在等什麼了。

爲什麼說數據傾斜與業務邏輯和數據量有關

從另外角度看數據傾斜,其本質還是在單臺節點在執行那一部分數據reduce任務的時候,由於數據量大,跑不動,造成任務卡住。

若是這臺節點機器內存夠大,CPU、網絡等資源充足,跑 80G 左右的數據量和跑10M 數據量所耗時間不是很大差距,那麼也就不存在問題,傾斜就傾斜吧,反正機器跑的動。

所以機器配置和數據量存在一個合理的比例,一旦數據量遠超機器的極限,那麼不管每個key的數據如何分佈,總會有一個key的數據量超出機器的能力,造成 reduce 緩慢甚至卡頓。

業務邏輯造成的數據傾斜會多很多,日常使用過程中,容易造成數據傾斜的原因可以歸納爲幾點:

容易造成數據傾斜的原因:

1) 

分組 :group by 優於distinct group

情形:group by 維度過小,某值的數量過多

後果:處理某值的reduce非常耗時

2)

去重 distinct count(distinct xx)

情形:某特殊值過多

後果:處理此特殊值的reduce耗時

3)

連接 join

情形1:其中一個表較小,但是key集中

後果1:分發到某一個或幾個Reduce上的數據遠高於平均值

情形2:大表與大表,但是0值或空值過多

後果2:這些空值都由一個reduce處理,非常慢

解決方案 : 

1)  key_隨機數

2)  key_序列

3)隨機partiton

如果遇到的數據是業務數據本身如此,不可以隨意的加隨機數。比如從事大數據工作的人數,北京 上海 深圳可能比較多。或者每年一本、二本、三本錄取人數,一本的人數肯定是要少於二本的。我們加上隨機數那麼就會更改錄取的真實情況。我們可以使用化大爲的思想。比如從事大數據業務。我們可以先將上海 北京 深圳 的數據先進行拆分然後再進行業務處理。高考業務,我們可以先將三本二本進行拆分。

如果和業務無關,那麼就直接給分區加上隨機數。

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章