大資料中的資料傾斜

文章結構

再根據幾個場景來描述一下資料傾斜產生的情況

詳細分析一下在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的優化，資料清洗中的各種坑，這些留待後面單獨的分享，會有很多的內容。

另外千億級別的資料還會有更多的難點，不僅僅是資料傾斜的問題，這一點在後面也會有專門的分享。

大資料開發中的資料傾斜

什麼是資料傾斜 由於資料分布不均勻，造成資料大量的集中到一點，造成資料熱點 資料傾斜的表現 任務進度長時間維持在 99 或者 100 的附近，檢視任務監控頁面，發現只有少量 reduce 子任務未完成，因為其處理的資料量和其他的 reduce 差異過大。單一 reduce 處理的記錄數和平均記錄數相...

大資料學習 資料傾斜

2017 10 23 細柳條小秀才翻譯鋪 前言 資料傾斜是日常大資料查詢中 的乙個bug，遇不到它時你覺得資料傾斜也就是書本部落格上的乙個無病呻吟的偶然案例，但當你遇到它是你就會懊悔當初怎麼不多了解一下這個赫赫有名的事故。當然你和資料傾斜的緣分深淺還是看你公司的業務邏輯和資料量有沒有步入資料傾斜的領...

大資料 「資料傾斜」的問題

解決資料傾斜的辦法，前輩已經寫得非常完整了，我這裡就直接搬磚吧 建議先看這個鏈結文章，非常好 下面是自己的總結 什麼是資料傾斜？見下圖 簡單來說資料傾斜就是資料的key 的分化嚴重不均，造成一部分資料很多，一部分資料很少的局面。舉個 word count 的入門例子 它的map 階段就是形成 aaa...