1. 程式人生 > >Hadoop數據傾斜及解決辦法

Hadoop數據傾斜及解決辦法

spa 調優 大量 art 很慢 shu 有一種 繼承 cal

數據傾斜:就是大量的相同key被partition分配到一個分區裏,map /reduce程序執行時,reduce節點大部分執行完畢,但是有一個或者幾個reduce節點運行很慢,導致整個程序的處理時間很長,

這是因為某一個key的條數比其他key多很多(有時是百倍或者千倍之多),這條key所在的reduce節點所處理的數據量比其他節點就大很多,從而導致某幾個節點遲遲運行不完。

解決方案:

1.增加jvm內存,這適用於第一種情況(唯一值非常少,極少數值有非常多的記錄值(唯一值少於幾千)),這種情況下,往往只能通過硬件的手段來進行調優,增加jvm內存可以顯著的提高運行效率。

2.增加reduce的個數,這適用於第二種情況(唯一值比較多,這個字段的某些值有遠遠多於其他值的記錄數,但是它的占比也小於百分之一或千分之一),我們知道,這種情況下,

  最容易造成的結果就是大量相同key被partition到一個分區,從而一個reduce執行了大量的工作,而如果我們增加了reduce的個數,這種情況相對來說會減輕很多,畢竟計算的節點多了,就算工作量還是不均勻的,那也要小很多。

3.自定義分區,這需要用戶自己繼承partition類,指定分區策略,這種方式效果比較顯著。

4.重新設計key,有一種方案是在map階段時給key加上一個隨機數,有了隨機數的key就不會被大量的分配到同一節點(小幾率),待到reduce後再把隨機數去掉即可。

5.使用combinner合並,combinner是在map階段,reduce之前的一個中間階段,在這個階段可以選擇性的把大量的相同key數據先進行一個合並,可以看做是local reduce,然後再交給reduce來處理,

  這樣做的好處很多,即減輕了map端向reduce端發送的數據量(減輕了網絡帶寬),也減輕了map端和reduce端中間的shuffle階段的數據拉取數量(本地化磁盤IO速率),推薦使用這種方法。

Hadoop數據傾斜及解決辦法