常見表現：在hive中 map階段早就跑完了，reduce階段一直卡在99%。很大情況是發生了資料傾斜，整個任務在等某個節點跑完。 在spark中大部分的task執行的特別快，剩下的一些task執行的特別慢，要幾分鐘或幾十分鐘才執行完乙個task hive中大表join的時候，容易產生資料傾斜問題，spark中產生shuffle類運算元的操作，groupbykey、reducebykey、join等操作會引起資料傾斜。通過stage去定位
資料傾斜原因： 在進行shuffle的時候，必須將各個節點上相同的key拉取到某個節點上的乙個task來進行處理，比如按照key進行聚合或join等操作。此時如果某個key對應的資料量特別大的話，就會發生資料傾斜。比如大部分key對應10條資料，但是個別key卻對應了100萬條資料，那麼大部分task可能就只會分配到10條資料，然後1秒鐘就執行完了；但是個別task可能分配到了100萬資料，要執行一兩個小時
解決方法1：直接過濾掉那些引起傾斜的key
比如說，總共有100萬個key。只有2 個key，是資料量達到10 萬的。其他所有的key，對應的數量都是幾十，這樣join後會引起傾斜。這個時候，自己可以去取捨，如果業務和需求可以理解和接受的話，在從hive 表查詢源資料的時候，直接在sql 中用where 條件，過濾掉某幾個key。那麼這幾個原先有大量資料，會導致資料傾斜的key，被過濾掉之後，那麼在的spark作業中，自然就不會發生資料傾斜了。
解決方法2：hive etl做處理
導致資料傾斜的是hive表。如果該hive表中的資料本身很不均勻（比如某個key對應了100萬資料，其他key才對應了10條資料），而且應用中需要頻繁使用spark對hive表執行分析操作時，可以使用hive etl去做乙個預處理 實現方式 通過hive etl預先對資料按照key進行聚合，或者是預先和其他表進行join，然後在spark作業中針對的資料來源就不是原來的hive表了，而是預處理後的hive表。此時由於資料已經預先進行過聚合或join操作了，那麼在spark作業中也就不需要使用原先的shuffle類運算元執行這類操作了。hive etl中進行group by或者join等shuffle操作時，還是會出現資料傾斜，導致hive etl的速度很慢。我們只是把資料傾斜的發生提前到了hive etl中
解決方法3：提高shuffle操作並行度
在對rdd執行shuffle運算元時，給shuffle運算元傳入乙個引數，比如reducebykey(1000)，該引數就設定了這個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的執行時間都會變短了
前端開發 效能優化與調優
目前前端開發進行效能測試，大部分都是用類似以下的 進行測試 var start new date gettime var end new date gettime console.log end start 這種方式實在太low了，而且並不十分精確，因為引擎不同，環境也不同，在本機器上進行的測試，再...
spark效能調優 資料傾斜
1.資料傾斜發生時的現象 絕大多數task執行得都非常快，但個別task執行極慢。比如，總共有1000個task，997個task都在1分鐘之內執行完了，但是剩餘兩三個task卻要一兩個小時。這種情況很常見。原本能夠正常執行的spark作業，某天突然報出oom 記憶體溢位 異常，觀察異常棧，是我們寫...
Hive效能調優之資料傾斜 2
1 通常情況下，作業會通過input的目錄產生乙個或者多個map任務。主要的決定因素有 input的檔案總個數，input的檔案大小，集群設定的檔案塊大小 目前為128m，可在hive中通過set dfs.block.size 命令檢視到，該引數不能自定義修改 2 舉例 a 乙個大檔案 假設inpu...