0x00 前言

數(shù)據(jù)傾斜是大數(shù)據(jù)領(lǐng)域繞不開的攔路虎，當(dāng)你所需處理的數(shù)據(jù)量到達(dá)了上億甚至是千億條的時候，數(shù)據(jù)傾斜將是橫在你面前一道巨大的坎。

邁的過去，將會海闊天空!邁不過去，就要做好準(zhǔn)備：很可能有幾周甚至幾月都要頭疼于數(shù)據(jù)傾斜導(dǎo)致的各類詭異的問題。

[[209098]]

文章結(jié)構(gòu)

• 先大致解釋一下什么是數(shù)據(jù)傾斜
• 再根據(jù)幾個場景來描述一下數(shù)據(jù)傾斜產(chǎn)生的情況
• 詳細(xì)分析一下在Hadoop和Spark中產(chǎn)生數(shù)據(jù)傾斜的原因
• 如何解決(優(yōu)化)數(shù)據(jù)傾斜問題?

0x01 什么是數(shù)據(jù)傾斜

簡單的講，數(shù)據(jù)傾斜就是我們在計算數(shù)據(jù)的時候，數(shù)據(jù)的分散度不夠，導(dǎo)致大量的數(shù)據(jù)集中到了一臺或者幾臺機(jī)器上計算，這些數(shù)據(jù)的計算速度遠(yuǎn)遠(yuǎn)低于平均計算速度，導(dǎo)致整個計算過程過慢。

一、關(guān)鍵字：數(shù)據(jù)傾斜

相信大部分做數(shù)據(jù)的童鞋們都會遇到數(shù)據(jù)傾斜，數(shù)據(jù)傾斜會發(fā)生在數(shù)據(jù)開發(fā)的各個環(huán)節(jié)中，比如：

• 用 Hive 算數(shù)據(jù)的時候 reduce 階段卡在 99.99%
• 用 Spark Streaming 做實時算法時候，一直會有 executor 出現(xiàn) OOM 的錯誤，但是其余的 executor 內(nèi)存使用率卻很低。

這些問題經(jīng)常會困擾我們，辛辛苦苦等了幾個小時的數(shù)據(jù)就是跑不出來，心里多難過啊。

例子很多，這里先隨便舉兩個，后文會詳細(xì)的說明。

二、關(guān)鍵字：千億級

為什么要突出這么大數(shù)據(jù)量?先說一下筆者自己最初對數(shù)據(jù)量的理解：

數(shù)據(jù)量大就了不起了?數(shù)據(jù)量少，機(jī)器也少，計算能力也是有限的，因此難度也是一樣的。憑什么數(shù)據(jù)量大就會有數(shù)據(jù)傾斜，數(shù)據(jù)量小就沒有?

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

• 公司一：總用戶量 1000 萬，5 臺 64G 內(nèi)存的的服務(wù)器。
• 公司二：總用戶量 10 億，1000 臺 64G 內(nèi)存的服務(wù)器。

兩個公司都部署了 Hadoop 集群。假設(shè)現(xiàn)在遇到了數(shù)據(jù)傾斜，發(fā)生什么?

公司一的數(shù)據(jù)分時童鞋在做 join 的時候發(fā)生了數(shù)據(jù)傾斜，會導(dǎo)致有幾百萬用戶的相關(guān)數(shù)據(jù)集中到了一臺服務(wù)器上，幾百萬的用戶數(shù)據(jù)，說大也不大，正常字段量的數(shù)據(jù)的話 64G 還是能輕松處理掉的。

公司二的數(shù)據(jù)分時童鞋在做 join的時候也發(fā)生了數(shù)據(jù)傾斜，可能會有 1 億的用戶相關(guān)數(shù)據(jù)集中到了一臺機(jī)器上了(相信我，這很常見)，這時候一臺機(jī)器就很難搞定了，***會很難算出結(jié)果。

0x02 數(shù)據(jù)傾斜長什么樣

工作中遇到的大部分的數(shù)據(jù)傾斜問題都解決了，而且也不想重新運(yùn)行任務(wù)來截圖，下面會分幾個場景來描述一下數(shù)據(jù)傾斜的特征，方便讀者辨別。

由于 Hadoop 和 Spark 是最常見的兩個計算平臺，下面就以這兩個平臺說明：

一、Hadoop中的數(shù)據(jù)傾斜

