資料傾斜的解決跟之前講解的效能調優，有一點異曲同工之妙。
效能調優，其實調了半天，最有效、最直接、最簡單的方式就是加資源，加並行度，注意rdd架構（復用同乙個rdd，加上cache快取）。而shuffle、jvm等都是調優次要的。
資料傾斜問題最直接、最有效、最簡單的方案就是：聚合源資料和過濾導致傾斜的key。
我們在spark做一些聚合的操作groupbykey、reducebykey，其實就是拿到每個key對應的values或者對每個key對應的values執行一定的計算。現在這些操作，比如groupbykey和reducebykey都是在spark作業中執行的。
而spark作業的資料**，通常是**呢？90%的情況下，資料**都是hive表（hdfs，大資料分布式儲存系統）。有了spark以後，hive比較適合做什麼事情？hive就是適合做離線的，晚上凌晨跑的etl（extract transform load，資料的採集、清洗、匯入），從而去形成乙個完整的hive中的資料倉儲，我們可以簡單理解資料倉儲就是一堆表。
spark作業的源表其實通常情況下來說也是通過某些hive etl生成的。hive etl可能是晚上凌晨在那兒跑，今天跑昨天的資料。而資料傾斜，某個key對應的80萬資料，某些key對應幾百條，某些key對應幾十條。
現在咱們直接在生成hive表的hive etl中，對資料進行聚合。比如按key來分組，將key對應的所有的values，全部用一種特殊的格式，拼接到乙個字串裡面去，比如「key=sessionid, value: action_seq=1|user_id=1|search_keyword=火鍋|category_id=001;action_seq=2|user_id=1|search_keyword=涮肉|category_id=001」。
對key進行group，在spark中拿到key=sessionid，values。hive etl中直接對key進行了聚合，那麼也就意味著每個key就只對應一條資料。在spark中就不需要再去執行groupbykey+map這種操作了。直接對每個key對應的values字串，map操作，進行你需要的操作即可。 spark中可能對這個操作就不需要執行shffule操作了，也就根本不可能導致資料傾斜。或者是對每個key在hive etl中進行聚合，對所有values聚合一下，不一定是拼接起來，可能是直接進行計算。
聚合源資料的另乙個思路：我們可能沒有辦法對每個key就聚合出來一條資料，那麼也可以做乙個妥協，對每個key對應的資料，有好幾個粒度，比如10萬條裡面包含了幾個城市、幾天、幾個地區的資料，現在放粗粒度。直接就按照城市粒度，做一下聚合，幾個城市，幾天、幾個地區粒度的資料，都給聚合起來。總之盡量去聚合，減少每個key對應的數量，也許聚合到比較粗的粒度之後，原先有10萬資料量的key，現在只有1萬資料量。減輕資料傾斜的現象和問題。
如果你能夠接受某些資料，在spark作業中直接就摒棄掉，不使用。比如說總共有100萬個key，只有2個key是資料量達到10萬的，其他所有的key對應的數量都是幾十。這個時候，我們自己可以去取捨，如果業務和需求可以理解和接受的話，在你從hive表查詢源資料的時候，直接在sql中用where條件，過濾掉某幾個key。那麼這幾個原先有大量資料，會導致資料傾斜的key，被過濾掉之後，那麼在spark作業中自然就不會發生資料傾斜了。
Spark資料傾斜方案實戰 三
作者 小艦 出品 dlab資料實驗室 id rucdlab 增加隨機字首 1.資料準備 由於上面兩期，我們都是用的1.2億條資料的單錶來進行測試的，本節的場景需要涉及到兩表join，因此我們再次構造乙個小表。本期我們就用這兩個表進行join，再簡單回顧一下那1.2億條資料的表cyj skew，其中有...
spark解決資料傾斜問題
參考 資料傾斜發生的原理 資料傾斜的原理很簡單 在進行shuffle的時候，必須將各個節點上相同的key拉取到某個節點上的乙個task來進行處理，比如按照key進行聚合或join等操作。此時如果某個key對應的資料量特別大的話，就會發生資料傾斜。比如大部分key對應10條資料，但是個別key卻對應了...
Spark 資料傾斜
計算資料時，資料分散度不夠，導致大量資料集中到一台或幾台機器上計算。區域性計算遠低於平均計算速度，整個過程過慢。部分任務處理資料量過大，可能oom，任務失敗，進而應用失敗。1 executor lost driver oom shuffle過程出錯 2 正常執行任務突然失敗 3 單個executor...