Spark千億級資料去重，效能最佳化踩坑之路

大家好，我是狗哥，今天給大家寫一點乾貨，這次我們們就從0-1把思路給大家講一下，這也是我同事在資料開發中踩過的坑，希望能幫助到大家。

先虛擬一個業務場景，方便大家思考

我舉個例子，拿京東或者淘寶說吧，如果你的業務讓你計算幾個維度(廣告位置、小時、廣告型別等等吧，我就隨便舉個例子)，每個維度的資料uv量級，方便業務評估和市場決策，資料精準度不要求完全精準，誤差在1%以內就行了，你該如何做?

我們針對兩個開發者思路，來跟大家梳理我們踩過的坑。

思路一，能跑就行，不關注效能

解決方式：直接count distinct

優勢：應屆生都會

弊端：資料去重效能差

計算效能：剛開始資料量少，4-6個小時可以出來，隨著資料量增多執行時間 6-12個小時，業務對此非常不滿意，早上來了看不到資料包表，需要等下午才產出，直接影響資料人員的口碑(老闆開週會，肯定會diss做資料的，不能忍呀兄弟們，一定要精益求精!!!)。

思路二，用bitmap去重複

經過一番技術調研，發現用bitmap去重複，效能會很高，但裝置id(imei、idfa) 不是數字，沒有辦法用bitmap，如果想用bitmap，需要把裝置ID做hash計算，還得取絕對值，正數才行

解決方式：abs(hash(imei))

優勢：bitmap去重複效能高效，資料計算效能降低到了40分鐘，從之前的10個小時跑不出來，變成了40分鐘可以執行出來，直接單車變摩托。

弊端：發現資料誤差到了6%，排查發現，是資料裝置ID在hash的時候會出現正負數，也就是兩個裝置他的hash值是正負對稱的(舉個例子：一個裝置hash值 -1，一裝置個hash值1)，兩個裝置取絕對值abs，會出現都等於1。

針對這個問題，狗哥給出了建議，就是先根據裝置ID取模1000(這個數大家可以自己去根據資料量除錯)，進行裝置ID分桶，這樣的好處相同裝置會分在同一個桶內，同時減少了hash值絕對值這之後相互影響的情況，然後每個分桶的u去重複uv再累加，這樣下來，分維度的資料uv就會計算出來了，資料準確度到了0.03%，符合業務要求，同時資料效能穩定在40分鐘左右。