#hadoop #mapreduce #partitioning
#hadoop #mapreduce #разделение
Вопрос:
Я пытаюсь написать новое задание Hadoop для входных данных, которое несколько искажено. Аналогией для этого может быть пример подсчета слов в учебном пособии по Hadoop, за исключением того, что, допустим, одно конкретное слово присутствует много раз.
Я хочу иметь функцию разделения, в которой этот один ключ будет сопоставлен нескольким редукторам и оставшимся ключам в соответствии с их обычным разделением хэша. Возможно ли это?
Заранее спасибо.
Ответ №1:
Не думайте, что в Hadoop один и тот же ключ может быть сопоставлен нескольким редукторам. Но ключи могут быть разделены так, чтобы редукторы загружались более или менее равномерно. Для этого входные данные должны быть выбраны, а ключи разделены соответствующим образом. Проверьте документ Yahoo для получения более подробной информации о пользовательском разделителе. Код сортировки Yahoo находится в пакете org.apache.hadoop.examples.terasort.
Допустим, ключ A имеет 10 строк, B имеет 20 строк, C имеет 30 строк, а D имеет 60 строк на входе. Затем ключи A, B, C могут быть отправлены в редуктор 1, а ключ D может быть отправлен в редуктор 2, чтобы равномерно распределить нагрузку на редукторы. Для разделения ключей необходимо выполнить выборку входных данных, чтобы узнать, как распределяются ключи.
Вот еще несколько предложений, чтобы ускорить выполнение задания.
Укажите объединитель в JobConf, чтобы уменьшить количество ключей, отправляемых в редуктор. Это также уменьшает сетевой трафик между задачами mapper и reducer. Хотя нет никакой гарантии, что объединитель будет вызван платформой Hadoop.
Кроме того, поскольку данные искажены (некоторые клавиши повторяются снова и снова, скажем, «инструменты»), вы можете увеличить число задач сокращения, чтобы быстрее выполнить задание. Это гарантирует, что, пока редуктор обрабатывает «инструменты», другие данные обрабатываются другими редукторами параллельно.
Комментарии:
1. Быстрый вопрос, есть ли какие-либо другие преимущества в производительности от равномерного распределения, кроме уменьшения количества сокращений, чтобы избежать ненужной обработки?
2. не понимаю, как равномерное распределение связано с ненужной обработкой в задаче редуктора — равномерное распределение нагрузки на редукторы обеспечит более быстрое выполнение задания. В противном случае на общее время выполнения задания будет влиять редуктор, который занимает больше всего времени. По этой причине Hadoop поддерживает спекулятивное выполнение , что неэффективно.
Ответ №2:
Если вы разделяете свои данные на несколько редукторов по соображениям производительности, вам понадобится второй редуктор для объединения данных в конечный набор результатов.
В Hadoop есть встроенная функция, которая делает что-то подобное: объединитель.
Объединитель — это функциональность типа «редуктор». Это гарантирует, что в рамках задачи map может быть выполнено частичное сокращение данных и, как таковое, уменьшает количество записей, которые необходимо обработать позже.
В базовом примере wordcount объединитель точно такой же, как и редуктор. Обратите внимание, что для некоторых алгоритмов вам потребуется другая реализация для этих двух. У меня также был проект, в котором объединитель был невозможен из-за алгоритма.
Комментарии:
1. Не уверен, что один и тот же ключ может быть разделен на несколько редукторов, поэтому опция второго редуктора (M -> R -> R) может не возникнуть. Когда данные очень и очень большие, пользовательский разделитель с выборкой входных данных может быть лучшим выбором, как это сделано в Y! Сортировка Tera.
2. почему бы и нет? getPartition() получает ключ и значение в качестве параметров и возвращает целое число. Я полагаю, что решение о возврате раздела на основе значения, а не ключа, зависит от программиста. Пример можно найти здесь: hadooptutorial.wikispaces.com/Custom разделитель