Hadoop разделяет ключи на несколько пулов редукторов?

Question

Я пытаюсь запустить задание hadoop на очень большом количестве данных, используя до 32 редукторов.Но когда я просматриваю выходные данные для каждого редуктора, я вижу, что может случиться так, что более одного редуктора получат ключ (конечно, с разными значениями).Можно ли избежать такого поведения при использовании большего количества редукторов?

LE: Я пробовал и использовал класс Text вместо этого, но проблема в том, что, хотя он работает нормально, мой jvm в конечном итоге падает из-за нехватки места в куче.Какие критерии использует hadoop для разделения данных на пулы ключей, кроме CompareTo?

Answer 1

Вы говорите, что у вас есть собственный ключ (который реализует WritableComparable), вы переопределили метод hashCode()?

Если вы используете HashPartitioner (который используется по умолчанию), и не переопределяетеметод hashCode() в вашем настраиваемом ключе, а затем два идентичных ключа от разных преобразователей, скорее всего, перейдут к разным редукторам (результат hashCode () по модулю с числом редукторов, чтобы определить редуктор для отправки ключа /значение пары к).Это связано с тем, что по умолчанию метод hashCode () является нативным и возвращает адрес в памяти объекта

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

public int hashCode() {
    return field1.hashCode() + field2.hashCode()
}

Answer 2

Я подозреваю, что вы видите спекулятивную казнь.Обычно все значения для данного ключа всегда идут к одному редуктору.От http://developer.yahoo.com/hadoop/tutorial/module4.html:

Спекулятивное выполнение : Одна из проблем системы Hadoop состоит в том, что, разделяя задачи на множество узлов, возможно, что несколько медленных узлов ограничат скоростьостальная часть программы.Например, если один узел имеет медленный дисковый контроллер, то он может считывать свои данные только на 10% скорости всех других узлов.Таким образом, когда 99 задач карты уже завершены, система все еще ожидает регистрации последней задачи карты, которая занимает намного больше времени, чем все другие узлы.

Вынуждая задачи работать изолированно друг от друга,отдельные задачи не знают, откуда поступают их данные.Задачи доверяют платформе Hadoop, чтобы просто предоставить соответствующий вклад.Поэтому один и тот же ввод может обрабатываться несколько раз параллельно, чтобы использовать различия в возможностях машины.Поскольку большинство задач в задании подходят к концу, платформа Hadoop будет планировать избыточные копии оставшихся задач на нескольких узлах, которые не должны выполнять другую работу.Этот процесс известен как умозрительное исполнение.Когда задачи завершаются, они сообщают об этом факту в JobTracker.Какая бы копия задачи ни заканчивалась первой, она становится окончательной.Если другие копии выполнялись спекулятивно, Hadoop говорит TaskTrackers отказаться от задач и отбросить их результаты.Затем редукторы получают свои входные данные от того, какой Mapper успешно завершил, сначала.

Спекулятивное выполнение включено по умолчанию. Вы можете отключить спекулятивное выполнение для картографов и редукторов, установив для параметров mapred.map.tasks.speculative.execution и mapred.reduce.tasks.speculative.execution JobConf значение false, соответственно.