1.數據傾斜的表現
1.1.Hadoop數據傾斜:
Hadoop中的數據傾斜主要表現在、ruduce階段卡在99.99%，一直99.99%不能結束。
這裡如果詳細的看日誌或者和監控界面的話會發現：
有一個多幾個reduce卡住
各種container報錯OOM
讀寫的數據量極大，至少遠遠超過其它正常的reduce
伴隨著數據傾斜，會出現任務被kill等各種詭異的表現。
經驗：Hive的數據傾斜，一般都發生在Sql中Group和On上，而且和數據邏輯綁定比較深。
1.2.Spark中的數據傾斜：
Spark中的數據傾斜也很常見，這裡包括Spark Streaming和Spark Sql，表現主要有下面幾種：
Executor lost，OOM，Shuffle過程出錯
Driver OOM
單個Executor執行時間特別久，整體任務卡在某個階段不能結束
正常運行的任務突然失敗
補充一下，在Spark streaming程序中，數據傾斜更容易出現，特別是在程序中包含一些類似sql的join、group這種操作的時候。 因為Spark Streaming程序在運行的時候，我們一般不會分配特別多的內存，因此一旦在這個過程中出現一些數據傾斜，就十分容易造成OOM。
2.數據傾斜原因
在做數據運算的時候會設計到，countdistinct、group by、join等操作，這些都會觸發Shuffle動作，一旦觸發，所有相同key的值就會拉到一個或幾個節點上，就容易發生單點問題。
3.解決數據傾斜
3.1.解決數據傾斜有這幾個思路：
業務邏輯，我們從業務邏輯的層面上來優化數據傾斜，比如上面的例子，我們單獨對這兩個城市來做count，最後和其它城市做整合。
程序層面，比如說在Hive中，經常遇到count（distinct）操作，這樣會導致最終只有一個reduce，我們可以先group 再在外面包一層count，就可以了。
調參方面，Hadoop和Spark都自帶了很多的參數和機制來調節數據傾斜，合理利用它們就能解決大部分問題。
3.2.從業務和數據上解決數據傾斜
很多數據傾斜都是在數據的使用上造成的。我們舉幾個場景，並分別給出它們的解決方案。
數據分佈不均勻：
前面提到的“從數據角度來理解數據傾斜”和“從業務計角度來理解數據傾斜”中的例子，其實都是數據分佈不均勻的類型，這種情況和計算平臺無關，我們能通過設計的角度嘗試解決它。
有損的方法：
找到異常數據，比如ip為0的數據，過濾掉
無損的方法：
對分佈不均勻的數據，單獨計算
先對key做一層hash，先將數據打散讓它的並行度變大，再彙集
數據預處理
3.3.Hadoop平臺的優化方法
列出來一些方法和思路，具體的參數和用法在官網看就行了。
map join方式
count distinct的操作，先轉成group，再count
萬能膏藥：hive.groupby.skewindata=true （這個變量是用於控制負載均衡的。當數據出現傾斜時，如果該變量設置為true，那麼Hive會自動進行負載均衡。）
left semi jioin的使用
設置map端輸出、中間結果壓縮。（不完全是解決數據傾斜的問題，但是減少了IO讀寫和網絡傳輸，能提高很多效率）
3.4.Spark平臺的優化方法
mapjoin方式:
把小數據broadcast，大數據集進行filter看是否包含是在小數據集中。
key打散的方式：
把key後面拼接隨機數字。
合理設置driver的內存
Spark Sql中的優化和Hive類似，可以參考Hive
閱讀更多 從大數據說起 的文章
