ReduceByKey и parititionBy в Spark

Question

В книге Learning Spark пишут:

Для операций, которые действуют на один RDD, таких как lowerByKey (), выполнение на предварительно разделенном RDD вызовет всезначения для каждого ключа, которые должны быть вычислены локально на одном компьютере, требуя, чтобы только конечное локально уменьшенное значение было отправлено с каждого рабочего узла обратно на мастер.

Однаков этом ответе , о котором говорит автор, предварительное разбиение не требуется, потому что:

Для lowerByKey () первое качество объединяет элементы одного и того же ключа с предоставленнымфункция ассоциативного сокращения локально сначала для каждого исполнителя, а затем в конечном итоге агрегируется для всех исполнителей.

Итак, почему в книге предлагается предварительное разбиение, если в любом случае метод limitByKey () объединяет элементы в каждомисполнитель первым без перетасовки данных?

Answer 1

Ответ, приведенный выше, суммировал методы DuceByKey и partitionBy.

Чтобы ответить на ваш вопрос, вам не нужно применять partitionBy перед вызовом reduByKey.

Answer 2

Книга действительно не предлагает предварительное разбиение.Он описывает только поведение *ByKey методов при применении к секционированным RDD.Учитывая, что само разбиение - это случайное перемешивание , заключение о том, что вы должны превентивно разделить ваши данные для одного reduceByKey, неоправданно.

На самом деле, еслиданные содержат N значений с K уникальными ключами и P разделами, размер шаффла в сценарии reduceByKey ∘ partitionBy всегда больше и равен размеруперемешивание только с reduceByKey.

Если вы собираетесь подать кратную амортизированную стоимость partitionBy, за которой следует набор *byKey или *Join приложений, может быть ниже, чемстоимость применения *byKey методов.Точно так же, если вы уже перетасовали данные как часть другой операции и собираетесь применить операцию перетасовки позже, вам следует попытаться сохранить существующее разбиение.Это, однако, не означает, что вы всегда должны предпочитать сначала partitionBy.