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

　　對(duì) Spark/Hadoop 這樣的分布式大數(shù)據(jù)系統(tǒng)來(lái)講，數(shù)據(jù)量大并不可怕，可怕的是數(shù)據(jù)傾斜。

　　對(duì)于分布式系統(tǒng)而言，理想情況下，隨著系統(tǒng)規(guī)模（節(jié)點(diǎn)數(shù)量）的增加，應(yīng)用整體耗時(shí)線(xiàn)性下降。如果一臺(tái)機(jī)器處理一批大量數(shù)據(jù)需要 120 分鐘，當(dāng)機(jī)器數(shù)量增加到 3 臺(tái)時(shí)，理想的耗時(shí)為 120 / 3 = 40 分鐘。但是，想做到分布式情況下每臺(tái)機(jī)器執(zhí)行時(shí)間是單機(jī)時(shí)的1 / N，就必須保證每臺(tái)機(jī)器的任務(wù)量相等。不幸的是，很多時(shí)候，任務(wù)的分配是不均勻的，甚至不均勻到大部分任務(wù)被分配到個(gè)別機(jī)器上，其它大部分機(jī)器所分配的任務(wù)量只占總量的小部分。比如一臺(tái)機(jī)器負(fù)責(zé)處理 80% 的任務(wù)，另外兩臺(tái)機(jī)器各處理 10% 的任務(wù)。

　　『不患多而患不均』，這是分布式計(jì)算環(huán)境下最大的問(wèn)題。意味著計(jì)算能力不是線(xiàn)性擴(kuò)展的，而是存在短板效應(yīng)： 一個(gè) Stage 所耗費(fèi)的時(shí)間，是由最慢的那個(gè) Task 決定。

　　由于同一個(gè) Stage 內(nèi)的所有 task 執(zhí)行相同的計(jì)算，在排除不同計(jì)算節(jié)點(diǎn)計(jì)算能力差異的前提下，不同 task 之間耗時(shí)的差異主要由該 task 所處理的數(shù)據(jù)量決定。所以，要想發(fā)揮分布式系統(tǒng)并行計(jì)算的優(yōu)勢(shì)，就必須解決數(shù)據(jù)傾斜問(wèn)題。

　　數(shù)據(jù)傾斜的危害

　　當(dāng)出現(xiàn)數(shù)據(jù)傾斜時(shí)，小量任務(wù)耗時(shí)遠(yuǎn)高于其它任務(wù)，從而使得整體耗時(shí)過(guò)大，未能充分發(fā)揮分布式系統(tǒng)的并行計(jì)算優(yōu)勢(shì)。

　　另外，當(dāng)發(fā)生數(shù)據(jù)傾斜時(shí)，部分任務(wù)處理的數(shù)據(jù)量過(guò)大，可能造成內(nèi)存不足使得任務(wù)失敗，并進(jìn)而引進(jìn)整個(gè)應(yīng)用失敗。

　　數(shù)據(jù)傾斜的現(xiàn)象

　　當(dāng)發(fā)現(xiàn)如下現(xiàn)象時(shí)，十有八九是發(fā)生數(shù)據(jù)傾斜了：

　　絕大多數(shù) task 執(zhí)行得都非?？?，但個(gè)別 task 執(zhí)行極慢，整體任務(wù)卡在某個(gè)階段不能結(jié)束。

　　原本能夠正常執(zhí)行的 Spark 作業(yè)，某天突然報(bào)出 OOM（內(nèi)存溢出）異常，觀(guān)察異常棧，是我們寫(xiě)的業(yè)務(wù)代碼造成的。這種情況比較少見(jiàn)。

　　TIPS：

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

　　數(shù)據(jù)傾斜的原因

　　在進(jìn)行 shuffle 的時(shí)候，必須將各個(gè)節(jié)點(diǎn)上相同的 key 拉取到某個(gè)節(jié)點(diǎn)上的一個(gè) task 來(lái)進(jìn)行處理，比如按照 key 進(jìn)行聚合或 join 等操作。此時(shí)如果某個(gè) key 對(duì)應(yīng)的數(shù)據(jù)量特別大的話(huà)，就會(huì)發(fā)生數(shù)據(jù)傾斜。比如大部分 key 對(duì)應(yīng)10條數(shù)據(jù)，但是個(gè)別 key 卻對(duì)應(yīng)了100萬(wàn)條數(shù)據(jù)，那么大部分 task 可能就只會(huì)分配到10條數(shù)據(jù)，然后1秒鐘就運(yùn)行完了;但是個(gè)別 task 可能分配到了100萬(wàn)數(shù)據(jù)，要運(yùn)行一兩個(gè)小時(shí)。

　　因此出現(xiàn)數(shù)據(jù)傾斜的時(shí)候，Spark 作業(yè)看起來(lái)會(huì)運(yùn)行得非常緩慢，甚至可能因?yàn)槟硞€(gè) task 處理的數(shù)據(jù)量過(guò)大導(dǎo)致內(nèi)存溢出。