資料傾斜是大資料領域繞不開的攔路虎，當你所需處理的資料量到達了上億甚至是千億條的時候，資料傾斜將是橫在你面前一道巨大的坎。鄭重宣告：先大致解釋一下什麼是資料傾斜邁的過去，將會海闊天空！邁不過去，就要做好準備：很可能有幾周甚至幾月都要頭疼於資料傾斜導致的各類詭異的問題。
再根據幾個場景來描述一下資料傾斜產生的情況
詳細分析一下在hadoop和spark中產生資料傾斜的原因
如何解決（優化）資料傾斜問題？
簡單的講，資料傾斜就是我們在計算資料的時候，資料的分散度不夠，導致大量的資料集中到了一台或者幾台機器上計算，這些資料的計算速度遠遠低於平均計算速度，導致整個計算過程過慢。相信大部分做資料的童鞋們都會遇到資料傾斜，資料傾斜會發生在資料開發的各個環節中，比如：
這些問題經常會困擾我們，辛辛苦苦等了幾個小時的資料就是跑不出來，心裡多難過啊。
例子很多，這裡先隨便舉兩個，後文會詳細的說明。
為什麼要突出這麼大資料量？先說一下筆者自己最初對資料量的理解：
資料量大就了不起了？資料量少，機器也少，計算能力也是有限的，因此難度也是一樣的。憑什麼資料量大就會有資料傾斜，資料量小就沒有？這樣理解也有道理，但是比較片面，舉兩個場景來對比：
兩個公司都部署了hadoop集群。假設現在遇到了資料傾斜，發生什麼？
公司一的資料分時童鞋在做join的時候發生了資料傾斜，會導致有幾百萬使用者的相關資料集中到了一台伺服器上，幾百萬的使用者資料，說大也不大，正常字段量的資料的話64g還是能輕鬆處理掉的。
公司二的資料分時童鞋在做join的時候也發生了資料傾斜，可能會有1個億的使用者相關資料集中到了一台機器上了（相信我，這很常見），這時候一台機器就很難搞定了，最後會很難算出結果。
筆者大部分的資料傾斜問題都解決了，而且也不想重新執行任務來截圖，下面會分幾個場景來描述一下資料傾斜的特徵，方便讀者辨別。
由於hadoop和spark是最常見的兩個計算平台，下面就以這兩個平台說明：
hadoop中直接貼近使用者使用使用的時mapreduce程式和hive程式，雖說hive最後也是用mr來執行（至少目前hive記憶體計算並不普及），但是畢竟寫的內容邏輯區別很大，乙個是程式，乙個是sql，因此這裡稍作區分。
hadoop中的資料傾斜主要表現在、ruduce階段卡在99.99%，一直99.99%不能結束。
這裡如果詳細的看日誌或者和監控介面的話會發現：
伴隨著資料傾斜，會出現任務被kill等各種詭異的表現。
經驗：hive的資料傾斜，一般都發生在sql中group和on上，而且和資料邏輯繫結比較深。
spark中的資料傾斜也很常見，這裡包括spark streaming和spark sql，表現主要有下面幾種：
補充一下，在spark streaming程式中，資料傾斜更容易出現，特別是在程式中包含一些類似sql的join、group這種操作的時候。 因為spark streaming程式在執行的時候，我們一般不會分配特別多的記憶體，因此一旦在這個過程中出現一些資料傾斜，就十分容易造成oom。
我們以spark和hive的使用場景為例。他們在做資料運算的時候會設計到，countdistinct、group by、join等操作，這些都會觸發shuffle動作，一旦觸發，所有相同key的值就會拉到乙個或幾個節點上，就容易發生單點問題。
shuffle是乙個能產生奇蹟的地方，不管是在spark還是hadoop中，它們的作用都是至關重要的。關於shuffle的原理，這裡不再講述，看看hadoop相關的**或者文章理解一下就ok。這裡主要針對，在shuffle如何產生了資料傾斜。
hadoop和spark在shuffle過程中產生資料傾斜的原理基本類似。如下圖。
大部分資料傾斜的原理就類似於下圖，很明了，因為資料分布不均勻，導致大量的資料分配到了乙個節點。
我們舉乙個例子，就說資料預設值的設計吧，假設我們有兩張表：
這可能是兩個不同的人開發的資料表，如果我們的資料規範不太完善的話，會出現一種情況，user表中的register_ip欄位，如果獲取不到這個資訊，我們預設為null，但是在ip表中，我們在統計這個值的時候，為了方便，我們把獲取不到ip的使用者，統一認為他們的ip為0。
兩邊其實都沒有錯的，但是一旦我們做關聯了會出現什麼情況，這個任務會在做關聯的階段，也就是sql的on的階段卡死。
資料往往和業務是強相關的，業務的場景直接影響到了資料的分布。
再舉乙個例子，比如就說訂單場景吧，我們在某一天在北京和上海兩個城市多了強力的推廣，結果可能是這兩個城市的訂單量增長了10000%，其餘城市的資料量不變。
然後我們要統計不同城市的訂單情況，這樣，一做group操作，可能直接就資料傾斜了。
資料傾斜的產生是有一些討論的，解決它們也是有一些討論的，本章會先給出幾個解決資料傾斜的思路，然後對hadoop和spark分別給出一些解決資料傾斜的方案。
注意：很多資料傾斜的問題，都可以用和平台無關的方式解決，比如更好的資料預處理， 異常值的過濾等，因此筆者認為，解決資料傾斜的重點在於對資料設計和業務的理解，這兩個搞清楚了，資料傾斜就解決了大部分了。
解決資料傾斜有這幾個思路：
業務邏輯，我們從業務邏輯的層面上來優化資料傾斜，比如上面的例子，我們單獨對這兩個城市來做count，最後和其它城市做整合。
程式層面，比如說在hive中，經常遇到count（distinct）操作，這樣會導致最終只有乙個reduce，我們可以先group 再在外麵包一層count，就可以了。
調參方面，hadoop和spark都自帶了很多的引數和機制來調節資料傾斜，合理利用它們就能解決大部分問題。
很多資料傾斜都是在資料的使用上造成的。我們舉幾個場景，並分別給出它們的解決方案。
資料分布不均勻：
前面提到的「從資料角度來理解資料傾斜」和「從業務計角度來理解資料傾斜」中的例子，其實都是資料分布不均勻的型別，這種情況和計算平台無關，我們能通過設計的角度嘗試解決它。
無損的方法：
資料預處理
列出來一些方法和思路，具體的引數和用法在官網看就行了。
mapjoin方式
count distinct的操作，先轉成group，再count
萬能膏藥：hive.groupby.skewindata=true
left semi jioin的使用
設定map端輸出、中間結果壓縮。（不完全是解決資料傾斜的問題，但是減少了io讀寫和網路傳輸，能提高很多效率）
列出來一些方法和思路，具體的引數和用法在官網看就行了。
mapjoin方式
設定rdd壓縮
合理設定driver的記憶體
spark sql中的優化和hive類似，可以參考hive
文中一些內容沒有細講，比如hive sql的優化，資料清洗中的各種坑，這些留待後面單獨的分享，會有很多的內容。
另外千億級別的資料還會有更多的難點，不僅僅是資料傾斜的問題，這一點在後面也會有專門的分享。
個人主頁：
漫談千億級資料優化實踐 資料傾斜（純乾貨）
資料傾斜是大資料領域繞不開的攔路虎，當你所需處理的資料量到達了上億甚至是千億條的時候，資料傾斜將是橫在你面前一道巨大的坎。邁的過去，將會海闊天空！邁不過去，就要做好準備 很可能有幾周甚至幾月都要頭疼於資料傾斜導致的各類詭異的問題。鄭重宣告 先大致解釋一下什麼是資料傾斜 再根據幾個場景來描述一下資料傾...
資料傾斜優化
資料傾斜 在分布式程式分配任務的時候，任務分配的不平均。資料傾斜，在企業開發中是經常遇到的，以及是非常影響效能的一種場景。資料傾斜一旦發生，橫向拓展只能緩解這個情況，而不能解決這個情況。如果遇到資料傾斜，一定要從根本上去解決這個問題。而不是想著加機器來解決。方案一用前面講過的map join smb...
mr資料傾斜優化
資料傾斜是資料中的常見情況。資料中不可避免地會出現離群值 outlier 並導致資料傾斜。這些離群值會顯著地拖慢mapreduce的執行。常見的資料傾斜有以下幾類 資料頻率傾斜 某乙個區域的資料量要遠遠大於其他區域。資料大小傾斜 部分記錄的大小遠遠大於平均值。在map端和reduce端都有可能發生資...