Hadoop 中最常用的是的是 Mapreduce 和 Hive ，雖說 Hive ***也是用 MR 來執(zhí)行(至少目前Hive內(nèi)存計算并不普及)，但是畢竟寫的內(nèi)容邏輯區(qū)別很大，一個是程序，一個是 Sql，因此這里稍作區(qū)分。

Hadoop中的數(shù)據(jù)傾斜主要表現(xiàn)在、ruduce 階段卡在 99.99%，一直 99.99% 不能結(jié)束。

這里如果詳細(xì)的看日志或者和監(jiān)控界面的話會發(fā)現(xiàn)：

1. 有一個多幾個 reduce 卡住
2. 各種 container 報錯 OOM
3. 讀寫的數(shù)據(jù)量極大，至少遠(yuǎn)遠(yuǎn)超過其它正常的 reduce
4. 伴隨著數(shù)據(jù)傾斜，會出現(xiàn)任務(wù)被 kill 等各種詭異的表現(xiàn)。

經(jīng)驗：Hive 的數(shù)據(jù)傾斜，一般都發(fā)生在 Sql 中 Group 和 On 上，而且和數(shù)據(jù)邏輯綁定比較深。

二、Spark 中的數(shù)據(jù)傾斜

Spark 中的數(shù)據(jù)傾斜也很常見，這里包括Spark Streaming 和 Spark Sql，表現(xiàn)主要有下面幾種：

1. Executor lost，OOM，Shuffle過程出錯
2. Driver OOM
3. 單個 executor 執(zhí)行時間特別久，整體任務(wù)卡在某個階段不能結(jié)束
4. 正常運(yùn)行的任務(wù)突然失敗

補(bǔ)充一下，在 Spark streaming 程序中，數(shù)據(jù)傾斜更容易出現(xiàn)，特別是在程序中包含一些類似 Sql 的 join、group 這種操作的時候。 因為 Spark Streaming 程序在運(yùn)行的時候，我們一般不會分配特別多的內(nèi)存，因此一旦在這個過程中出現(xiàn)一些數(shù)據(jù)傾斜，就十分容易造成 OOM。

0x03 數(shù)據(jù)傾斜的原理

一、數(shù)據(jù)傾斜產(chǎn)生的原因

我們以 Spark 和 Hive 的使用場景為例。他們在做數(shù)據(jù)運(yùn)算的時候會涉及到，count distinct、group by、join 等操作，這些都會觸發(fā) Shuffle 動作，一旦觸發(fā)，所有相同 key 的值就會拉到一個或幾個節(jié)點上，就容易發(fā)生單點問題。

二、萬惡的 Shuffle

Shuffle 是一個能產(chǎn)生奇跡的地方，不管是在 Spark 還是 Hadoop 中，它們的作用都是至關(guān)重要的。關(guān)于 Shuffle 的原理，這里不再講述，看看 Hadoop 相關(guān)的論文或者文章理解一下就 ok。這里主要針對在 Shuffle 如何產(chǎn)生了數(shù)據(jù)傾斜。

Hadoop 和 Spark 在 Shuffle 過程中產(chǎn)生數(shù)據(jù)傾斜的原理基本類似。

大部分?jǐn)?shù)據(jù)傾斜的原理就類似于下圖，很明了，因為數(shù)據(jù)分布不均勻，導(dǎo)致大量的數(shù)據(jù)分配到了一個節(jié)點。

三、從數(shù)據(jù)角度來理解數(shù)據(jù)傾斜

我們舉一個例子，就說數(shù)據(jù)默認(rèn)值的設(shè)計吧，假設(shè)我們有兩張表：

• user(用戶信息表)：userid，register_ip
• ip(IP表)：ip，register_user_cnt

這可能是兩個不同的人開發(fā)的數(shù)據(jù)表，如果我們的數(shù)據(jù)規(guī)范不太完善的話，會出現(xiàn)一種情況，user 表中的 register_ip 字段，如果獲取不到這個信息，我們默認(rèn)為 null，但是在 ip 表中，我們在統(tǒng)計這個值的時候，為了方便，我們把獲取不到 ip 的用戶，統(tǒng)一認(rèn)為他們的 ip 為 0。

兩邊其實都沒有錯的，但是一旦我們做關(guān)聯(lián)了會出現(xiàn)什么情況，這個任務(wù)會在做關(guān)聯(lián)的階段，也就是sql的on的階段卡死。

四、從業(yè)務(wù)計角度來理解數(shù)據(jù)傾斜

數(shù)據(jù)往往和業(yè)務(wù)是強(qiáng)相關(guān)的，業(yè)務(wù)的場景直接影響到了數(shù)據(jù)的分布。

