資料傾斜的概念
有的時候，我們可能會遇到大資料計算中乙個最棘手的問題--資料傾斜，此時spark作業的效能會比期望的差的多。資料傾斜調優，就是使用各種技術方案解決不同型別的資料傾斜問題以保證spark作業的效能
絕大多數task執行的都非常快，但個別task執行極慢，比如，總共有1000個task，997個task都在一分鐘內執行完了，但是剩餘兩三個taks需要一兩個小時，這種情況很常見。
原本能夠正常執行的spark作業，某天突然報出oom（記憶體溢位）異常，觀察異常 棧，是我們寫的業務**造成的，這種情況比較少見。
資料傾斜發生的原理
資料傾斜的原理很簡單：在進行shuffle的時候，必須將各個節點上相同的key拉取到某個節點上的乙個task來進行處理，比如按照key進行聚合或join等操作此時如果某個key對應的資料量特別大的話，就會發生資料傾斜。
如何定位導致資料傾斜的**
資料傾斜只會發生在shuffle過程中，這裡給大家羅列一些常用的並且可能會觸發shuffle操作的運算元：groupbykey，reducebykey，join,cogroup,repartition等。出現資料傾斜時，可能是你的使用了這些運算元中某乙個所導致的。可以使用rdd.sample(false,0.1).countbykey的方式隨機抽查出傾斜的資料。
資料傾斜的解決方案
方案一：使用hive etl預處理資料
方案使用場景：導致資料傾向性的是hive表，如果hive表中的資料本身很不均勻。
方案實現思路：此時可以評估一下，是否可以通過hive來進行資料預處理（即通過hive etl 預先對資料按照key進行聚合，或者是預先和其他表進行join），然後在spark作業中針對的資料來源就不是原來的hive表了，而是處理後的hive表，此時由於預先進行過聚合或join操作了，那麼在spark作業中就不需要使用原先的shuffle類運算元執行這類操作了。
方案實現原理：這種方案從根源上解決了資料傾斜，因此徹底避免了在spark中執行shuffle類運算元，那麼肯定不會有資料傾斜的問題了。但是這裡也要提醒下大家，這種方式治標不治本，因為畢竟資料本身就存在不均勻問題，所以hive etl 中進行group by 或 join等shuffle操作時，還是會出現資料傾斜，導致hive etl的速度很慢，我們只是把資料傾斜的發生提前到了hive etl中，避免spark程式發生資料傾斜而已。
方案優點：實現起來簡單便捷，效果還非常好，完全避掉了資料傾斜，spark作業效能會大幅度提公升。
解決方案二：過濾少量導致資料傾斜的key
方案使用場景：如果發現導致傾斜的key就少數幾個，而且對計算本身的影響並不大的話，那麼很適合使用這種解決方案，比如99%的key就對應10條資料，但是只有乙個key對應了100w萬資料，從而導致了資料傾斜。
方案解決思路：如果我們判斷那少數幾個資料量特別多的key，對作業的執行和計算結果不是特別重要的話，那麼可以使用sample運算元對rdd進行取樣，然後計算出key的數量，取資料量多的key過濾掉即可。
方案實現原理：將導致資料傾斜的key給過濾掉之後，這些key就不對參與計算了，自然不能產生資料傾斜。
方案優缺點：實現簡單，而且效果也很好，可能完全避掉資料傾斜，使用場景不多，大多數情況下，導致傾斜的key還是很多，並不算是只有少數幾個。
方案三：提高shuffle操作的並行度
方案使用場景：如果我們必須要對資料傾斜迎難而上，那麼建議優先使用這些方案，因此這些是處理資料最簡單的一種方案。
方案實現思路：在rdd進行shuffle運算元時，給shuffle運算元傳入乙個引數，比如reducebykey（10000）該引數就設定了這個shuffle運算元執行時shuffle read task的數量。對於spark sql中的shuffle類語句，比如group by ，join等，需要設定乙個引數，即spark.sql.shuffle.partitions,該引數代表了shuffle read task 的並行度，預設值為200，對於很多場景來說都是有點過小。
方案實現原理:增加shuffle read task 的數量，可以讓原本分配給乙個task的多個key分配給多個task，從而讓每個task處理比原來更少的資料。舉例來說，如果原本5個key，每個key對應10條資料，這5個key都是分配給乙個task的，那麼這個task就要處理50條資料，二增加了shuffle read task 以後，每個task就分配到乙個key，即每個task就處理10條資料，那麼自然每個task的執行時間都會變短了。
方案優點：實現起來比較簡單，可以有效的緩解和減輕資料傾斜的影響。
方案缺點：只是緩解了資料傾斜而已，並沒有徹底**了問題，根據實戰經驗來看，其效果有限。
解決方案四：兩階段聚合（區域性聚合+全域性聚合）
方案試用場景：對rdd執行reducebykey等聚合類shuffle運算元或在spark sql中使用group by 語句進行了分組聚合是，比較適用這種方案。
方案實現原理：將原本相同的key通過附加隨機字首的方式，變成多個不同的key，就可以讓原本被乙個task處理的資料分散到多個task上去做區域性聚合，進而解決單個task處理資料量過多的問題。接著去除掉隨機字首，在次進行全域性聚合，就可以得到最終的結果。
方案優點：對於聚合類的shuffle操作導致的資料傾斜，效果是非常不錯的，通常都可以解決掉資料傾斜，或者至少是大幅度的解除資料傾斜，將spark作業的效能提公升數倍以上
方案缺點：僅僅適用於聚合類的shuffle操作，適用範圍相對比較窄，如果join類的shuffle操作，還得用其他的解決方案。
Spark之資料傾斜
spark之資料傾斜 1 關於效能調優首先談資料傾斜，為什麼?1 因為如果資料傾斜，其他所有的調優都是笑話，因為資料傾斜主要導致程式跑步起來或者執行狀態不可用。2 資料傾斜最能代表spark水平的地方，spark是分布式的，如果理解資料傾斜說明你對spark執行機制瞭如指掌。2 資料傾斜兩大直接致命...
Spark效能優化指南 資料傾斜
調優概述 有的時候，我們可能會遇到大資料計算中乙個最棘手的問題 資料傾斜，此時spark作業的效能會比期望差很多。資料傾斜調優，就是使用各種技術方案解決不同型別的資料傾斜問題，以保證spark作業的效能。資料傾斜發生時的現象 絕大多數task執行得都非常快，但個別task執行極慢。比如，總共有100...
Spark 資料傾斜
計算資料時，資料分散度不夠，導致大量資料集中到一台或幾台機器上計算。區域性計算遠低於平均計算速度，整個過程過慢。部分任務處理資料量過大，可能oom，任務失敗，進而應用失敗。1 executor lost driver oom shuffle過程出錯 2 正常執行任務突然失敗 3 單個executor...