這個面試問題很難麼 | 如何處理大資料中的資料傾斜

資料傾斜

資料傾斜是我們在處理大資料量問題時繞不過去的問題，也是在面試中幾乎必問的考點。 正常的資料分布理論上都是傾斜的，就是我們所說的'二八原理'：80%的财富集中在20%的人手中, 80%的使用者隻使用20%的功能 , 20%的使用者貢獻了80%的通路量。 簡單來說資料傾斜就是資料的key 的分化嚴重不均，造成一部分資料很多，一部分資料很少的局面。

表現

相信大部分做資料的童鞋們都會遇到資料傾斜，資料傾斜會發生在資料開發的各個環節中，比如： 用Hive算資料的時候reduce階段卡在99.99% 用SparkStreaming做實時算法時候，一直會有executor出現OOM的錯誤，但是其餘的executor記憶體使用率卻很低。

Hadoop

當我們看任務進度長時間維持在99%，這裡如果詳細的看日志或者和監控界面的話會發現：

• 有一個多幾個reduce卡住
• 各種container報錯OOM
• 讀寫的資料量極大，至少遠遠超過其它正常的reduce
• 伴随着資料傾斜，會出現任務被kill等各種詭異的表現

Spark

Spark中的資料傾斜也很常見，Spark中一個 stage 的執行時間受限于最後那個執行完的 task，是以運作緩慢的任務會拖累整個程式的運作速度。過多的資料在同一個task中執行，将會把executor撐爆，造成OOM，程式終止運作。

Flink

使用Window、GroupBy、Distinct等聚合函數時，頻繁出現反壓，消費速度很慢，個别的task會出現OOM，調大資源也無濟于事。

資料傾斜原理和解決方案

在做資料運算的時候會設計到，countdistinct、group by、join等操作，都會觸發Shuffle動作。一旦觸發，所有相同 key 的值就會拉到一個或幾個節點上，發生單點問題。

一個簡單的場景，在訂單表中，北京和上海兩個地區的訂單數量比其他地區高幾個數量級。那麼進行聚合的時候就會出現資料熱點。

解決資料傾斜的幾個思路：

• 業務上：避免熱點key的設計或者打散熱點key，例如可以把北京和上海分成地區，然後單獨彙總。
• 技術上：在熱點出現時，需要調整方案避免直接進行聚合，可以借助架構本身的能力，例如進行mapside-join。
• 參數上：無論是Hadoop、Spark還是Flink都提供了大量的參數可以調整。

Hadoop/Hive參數

• mapside-join
• 對于group by或distinct，設定 hive.groupby.skewindata=true
• 合并小檔案
• 壓縮檔案

Spark 參數

• 使用map join 代替reduce join
• 提高shuffle并行度

Flink 參數

• MiniBatch設定
• 并行度設定