運算元優化 repartiton

運算元優化 repartiton

運算元調優之使用repartition解決spark sql低並行度的效能問題

spark.sql.shuffle.partitions 調整dataframe的shuffle並行度

spark.default.parallelism  調整rdd的shuffle並行度

並行度：之前說過，並行度是自己可以調節，或者說是設定的。

1、spark.default.parallelism

2、textfile()，傳入第二個引數，指定partition數量（比較少用）

咱們的專案**中，沒有設定並行度，實際上，在生產環境中，是最好自己設定一下的。

自己手動設定spark.default.parallelism引數，指定為cpu core總數的2~3倍。400~600個並行度。600。

承上啟下

你設定的這個並行度，在哪些情況下會生效？哪些情況下，不會生效？

都是你設定的那個引數。（除非你使用coalesce運算元縮減過partition數量）

問題來了，spark sql，用了。用spark sql的那個stage的並行度，你沒法自己指定。

spark sql自己會預設根據hive表對應的hdfs檔案的block，自動設定spark sql查詢所在的那個stage的

並行度。你自己通過spark.default.parallelism引數指定的並行度，只會在沒有spark sql的stage中生效。

比如你第乙個stage，用了spark sql從hive表中查詢出了一些資料，然後做了一些transformation操作，

接著做了乙個shuffle操作（groupbykey）；下乙個stage，在shuffle操作之後，

做了一些transformation操作。hive表，對應了乙個hdfs檔案，有20個block；

你自己設定了spark.default.parallelism引數為100。

你的第乙個stage的並行度，是不受你的控制的，就只有20個task；第二個stage，

才會變成你自己設定的那個並行度，100。

問題在**？

spark sql預設情況下，它的那個並行度，咱們沒法設定。可能導致的問題，也許沒什麼問題，

也許很有問題。spark sql所在的那個stage中，後面的那些transformation操作，

可能會有非常複雜的業務邏輯，甚至說複雜的演算法。如果你的spark sql預設把task數量設定的很少，

20個，然後每個task要處理為數不少的資料量，然後還要執行特別複雜的演算法。

這個時候，就會導致第乙個stage的速度，特別慢。第二個stage，1000個task，刷刷刷，非常快。

解決上述spark sql無法設定並行度和task數量的辦法，是什麼呢？

repartition運算元，你用spark sql這一步的並行度和task數量，肯定是沒有辦法去改變了。但是呢，

可以將你用spark sql查詢出來的rdd，使用repartition運算元，去重新進行分割槽，

此時可以分割槽成多個partition，比如從20個partition，分割槽成100個。

然後呢，從repartition以後的rdd，再往後，並行度和task數量，就會按照你預期的來了。

就可以避免跟spark sql繫結在乙個stage中的運算元，只能使用少量的task去處理大量資料以及

複雜的演算法邏輯。

運算元優化 foreachPartition

運算元優化 foreachpartition foreach的寫庫原理 預設的foreach的效能缺陷在 首先，對於每條資料，都要單獨去呼叫一次function，task為每個資料，都要去執行一次function函式。如果100萬條資料，乙個partition 呼叫100萬次。效能比較差。另外乙個非...

優化資料結構運算元組 指標

開始操作 原始資料結構 define receive max 2048 typedef struct lbdatatype 計畫 1改為指標 2放棄巨集 先1 define receive max 2048 typedef struct lbdatatype 編譯發現 沒有問題 其實是有問題的 你看...

Spark效能優化 2 運算元調優

本片博文為大家帶來的是運算元調優。二.foreachpartition 優化資料庫操作 三.filter 與 coalesce 的配合使用 四.repartition解決 sparksql 低並行度問題 五.reducebykey 預聚合 在生產環境中，通常使用foreachpartition運算元...