數據傾斜
數據傾斜是我們在處理大數據量問題時繞不過去的問題，也是在面試中幾乎必問的考點。
正常的數據分佈理論上都是傾斜的，就是我們所說的'二八原理'：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設置
- 並行度設置
其他更多的是在業務上的key設計來避免。
如何處理數據傾斜是一個長期的過程，希望本文的一些思路能提供幫助。
聲明：本號所有文章除特殊註明，都爲原創，公衆號讀者擁有優先閱讀權，未經作者本人允許不得轉載，否則追究侵權責任。
關注我的公衆號，後臺回覆【JAVAPDF】獲取200頁面試題！
5萬人關注的大數據成神之路，不來了解一下嗎？
5萬人關注的大數據成神之路，真的不來了解一下嗎？
5萬人關注的大數據成神之路，確定真的不來了解一下嗎？
