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

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

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

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

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

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

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

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

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

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

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

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

　　TIPS：

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

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

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

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