Блог

Главная - Вопросы по программированию - Почему RDD работает медленнее, чем обычный список в spark?

Почему RDD работает медленнее, чем обычный список в spark?

#scala #apache-spark

#scala #apache-spark

Вопрос:

Я хотел сравнить эффективность RDD по сравнению с обычным List в scala spark.

 val list = Range(1, 1000000, 1)
val dist_list = sc.parallelize(list)

val start_time = System.nanoTime
val sum = list.reduce((x,y) => x y)
println(s"for list time is      ${System.nanoTime - start_time}")

val s_time = System.nanoTime
val dist_sum = dist_list.reduce((x,y) => x y)
println(s"for dist_list time is ${System.nanoTime - s_time}")

и получил результат

 for list time is      24849500
for dist_list time is 378051900

что означает, что RDD в 15 раз медленнее, чем обычные операции. Почему это могло произойти?

Комментарии:

1. Ожидаете ли вы, что ваш код RDD будет превосходить версию списка? Почему?

2. Это распространенное заблуждение. Должен существовать порог, при достижении которого распараллеливание операций становится оптимальным. Простое распараллеливание операций увеличивает накладные расходы, связанные с планированием параллельных задач. Если набор данных не достаточно велик, чтобы уменьшить эти накладные расходы, использование нескольких потоков действительно может замедлить вашу работу. И это даже не говоря о более сложной системе планирования Spark. Другими словами, ваши предположения и ожидания не совсем верны. На что вы можете рассчитывать, так это на то, что чем больше набор данных, тем больше вероятность того, что Spark будет работать лучше, но существует порог, при котором он запускается.

3. Обратите внимание, что это неподходящий способ сравнительного анализа. Кроме того, сколько исполнителей вы настроили? Возможно, он даже выполняется в одном потоке. Наконец, Spark предназначен для распределенных вычислений, а не для параллельных вычислений, если у вас будет только одна машина, тогда вам будет лучше с параллельными коллекциями или фьючерсами .

4. @ernest_k, дело не только в размере набора данных. Для любого набора размеров Int , который вы могли бы разумно ожидать для вычисления суммы в одной JVM (например, ни одно подмножество этих Int s не переполнится), я бы ожидал, что версия без Spark превзойдет Spark, просто потому, что добавление двух целых чисел происходит настолько быстро, что накладные расходы на координацию затмят выполнение дополнений в цикле.

5. @LeviRamsey Правильно. Сокращение этого значения до одной переменной (размера набора данных) было чрезмерным упрощением с моей стороны. Также есть способы управления потоками (Spark или практически любой API параллельного программирования), количество потоков и, конечно, какова сама задача и т. Д. Как вы говорите, добавление миллионов целых чисел почти всегда будет быстрее с одним или несколькими потоками в процессе; но выполнение двух задач, которые занимают по одной минуте каждая, например, вызов медленной веб-службы, очевидно, может быть улучшено с помощью нескольких потоков.

Метки: ,