漫談千億級資料優化實踐：資料傾斜

阿新 • • 發佈：2019-01-25

前言

資料傾斜是大資料領域繞不開的攔路虎，當你所需處理的資料量到達了上億甚至是千億條的時候，資料傾斜將是橫在你面前一道巨大的坎。

邁的過去，將會海闊天空！邁不過去，就要做好準備：很可能有幾周甚至幾月都要頭疼於資料傾斜導致的各類詭異的問題。

鄭重宣告：

話題比較大，技術要求也比較高，筆者盡最大的能力來寫出自己的理解，寫的不對和不好的地方大家一起交流。
有些例子不是特別嚴謹，一些小細節對文章理解沒有影響，不要太在意。（比如我在算機器記憶體的時候，就不把Hadoop自身的程序算到使用記憶體中）
總的來講個人感覺寫的還是比較乾貨的。

文章結構

先大致解釋一下什麼是資料傾斜
再根據幾個場景來描述一下資料傾斜產生的情況

詳細分析一下在Hadoop和Spark中產生資料傾斜的原因
如何解決（優化）資料傾斜問題？

0x01 什麼是資料傾斜

簡單的講，資料傾斜就是我們在計算資料的時候，資料的分散度不夠，導致大量的資料集中到了一臺或者幾臺機器上計算，這些資料的計算速度遠遠低於平均計算速度，導致整個計算過程過慢。（比如按userId分表的資料，如果某些User的訪問量比較高，則出現數據傾斜）

一、關鍵字：資料傾斜

相信大部分做資料的童鞋們都會遇到資料傾斜，資料傾斜會發生在資料開發的各個環節中，比如：

用Hive算資料的時候reduce階段卡在99.99%
用SparkStreaming做實時演算法時候，一直會有executor出現OOM的錯誤，但是其餘的executor記憶體使用率卻很低。

這些問題經常會困擾我們，辛辛苦苦等了幾個小時的資料就是跑不出來，心裡多難過啊。

例子很多，這裡先隨便舉兩個，後文會詳細的說明。

二、關鍵字：千億級

為什麼要突出這麼大資料量？先說一下筆者自己最初對資料量的理解：

資料量大就了不起了？資料量少，機器也少，計算能力也是有限的，因此難度也是一樣的。憑什麼資料量大就會有資料傾斜，資料量小就沒有？

這樣理解也有道理，但是比較片面，舉兩個場景來對比：

公司一：總使用者量1000萬，5臺64G記憶體的的伺服器。
公司二：總使用者量10億，1000臺64G記憶體的伺服器。

兩個公司都部署了Hadoop叢集。假設現在遇到了資料傾斜，發生什麼？

公司一的資料分時童鞋在做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

伴隨著資料傾斜，會出現任務被kill等各種詭異的表現。

經驗：Hive的資料傾斜，一般都發生在Sql中Group和On上，而且和資料邏輯繫結比較深。

二、Spark中的資料傾斜

Spark中的資料傾斜也很常見，這裡包括Spark Streaming和Spark Sql，表現主要有下面幾種：

Executor lost，OOM，Shuffle過程出錯
Driver OOM
單個Executor執行時間特別久，整體任務卡在某個階段不能結束
正常執行的任務突然失敗

補充一下，在Spark streaming程式中，資料傾斜更容易出現，特別是在程式中包含一些類似sql的join、group這種操作的時候。因為Spark Streaming程式在執行的時候，我們一般不會分配特別多的記憶體，因此一旦在這個過程中出現一些資料傾斜，就十分容易造成OOM。

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

這可能是兩個不同的人開發的資料表，如果我們的資料規範不太完善的話，會出現一種情況，user表中的register_ip欄位，如果獲取不到這個資訊，我們預設為null，但是在ip表中，我們在統計這個值的時候，為了方便，我們把獲取不到ip的使用者，統一認為他們的ip為0。

兩邊其實都沒有錯的，但是一旦我們做關聯了會出現什麼情況，這個任務會在做關聯的階段，也就是sql的on的階段卡死。

四、從業務計角度來理解資料傾斜

資料往往和業務是強相關的，業務的場景直接影響到了資料的分佈。

再舉一個例子，比如就說訂單場景吧，我們在某一天在北京和上海兩個城市多了強力的推廣，結果可能是這兩個城市的訂單量增長了10000%，其餘城市的資料量不變。

然後我們要統計不同城市的訂單情況，這樣，一做group操作，可能直接就資料傾斜了。

0x04 如何解決

資料傾斜的產生是有一些討論的，解決它們也是有一些討論的，本章會先給出幾個解決資料傾斜的思路，然後對Hadoop和Spark分別給出一些解決資料傾斜的方案。

注意：很多資料傾斜的問題，都可以用和平臺無關的方式解決，比如更好的資料預處理，異常值的過濾等，因此筆者認為，解決資料傾斜的重點在於對資料設計和業務的理解，這兩個搞清楚了，資料傾斜就解決了大部分了。

一、幾個思路

解決資料傾斜有這幾個思路：

業務邏輯，我們從業務邏輯的層面上來優化資料傾斜，比如上面的例子，我們單獨對這兩個城市來做count，最後和其它城市做整合。
程式層面，比如說在Hive中，經常遇到count（distinct）操作，這樣會導致最終只有一個reduce，我們可以先group 再在外面包一層count，就可以了。
調參方面，Hadoop和Spark都自帶了很多的引數和機制來調節資料傾斜，合理利用它們就能解決大部分問題。

二、從業務和資料上解決資料傾斜

很多資料傾斜都是在資料的使用上造成的。我們舉幾個場景，並分別給出它們的解決方案。

資料分佈不均勻：

前面提到的“從資料角度來理解資料傾斜”和“從業務計角度來理解資料傾斜”中的例子，其實都是資料分佈不均勻的型別，這種情況和計算平臺無關，我們能通過設計的角度嘗試解決它。

有損的方法：
- 找到異常資料，比如ip為0的資料，過濾掉
無損的方法：
- 對分佈不均勻的資料，單獨計算
- 先對key做一層hash，先將資料打散讓它的並行度變大，再彙集
資料預處理

三、Hadoop平臺的優化方法

列出來一些方法和思路，具體的引數和用法在官網看就行了。

mapjoin方式
count distinct的操作，先轉成group，再count
萬能膏藥：hive.groupby.skewindata=true
left semi jioin的使用
設定map端輸出、中間結果壓縮。（不完全是解決資料傾斜的問題，但是減少了IO讀寫和網路傳輸，能提高很多效率）

四、Spark平臺的優化方法