再舉一個例子，比如就說訂單場景吧，我們在某一天在北京和上海兩個城市多了強(qiáng)力的推廣，結(jié)果可能是這兩個城市的訂單量增長了10000%，其余城市的數(shù)據(jù)量不變。

然后我們要統(tǒng)計不同城市的訂單情況，這樣，一做 group 操作，可能直接就數(shù)據(jù)傾斜了。

0x04 如何解決

數(shù)據(jù)傾斜的產(chǎn)生是有一些討論的，解決它們也是有一些討論的，本章會先給出幾個解決數(shù)據(jù)傾斜的思路，然后對 Hadoop 和 Spark 分別給出一些解決數(shù)據(jù)傾斜的方案。

注意： 很多數(shù)據(jù)傾斜的問題，都可以用和平臺無關(guān)的方式解決，比如更好的數(shù)據(jù)預(yù)處理， 異常值的過濾等，因此筆者認(rèn)為，解決數(shù)據(jù)傾斜的重點在于對數(shù)據(jù)設(shè)計和業(yè)務(wù)的理解，這兩個搞清楚了，數(shù)據(jù)傾斜就解決了大部分了。

一、幾個思路

解決數(shù)據(jù)傾斜有這幾個思路：

1. 業(yè)務(wù)邏輯，我們從業(yè)務(wù)邏輯的層面上來優(yōu)化數(shù)據(jù)傾斜，比如上面的例子，我們單獨對這兩個城市來做 count，***和其它城市做整合。
2. 程序?qū)用妫热缯f在 Hive 中，經(jīng)常遇到count(distinct)操作，這樣會導(dǎo)致最終只有一個 reduce，我們可以先 group 再在外面包一層 count，就可以了。
3. 調(diào)參方面，Hadoop 和 Spark 都自帶了很多的參數(shù)和機(jī)制來調(diào)節(jié)數(shù)據(jù)傾斜，合理利用它們就能解決大部分問題。

二、從業(yè)務(wù)和數(shù)據(jù)上解決數(shù)據(jù)傾斜

很多數(shù)據(jù)傾斜都是在數(shù)據(jù)的使用上造成的。我們舉幾個場景，并分別給出它們的解決方案。

數(shù)據(jù)分布不均勻：

• 前面提到的“從數(shù)據(jù)角度來理解數(shù)據(jù)傾斜”和“從業(yè)務(wù)計角度來理解數(shù)據(jù)傾斜”中的例子，其實都是數(shù)據(jù)分布不均勻的類型，這種情況和計算平臺無關(guān)，我們能通過設(shè)計的角度嘗試解決它。

有損的方法：

• 找到異常數(shù)據(jù)，比如 ip 為 0 的數(shù)據(jù)，過濾掉

無損的方法：

• 對分布不均勻的數(shù)據(jù)，單獨計算
• 先對 key 做一層 hash，先將數(shù)據(jù)打散讓它的并行度變大，再匯集

數(shù)據(jù)預(yù)處理

三、Hadoop平臺的優(yōu)化方法

列出來一些方法和思路，具體的參數(shù)和用法在官網(wǎng)看就行了。

1. map join 方式
2. count distinct 的操作，先轉(zhuǎn)成 group，再 count
3. ***膏藥：hive.groupby.skewindata=true
4. left semi join的使用
5. 設(shè)置 map 端輸出、中間結(jié)果壓縮。(不完全是解決數(shù)據(jù)傾斜的問題，但是減少了 IO 讀寫和網(wǎng)絡(luò)傳輸，能提高很多效率)

四、Spark平臺的優(yōu)化方法

列出來一些方法和思路，具體的參數(shù)和用法在官網(wǎng)看就行了。

1. mapjoin 方式
2. 設(shè)置 rdd 壓縮
3. 合理設(shè)置 driver 的內(nèi)存
4. Spark Sql 中的優(yōu)化和 Hive 類似，可以參考Hive

0xFF 總結(jié)

數(shù)據(jù)傾斜的坑還是很大的，如何處理數(shù)據(jù)傾斜是一個長期的過程，希望本文的一些思路能提供幫助。

文中一些內(nèi)容沒有細(xì)講，比如 Hive Sql 的優(yōu)化，數(shù)據(jù)清洗中的各種坑，這些留待后面單獨的分享，會有很多的內(nèi)容。

另外千億級別的數(shù)據(jù)還會有更多的難點，不僅僅是數(shù)據(jù)傾斜的問題，這一點在后面也會有專門的分享。