Spark優化一則 減少Shuffle

2022-08-24 03:51:12 字數 4185 閱讀 1231

破砂鍋用自己3節點的spark集群試驗了這個優化演算法,並進一步找到更快的演算法。測試資料是sogou實驗室的日誌檔案前10000000條資料。目標是對日誌第2列資料,按照第乙個字母合併,得到每個首字母有幾條記錄。

所有的方案都重新啟動spark shell,先用以下**把日誌第2列資料cache到記憶體裡,spark gui顯示cache有8個partition,約1gb記憶體。

val rdd = sc.textfile("

hdfs://hadoop1:8000/input/sogouq3.txt

").map(_.split("

\t")).map(_(1

))rdd.cache()

rdd.count()

//res1: long = 10000000

spark gui

rdd name

storage level

cached partitions

fraction cached

size in memory

size in tachyon

size on disk

memory deserialized 1x replicated

100%

1089.4 mb

0.0 b

0.0 b

rdd.map(x => (x.charat(0), x)).groupbykey().mapvalues().collect()

//res2: array[(char, int)] = array((8,168189), (0,168338), (a,168228), (9,168018), (1,167647), (b,168404), (2,168731), (3,168206), (c,168991), (d,168095), (4,167523), (e,168179), (5,167967), (6,167907), (f,168174), (7,168718))

spark stage gui顯示有關stage id是1-2,累計耗時5s,產生140mb shuffle read和208mb shuffle write。

stage id

description

submitted

duration

tasks: succeeded/total

shuffle read

shuffle write

collect at :15      

2014/09/03 20:51:58

3 s8/8                     

140.2 mb

map at :15      

2014/09/03 20:51:55

2 s8/8                     

208.4 mb

count at :15      

2014/09/03 20:51:46

8 s8/8                     

rdd.distinct(numpartitions = 6).map(x => (x.charat(0), 1)).reducebykey(_+_).collect()

//res2: array[(char, int)] = array((6,167907), (0,168338), (f,168174), (7,168718), (a,168228), (1,167647), (8,168189), (b,168404), (2,168731), (9,168018), (3,168206), (c,168991), (d,168095), (4,167523), (e,168179), (5,167967))

spark stage gui顯示有關stage id是1-3,累計耗時4.2s,生成50mb shuffle read和75mb shuffle write。雖然多了1個stage,shuffle read/write比原始方案減少超過60%,從而速度加快16%。

stage id

description

submitted

duration

tasks: succeeded/total

shuffle read

shuffle write

collect at :15      

2014/09/03 20:24:17

0.2 s

6/6                     

4.9 kb

reducebykey at :15      

2014/09/03 20:24:15

2 s6/6                     

50.4 mb

7.4 kb

distinct at :15      

2014/09/03 20:24:13

2 s8/8                     

75.6 mb

count at :15      

2014/09/03 20:23:55

7 s8/8                     

既然減少shuffle可以加快速度,破砂鍋想出以下的zero shuffle方案來。

rdd.map(x => (x.charat(0

), x)).countbykey()

//res2: scala.collection.map[char,long] = map(e -> 623689, 2 -> 623914, 5 -> 619840, b -> 626111, 8 -> 620738, d -> 623515, 7 -> 620222, 1 -> 616184, 4 -> 616628, a -> 641623, c -> 630514, 6 -> 621346, f -> 624447, 0 -> 632735, 9 -> 637770, 3 -> 620724)

spark stage gui顯示有關stage id是1,累計耗時只有0.3s,沒有shuffle read/write。這個方案有關的rdd只有narrow dependency,所以只有1個stage。

stage id

description

submitted

duration

tasks: succeeded/total

shuffle read

shuffle write

countbykey at :15      

2014/09/03 20:45:02

0.3 s

8/8                     

count at :15      

2014/09/03 20:44:32

8 s比較3種方案

方案

shuffle read

shuffle write

time

slides原始方案

140.2 mb

208.4 mb

5sslides優化方案

50.4 mb

75.6 mb

4.2s

zero shuffle優化方案

0.3s

spark的優化之一是盡可能減少shuffle從而大幅減少緩慢的網路傳輸。熟悉rdd的函式對spark優化有很大幫助。

Spark優化一則 減少Shuffle

破砂鍋用自己3節點的spark集群試驗了這個優化演算法,並進一步找到更快的演算法。測試資料是sogou實驗室的日誌檔案前10000000條資料。目標是對日誌第2列資料,按照第乙個字母合併,得到每個首字母有幾條記錄。所有的方案都重新啟動spark shell,先用以下 把日誌第2列資料cache到記憶...

Mysql的優化一則

目的在於這麼乙個sql語句 select w.from wall w inner join wall category relation r on w.wall id r.wall id where r.category level1 id 39 and w.is online 1 order by...

Mysql的優化一則

目的在於這麼乙個sql語句 1 select w.from wall w inner join wall category relation r on w.wall id r.wall id where r.category level1 id 39 and w.is online 1 order ...