Потоковый или пользовательский Jar в Hadoop - PullRequest
Новая
       19

Потоковый или пользовательский Jar в Hadoop

11 голосов
/ 29 июля 2011

Я выполняю потоковое задание в Hadoop (на Amazon EMR) с картографом и редуктором, написанным на Python.Я хочу знать о приросте скорости, который я получил бы, если бы я внедрил тот же самый маппер и редуктор в Java (или использовал Pig).

В частности, я ищу опыт людей по переходу с потоковой передачи на пользовательский jarразвертывания и / или Свинья, а также документы, содержащие сравнительные сравнения этих параметров.Я нашел этот вопрос , но ответы для меня недостаточно конкретны.Я не ищу сравнений между Java и Python, но сравниваю развертывание пользовательских jar-файлов в Hadoop и потоковую передачу на основе Python.

Моя работа заключается в чтении подсчетов NGram из набора данных Google Books NGgram и вычислении совокупных показателей.Похоже, загрузка процессора на вычислительных узлах близка к 100%.(Хотелось бы услышать ваше мнение о различиях, связанных с работой с процессором или с IO).

Спасибо!

Amaç

1 Ответ

4 голосов
/ 31 июля 2011

Почему стоит рассмотреть возможность развертывания пользовательских банок?

  • Возможность использовать более мощные пользовательские форматы ввода. Для потоковых заданий, даже если вы используете подключаемый ввод / вывод, как упомянуто здесь , вы ограничены тем, что ключ и значения для вашего преобразователя / редуктора являются текстом / строкой. Вам потребуется потратить некоторое количество циклов ЦП, чтобы преобразовать в требуемый тип.
  • Я также слышал, что Hadoop умеет многократно использовать JVM для нескольких заданий, что невозможно при потоковой передаче (не могу этого подтвердить)

Когда использовать свинью?

  • Pig Latin довольно крутой и является языком потоков данных гораздо более высокого уровня, чем java / python или perl. Ваши сценарии Pig будут иметь тенденцию быть намного меньше, чем эквивалентные задачи, написанные на любом из других языков

Когда НЕ использовать свинью?

  • Даже несмотря на то, что свинья довольно хорошо умеет сама определять, сколько карт / сокращений и когда порождать карту или уменьшать и множество таких вещей, если вы мертвы, убедитесь, сколько карт / сокращений вам нужно, и у вас есть несколько очень специфические вычисления, которые вы должны выполнять в функциях Map / Reduce, и вы очень точно относитесь к производительности, тогда вам следует рассмотреть возможность развертывания собственных jar-файлов. Эта ссылка показывает, что свинья может отставать по производительности от собственного hadoop M / R. Вы также можете взглянуть на написание своих собственных Pig UDF , которые изолируют некоторые вычислительные функции (и, возможно, даже используют JNI для вызова некоторого собственного кода C / C ++ в UDF)

Примечание по заданиям ввода-вывода и ЦП:

  • С технической точки зрения, весь смысл сокращения hadoop и map заключается в распараллеливании интенсивных вычислительных функций, поэтому я бы предположил, что ваша карта и сокращение заданий требуют интенсивных вычислений. Единственный раз, когда подсистема Hadoop занята выполнением ввода-вывода, находится между картой и фазой сокращения, когда данные передаются по сети. Также, если у вас большой объем данных, и вы вручную сконфигурировали слишком мало карт и уменьшите их, что приведет к разливу на диск (хотя слишком большое количество задач приведет к слишком большому времени, затраченному на запуск / остановку JVM, и слишком большому количеству небольших файлов). Потоковое задание также будет иметь дополнительные накладные расходы на запуск виртуальной машины Python / Perl и иметь данные, которые копируются туда и обратно между JVM и скриптовой виртуальной машиной.
...