0x00 前言
引用
數據傾斜是大數據領域繞不開的攔路虎，當你所需處理的數據量到達了上億甚至是千億條的時候，數據傾斜將是橫在你面前一道巨大的坎。
邁的過去，將會海闊天空！邁不過去，就要做好準備：很可能有幾周甚至幾月都要頭疼於數據傾斜導致的各類詭異的問題。
邁的過去，將會海闊天空！邁不過去，就要做好準備：很可能有幾周甚至幾月都要頭疼於數據傾斜導致的各類詭異的問題。
鄭重聲明：
- 話題比較大，技術要求也比較高，筆者盡最大的能力來寫出自己的理解，寫的不對和不好的地方大家一起交流。
- 有些例子不是特別嚴謹，一些小細節對文章理解沒有影響，不要太在意。（比如我在算機器內存的時候，就不把Hadoop自身的進程算到使用內存中）
- 總的來講個人感覺寫的還是比較乾貨的。
- 先大致解釋一下什麼是數據傾斜
- 再根據幾個場景來描述一下數據傾斜產生的情況
- 詳細分析一下在Hadoop和Spark中產生數據傾斜的原因
- 如何解決（優化）數據傾斜問題？
簡單的講，數據傾斜就是我們在計算數據的時候，數據的分散度不夠，導致大量的數據集中到了一臺或者幾臺機器上計算，這些數據的計算速度遠遠低於平均計算速度，導致整個計算過程過慢。
一、關鍵字：數據傾斜
相信大部分做數據的童鞋們都會遇到數據傾斜，數據傾斜會發生在數據開發的各個環節中，比如：
- 用Hive算數據的時候reduce階段卡在99.99%
- 用SparkStreaming做實時算法時候，一直會有executor出現OOM的錯誤，但是其餘的executor內存使用率卻很低。
例子很多，這裏先隨便舉兩個，後文會詳細的說明。
二、關鍵字：千億級
爲什麼要突出這麼大數據量？先說一下筆者自己最初對數據量的理解：
引用
數據量大就了不起了？數據量少，機器也少，計算能力也是有限的，因此難度也是一樣的。憑什麼數據量大就會有數據傾斜，數據量小就沒有？
這樣理解也有道理，但是比較片面，舉兩個場景來對比：
- 公司一：總用戶量1000萬，5臺64G內存的的服務器。
- 公司二：總用戶量10億，1000臺64G內存的服務器。
公司一的數據分時童鞋在做join的時候發生了數據傾斜，會導致有幾百萬用戶的相關數據集中到了一臺服務器上，幾百萬的用戶數據，說大也不大，正常字段量的數據的話64G還是能輕鬆處理掉的。
公司二的數據分時童鞋在做join的時候也發生了數據傾斜，可能會有1個億的用戶相關數據集中到了一臺機器上了（相信我，這很常見），這時候一臺機器就很難搞定了，最後會很難算出結果。
0x02 數據傾斜長什麼樣
筆者大部分的數據傾斜問題都解決了，而且也不想重新運行任務來截圖，下面會分幾個場景來描述一下數據傾斜的特徵，方便讀者辨別。
由於Hadoop和Spark是最常見的兩個計算平臺，下面就以這兩個平臺說明：
一、Hadoop中的數據傾斜
Hadoop中直接貼近用戶使用使用的時Mapreduce程序和Hive程序，雖說Hive最後也是用MR來執行（至少目前Hive內存計算並不普及），但是畢竟寫的內容邏輯區別很大，一個是程序，一個是Sql，因此這裏稍作區分。
Hadoop中的數據傾斜主要表現在、ruduce階段卡在99.99%，一直99.99%不能結束。
這裏如果詳細的看日誌或者和監控界面的話會發現：
- 有一個多幾個reduce卡住
- 各種container報錯OOM
- 讀寫的數據量極大，至少遠遠超過其它正常的reduce
經驗：Hive的數據傾斜，一般都發生在Sql中Group和On上，而且和數據邏輯綁定比較深。
二、Spark中的數據傾斜
Spark中的數據傾斜也很常見，這裏包括Spark Streaming和Spark Sql，表現主要有下面幾種：
- Executor lost，OOM，Shuffle過程出錯
- Driver OOM
- 單個Executor執行時間特別久，整體任務卡在某個階段不能結束
- 正常運行的任務突然失敗
0x03 數據傾斜的原理
一、數據傾斜產生的原因
我們以Spark和Hive的使用場景爲例。他們在做數據運算的時候會設計到，countdistinct、group by、join等操作，這些都會觸發Shuffle動作，一旦觸發，所有相同key的值就會拉到一個或幾個節點上，就容易發生單點問題。
二、萬惡的shuffle
Shuffle是一個能產生奇蹟的地方，不管是在Spark還是Hadoop中，它們的作用都是至關重要的。關於Shuffle的原理，這裏不再講述，看看Hadoop相關的論文或者文章理解一下就ok。這裏主要針對，在Shuffle如何產生了數據傾斜。
Hadoop和Spark在Shuffle過程中產生數據傾斜的原理基本類似。如下圖。
大部分數據傾斜的原理就類似於下圖，很明瞭，因爲數據分佈不均勻，導致大量的數據分配到了一個節點。
三、從數據角度來理解數據傾斜
我們舉一個例子，就說數據默認值的設計吧，假設我們有兩張表：
- user（用戶信息表）：userid，register_ip
- ip（IP表）：ip，register_user_cnt
兩邊其實都沒有錯的，但是一旦我們做關聯了會出現什麼情況，這個任務會在做關聯的階段，也就是sql的on的階段卡死。
四、從業務計角度來理解數據傾斜
數據往往和業務是強相關的，業務的場景直接影響到了數據的分佈。
再舉一個例子，比如就說訂單場景吧，我們在某一天在北京和上海兩個城市多了強力的推廣，結果可能是這兩個城市的訂單量增長了10000%，其餘城市的數據量不變。
然後我們要統計不同城市的訂單情況，這樣，一做group操作，可能直接就數據傾斜了。
0x04 如何解決
數據傾斜的產生是有一些討論的，解決它們也是有一些討論的，本章會先給出幾個解決數據傾斜的思路，然後對Hadoop和Spark分別給出一些解決數據傾斜的方案。
注意： 很多數據傾斜的問題，都可以用和平臺無關的方式解決，比如更好的數據預處理， 異常值的過濾等，因此筆者認爲，解決數據傾斜的重點在於對數據設計和業務的理解，這兩個搞清楚了，數據傾斜就解決了大部分了。
一、幾個思路
解決數據傾斜有這幾個思路：
- 業務邏輯，我們從業務邏輯的層面上來優化數據傾斜，比如上面的例子，我們單獨對這兩個城市來做count，最後和其它城市做整合。
- 程序層面，比如說在Hive中，經常遇到count（distinct）操作，這樣會導致最終只有一個reduce，我們可以先group 再在外面包一層count，就可以了。
- 調參方面，Hadoop和Spark都自帶了很多的參數和機制來調節數據傾斜，合理利用它們就能解決大部分問題。
很多數據傾斜都是在數據的使用上造成的。我們舉幾個場景，並分別給出它們的解決方案。
數據分佈不均勻：
前面提到的“從數據角度來理解數據傾斜”和“從業務計角度來理解數據傾斜”中的例子，其實都是數據分佈不均勻的類型，這種情況和計算平臺無關，我們能通過設計的角度嘗試解決它。
- 有損的方法： 找到異常數據，比如ip爲0的數據，過濾掉
- 無損的方法： 對分佈不均勻的數據，單獨計算
先對key做一層hash，先將數據打散讓它的並行度變大，再彙集 - 數據預處理
列出來一些方法和思路，具體的參數和用法在官網看就行了。
- map join方式
- count distinct的操作，先轉成group，再count
- 萬能膏藥：hive.groupby.skewindata=true
- left semi jioin的使用
- 設置map端輸出、中間結果壓縮。（不完全是解決數據傾斜的問題，但是減少了IO讀寫和網絡傳輸，能提高很多效率）
列出來一些方法和思路，具體的參數和用法在官網看就行了。
- mapjoin方式
- 設置rdd壓縮
- 合理設置driver的內存
- Spark Sql中的優化和Hive類似，可以參考Hive
數據傾斜的坑還是很大的，如何處理數據傾斜是一個長期的過程，希望本文的一些思路能提供幫助。
文中一些內容沒有細講，比如Hive Sql的優化，數據清洗中的各種坑，這些留待後面單獨的分享，會有很多的內容。
另外千億級別的數據還會有更多的難點，不僅僅是數據傾斜的問題，這一點在後面也會有專門的分享。
參考
- https://hive.apache.org/
- http://spark.apache.org/
- http://www.jianshu.com/p/17baa9f96ca7
- 還有網上的一些博客也提供的一些思路，不過都沒有經驗和痛帶來的感悟多。
