作者 | 小艦
出品 | dlab資料實驗室（id：rucdlab）
增加隨機字首
1.資料準備
由於上面兩期，我們都是用的1.2億條資料的單錶來進行測試的，本節的場景需要涉及到兩表join，因此我們再次構造乙個小表。
本期我們就用這兩個表進行join，再簡單回顧一下那1.2億條資料的表cyj_skew，其中有1億條資料是不重複的，後面的2000萬條資料集中在了50個key中，所以這50個key每個key會重複40萬次；那我們可以簡單估計，cyj_skew中的50個重複key與cyj_skew_small 500個重複key相join，二者共有的乙個重複key會產生100*40w=4000w條結果，這個資料量比起其它key來講會大千萬倍。所以我們預想肯定會產生資料傾斜。
2.判斷資料傾斜
如何判斷資料傾斜呢？如果我們看到在任務執行的時候，大部分task都執行完畢，只剩若干個任務還在執行，並且執行時間和處理資料量遠超其他task，則可以認為發生了資料傾斜，如下圖所示，時間和資料量相差比較大。
3.判斷傾斜鍵
因為資料傾斜鍵是我們自己模擬出來的，所以我們知道cyj_skew和cyj_skew_small分別有50和500個重複鍵，那我們需要找出他們共有的重複鍵，對這些重複鍵進行優化。
首先，我們需要查詢出這兩個表對資料，得到兩份資料dataframe
然後，對這些資料的共有key進行加字首操作
最後，我們重新將新增字首的資料進行join計算
5.未優化效能結果
我們可以看到無論是時間還是資料量上都差別很大，而且總執行時長為11分鐘左右
6.優化效能
我們可以看到，整體的時間和資料量相差不大，資料傾斜現象基本消失，整個任務執行3分鐘左右。
總結
dlab資料實驗室 發起了乙個讀者討論交流區
●spark資料傾斜解決方案實戰（二）
●spark資料傾斜解決方案實戰（一）
●大資料計算生態之資料計算（二）
●大資料計算生態之資料計算（一）
●大資料計算生態之資料儲存
●spark訓練營（一）-- 開發環境搭建及wordcount實戰
●spark訓練營（二）-- sparkstreaming流計算元件wordcount實戰
●spark訓練營（三）-- graphx圖計算元件最短路演算法實戰
●一文縱覽大資料計算生態
●原創|帶你釐清分布式、資料庫的那些一致性
●深入淺出大資料元件之kafka訊息佇列
●乙個故事讓你理解什麼是區塊鏈
●實時資料流計算引擎flink和spark剖析
●自定義hadoop的輸入格式
Spark專案實戰 資料傾斜解決方案之聚合源資料
資料傾斜的解決跟之前講解的效能調優，有一點異曲同工之妙。效能調優，其實調了半天，最有效 最直接 最簡單的方式就是加資源，加並行度，注意rdd架構 復用同乙個rdd，加上cache快取 而shuffle jvm等都是調優次要的。資料傾斜問題最直接 最有效 最簡單的方案就是 聚合源資料和過濾導致傾斜的k...
Spark 資料傾斜
計算資料時，資料分散度不夠，導致大量資料集中到一台或幾台機器上計算。區域性計算遠低於平均計算速度，整個過程過慢。部分任務處理資料量過大，可能oom，任務失敗，進而應用失敗。1 executor lost driver oom shuffle過程出錯 2 正常執行任務突然失敗 3 單個executor...
spark資料傾斜問題
資料傾斜 加更大記憶體 跟cpu硬體是效能優化的根本之道 一 資料傾斜帶來的致命性後果 1.oom 根本原因資料太多 一般oom都是由於資料傾斜所致，spark基於jvm之上的 2.速度非常慢 二 資料傾斜的基本特徵 1.任務分配不均勻 2.個別task處理過度大量的資料 shuffle過程中遇到同...