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

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

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

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

Спасибо!

AMAC

Ответ 1

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

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

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

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

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

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

Примечание о заданиях с привязкой к IO и CPU:

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