資料傾斜的解決，跟之前講解的效能調優，有一點異曲同工之妙。 效能調優，跟大家講過乙個道理，「重劍無鋒」。效能調優，調了半天，最有效，最直接，最簡單的方式，就是加資源，加並行度，注意rdd架構（復用同乙個rdd，加上cache快取）；shuffle、jvm等，次要的。 資料傾斜，解決方案，第乙個方案和第二個方案，一起來講。最樸素、最簡譜、最直接、最有效、最簡單的，解決資料傾斜問題的方案。 第乙個方案：聚合源資料 第二個方案：過濾導致傾斜的key 重劍無鋒。後面的五個方案，尤其是最後4個方案，都是那種特別炫酷的方案。雙重group聚合方案；sample抽樣分解聚合方案；如果碰到了資料傾斜的問題。上來就先考慮考慮第乙個和第二個方案，能不能做，如果能做的話，後面的5個方案，都不用去搞了。 有效。簡單。直接。效果是非常之好的。徹底**了資料傾斜的問題。
第乙個方案：聚合源資料 咱們現在，做一些聚合的操作，groupbykey、reducebykey；groupbykey，說白了，就是拿到每個key對應的values；reducebykey，說白了，就是對每個key對應的values執行一定的計算。 現在這些操作，比如groupbykey和reducebykey，包括之前說的join。都是在spark作業中執行的。 spark作業的資料**，通常是**呢？90%的情況下，資料**都是hive表（hdfs，大資料分布式儲存系統）。hdfs上儲存的大資料。hive表，hive表中的資料，通常是怎麼出來的呢？有了spark以後，hive比較適合做什麼事情？hive就是適合做離線的，晚上凌晨跑的，etl（extract transform load，資料的採集、清洗、匯入），hive sql，去做這些事情，從而去形成乙個完整的hive中的資料倉儲；說白了，資料倉儲，就是一堆表。 spark作業的源表，hive表，其實通常情況下來說，也是通過某些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操作，進行你需要的操作即可。key,values串。 spark中，可能對這個操作，就不需要執行shffule操作了，也就根本不可能導致資料傾斜。 或者是，對每個key在hive etl中進行聚合，對所有values聚合一下，不一定是拼接起來，可能是直接進行計算。reducebykey，計算函式，應用在hive etl中，每個key的values。
聚合源資料方案，第二種做法 你可能沒有辦法對每個key，就聚合出來一條資料； 那麼也可以做乙個妥協；對每個key對應的資料，10萬條；有好幾個粒度，比如10萬條裡面包含了幾個城市、幾天、幾個地區的資料，現在放粗粒度；直接就按照城市粒度，做一下聚合，幾個城市，幾天、幾個地區粒度的資料，都給聚合起來。比如說 city_id date area_id select ... from ... group by city_id 盡量去聚合，減少每個key對應的數量，也許聚合到比較粗的粒度之後，原先有10萬資料量的key，現在只有1萬資料量。減輕資料傾斜的現象和問題。
上面講的第一種方案，其實這裡沒法講的太具體和仔細；只能給乙個思路。但是我覺得，思路已經講的非常清晰了；一般來說，大家只要有一些大資料（hive）。經驗，我覺得都是可以理解的。 具體怎麼去在hive etl中聚合和操作，就得根據你碰到資料傾斜問題的時候，你的spark作業的源hive表的具體情況，具體需求，具體功能，具體分析。
對於我們的程式來說，完全可以將aggregatebysession()這一步操作，放在乙個hive etl中來做，形成乙個新的表。對每天的使用者訪問行為資料，都按session粒度進行聚合，寫乙個hive sql。 在spark程式中，就不要去做groupbykey+maptopair這種運算元了。直接從當天的session聚合表中，用spark sql查詢出來對應的資料，即可。這個rdd在後面就可以使用了。
第二個方案：過濾導致傾斜的key 如果你能夠接受某些資料，在spark作業中直接就摒棄掉，不使用。比如說，總共有100萬個key。只有2個key，是資料量達到10萬的。其他所有的key，對應的數量都是幾十。 這個時候，你自己可以去取捨，如果業務和需求可以理解和接受的話，在你從hive表查詢源資料的時候，直接在sql中用where條件，過濾掉某幾個key。 那麼這幾個原先有大量資料，會導致資料傾斜的key，被過濾掉之後，那麼在你的spark作業中，自然就不會發生資料傾斜了。
資料傾斜方案之聚合源資料
效能調優，最有效，最直接，最簡單的方式，就是加資源，加並行度，注意rdd架構 復用同乙個rdd,加上cache快取 shuffle,jvm等，是次要的。資料傾斜，解決方案 第乙個方案 聚合源資料 現在，做一些聚合操作，groupbykey,reducebykey這種操作，說白了，就是拿到每個key對...
Spark專案實戰 資料傾斜解決方案之聚合源資料
資料傾斜的解決跟之前講解的效能調優，有一點異曲同工之妙。效能調優，其實調了半天，最有效 最直接 最簡單的方式就是加資源，加並行度，注意rdd架構 復用同乙個rdd，加上cache快取 而shuffle jvm等都是調優次要的。資料傾斜問題最直接 最有效 最簡單的方案就是 聚合源資料和過濾導致傾斜的k...
資料傾斜解決方案
資料傾斜定義 簡單的講，資料傾斜就是我們在資料計算的時候，由於資料的分散度不夠，導致大量的資料集中到了一台或者幾台機器上計算，這些機器的計算速度遠遠低於整個集群的平均計算速度，導致整個計算過程十分緩慢。常見資料傾斜現象 資料傾斜往往會發生在資料開發的各個環節中，比如 用hive資料計算的時候redu...