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

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

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

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

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

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

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

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

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

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

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

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

　　TIPS：

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

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

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

　　因此出現(xiàn)數(shù)據(jù)傾斜的時候，Spark 作業(yè)看起來會運行得非常緩慢，甚至可能因為某個 task 處理的數(shù)據(jù)量過大導(dǎo)致內(nèi)存溢出。