什么是數(shù)據(jù)傾斜
簡單的講，數(shù)據(jù)傾斜就是我們在計算數(shù)據(jù)的時候，數(shù)據(jù)的分散度不夠，導(dǎo)致大量的數(shù)據(jù)集中到了一臺或者幾臺機(jī)器上計算，這些數(shù)據(jù)的計算速度遠(yuǎn)遠(yuǎn)低于平均計算速度，導(dǎo)致整個計算過程過慢。
1、關(guān)鍵字：數(shù)據(jù)傾斜
相信大部分做數(shù)據(jù)的童鞋們都會遇到數(shù)據(jù)傾斜，數(shù)據(jù)傾斜會發(fā)生在數(shù)據(jù)開發(fā)的各個環(huán)節(jié)中，比如：用 Hive 算數(shù)據(jù)的時候 reduce 階段卡在 99.99%用 SparkStreaming 做實(shí)時算法時候，一直會有 executor 出現(xiàn) OOM 的錯誤，但是其余的 executor 內(nèi)存使用率卻很低。
這些問題經(jīng)常會困擾我們，辛辛苦苦等了幾個小時的數(shù)據(jù)就是跑不出來，心里多難過啊。
例子很多，這里先隨便舉兩個，后文會詳細(xì)的說明。
2、關(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é)果。
數(shù)據(jù)傾斜長什么樣
筆者大部分的數(shù)據(jù)傾斜問題都解決了，而且也不想重新運(yùn)行任務(wù)來截圖，下面會分幾個場景來描述一下數(shù)據(jù)傾斜的特征，方便讀者辨別。
由于Hadoop和Spark是最常見的兩個計算平臺，下面就以這兩個平臺說明：
1、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)：有一個多幾個 reduce 卡住各種 container 報錯 OOM讀寫的數(shù)據(jù)量極大，至少遠(yuǎn)遠(yuǎn)超過其它正常的 reduce
伴隨著數(shù)據(jù)傾斜，會出現(xiàn)任務(wù)被 kill 等各種詭異的表現(xiàn)。
經(jīng)驗(yàn)：Hive 的數(shù)據(jù)傾斜，一般都發(fā)生在 Sql 中 Group 和 On上，而且和數(shù)據(jù)邏輯綁定比較深。
2、Spark中的數(shù)據(jù)傾斜
Spark 中的數(shù)據(jù)傾斜也很常見，這里包括 Spark Streaming和 Spark Sql，表現(xiàn)主要有下面幾種：Executor lost，OOM，Shuffle 過程出錯Driver OOM單個 Executor 執(zhí)行時間特別久，整體任務(wù)卡在某個階段不能結(jié)束正常運(yùn)行的任務(wù)突然失敗
補(bǔ)充一下，在 Spark streaming 程序中，數(shù)據(jù)傾斜更容易出現(xiàn)，特別是在程序中包含一些類似 sql 的 join、group 這種操作的時候。 因?yàn)?Spark Streaming 程序在運(yùn)行的時候，我們一般不會分配特別多的內(nèi)存，因此一旦在這個過程中出現(xiàn)一些數(shù)據(jù)傾斜，就十分容易造成 OOM.
數(shù)據(jù)傾斜的原理
1、數(shù)據(jù)傾斜產(chǎn)生的原因
我們以 Spark 和 Hive 的使用場景為例。他們在做數(shù)據(jù)運(yùn)算的時候會設(shè)計到，countdistinct、group by、join 等操作，這些都會觸發(fā) Shuffle 動作，一旦觸發(fā)，所有相同 key 的值就會拉到一個或幾個節(jié)點(diǎn)上，就容易發(fā)生單點(diǎn)問題。
2、萬惡的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ù)傾斜的原理就類似于下圖，很明了，因?yàn)閿?shù)據(jù)分布不均勻，導(dǎo)致大量的數(shù)據(jù)分配到了一個節(jié)點(diǎn)。
3、從數(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.
兩邊其實(shí)都沒有錯的，但是一旦我們做關(guān)聯(lián)了會出現(xiàn)什么情況，這個任務(wù)會在做關(guān)聯(lián)的階段，也就是 sql 的 on 的階段卡死。
4、從業(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ù)傾斜了。
如何解決
數(shù)據(jù)傾斜的產(chǎn)生是有一些討論的，解決它們也是有一些討論的，本章會先給出幾個解決數(shù)據(jù)傾斜的思路，然后對 Hadoop 和 Spark 分別給出一些解決數(shù)據(jù)傾斜的方案。
注意： 很多數(shù)據(jù)傾斜的問題，都可以用和平臺無關(guān)的方式解決，比如更好的數(shù)據(jù)預(yù)處理， 異常值的過濾等，因此筆者認(rèn)為，解決數(shù)據(jù)傾斜的重點(diǎn)在于對數(shù)據(jù)設(shè)計和業(yè)務(wù)的理解，這兩個搞清楚了，數(shù)據(jù)傾斜就解決了大部分了。
1、幾個思路
解決數(shù)據(jù)傾斜有這幾個思路：業(yè)務(wù)邏輯，我們從業(yè)務(wù)邏輯的層面上來優(yōu)化數(shù)據(jù)傾斜，比如上面的例子，我們單獨(dú)對這兩個城市來做 count，最后和其它城市做整合。
程序?qū)用?，比如說在 Hive 中，經(jīng)常遇到 count（distinct）操作，這樣會導(dǎo)致最終只有一個 reduce，我們可以先 group 再在外面包一層 count，就可以了。
調(diào)參方面，Hadoop 和 Spark 都自帶了很多的參數(shù)和機(jī)制來調(diào)節(jié)數(shù)據(jù)傾斜，合理利用它們就能解決大部分問題。
2、從業(yè)務(wù)和數(shù)據(jù)上解決數(shù)據(jù)傾斜
很多數(shù)據(jù)傾斜都是在數(shù)據(jù)的使用上造成的。我們舉幾個場景，并分別給出它們的解決方案。
數(shù)據(jù)分布不均勻：前面提到的“從數(shù)據(jù)角度來理解數(shù)據(jù)傾斜”和“從業(yè)務(wù)計角度來理解數(shù)據(jù)傾斜”中的例子，其實(shí)都是數(shù)據(jù)分布不均勻的類型，這種情況和計算平臺無關(guān)，我們能通過設(shè)計的角度嘗試解決它。
有損的方法：找到異常數(shù)據(jù)，比如 ip 為0的數(shù)據(jù)，過濾掉無損的方法：對分布不均勻的數(shù)據(jù)，單獨(dú)計算先對 key 做一層 hash，先將數(shù)據(jù)打散讓它的并行度變大，再匯集數(shù)據(jù)預(yù)處理
3、Hadoop平臺的優(yōu)化方法
列出來一些方法和思路，具體的參數(shù)和用法在官網(wǎng)看就行了。
mapjoin 方式count distinct 的操作，先轉(zhuǎn)成 group，再 count萬能膏藥：hive.groupby.skewindata=true left semi jioin 的使用設(shè)置 map 端輸出、中間結(jié)果壓縮。（不完全是解決數(shù)據(jù)傾斜的問題，但是減少了 IO 讀寫和網(wǎng)絡(luò)傳輸，能提高很多效率）
4、Spark平臺的優(yōu)化方法
列出來一些方法和思路，具體的參數(shù)和用法在官網(wǎng)看就行了。
mapjoin 方式設(shè)置 rdd 壓縮合理設(shè)置 driver 的內(nèi)存Spark Sql 中的優(yōu)化和 Hive 類似，可以參考 Hive
總結(jié)
數(shù)據(jù)傾斜的坑還是很大的，如何處理數(shù)據(jù)傾斜是一個長期的過程，希望本文的一些思路能提供幫助。
閱讀排行榜
