數(shù)據(jù)分布傾斜性指的是數(shù)據(jù)分布過度集中于數(shù)據(jù)空間的某端，造成“頭重腳輕”或者“比薩斜塔”等不均勻的分布特點。數(shù)據(jù)分布傾斜性將造成運(yùn)算效率上的“瓶頸”和數(shù)據(jù)分析結(jié)果的“以偏概全”。

效率上的“瓶頸”

假如在大型商場中，共有A,B1,B2…..B9十家店鋪，其中A店鋪中有99W商品，B1,B2….B9這九家店鋪分別有1W商品。我們要統(tǒng)計商場中商品總數(shù)，計算初，采用HASHMAP作為存儲結(jié)構(gòu)，其中Key：店鋪 Value：商品。我們的計算過程是先統(tǒng)計每個店鋪的商品總數(shù)，最后將結(jié)果累加。可以發(fā)現(xiàn)，由于A有99W商品，按照1+1的累積方式（假如1+1耗時1秒），我們要加99W個1才能得到A店鋪的商品總數(shù)（總耗時99W秒），而B1,B2….B9只需分別累加1W個1（分別耗時1W秒），而為了得到商場中的商品總數(shù)，我們必須等待所有店鋪都分別累計結(jié)束才能處理總和，顯而易見，此時運(yùn)算瓶頸便集中在A店鋪的商品累計上。

這類狀況經(jīng)常發(fā)生在分布式運(yùn)算過程中，比如Hadoop Job計算，因為map/reduce 過程中是以Key-value形式來處理數(shù)據(jù)，假如某key下的數(shù)據(jù)量太大，會導(dǎo)致整個計算過程中move/shuffle/sort的耗時遠(yuǎn)遠(yuǎn)高于其他key，因此該Key變成為效率“瓶頸”。一般解決辦法是，自定義partitioner，對所有的Value進(jìn)行自定義分組，使得每組的量較平均，從而解決時間瓶頸問題。

數(shù)據(jù)分析結(jié)果的“以偏概全”

同樣使用上述的“商場”案例，并且在此基礎(chǔ)上我們假設(shè)A店鋪,B9店鋪是賣低端商品，而B1,B2…..B8是賣高端商品，銷量較小。如果我們要根據(jù)商品銷售狀況分析店鋪在買家當(dāng)中的受歡迎程度。由于A店鋪本身商品量大，而且定位的銷售價位是屬于薄利多銷，如果只從銷售量的考慮，我們會以為A店鋪在商場中是最受買家歡迎的，造成“片面”的分析結(jié)果。

其實，遇到這種情況，我們首先的分析賣家性質(zhì)和買家性質(zhì)，并且使用相對量來作為評估值，比如A店鋪賣低端商品，日銷售量1W商品，1W/99W<1%, 而B9店鋪賣低端商品，日銷售量5K商品，5K/1W=50%,所以在低端買家中，低端商品店鋪B9應(yīng)該是最受歡迎的。