Использование Pig / Hive для обработки данных вместо прямой Java-карты уменьшает код?

Question

(Еще более простой, чем Разница между Pig и Hive? Почему есть и то и другое? )

У меня есть конвейер обработки данных, написанный на нескольких Java map-Reduce задачи над Hadoop (мой собственный код, полученный из Hadoop's Mapper и Reducer).Это ряд основных операций, таких как соединение, обратное, сортировка и группировка по.Мой код задействован и не очень общий.

Каковы плюсы и минусы продолжения этого общепризнанного подхода, интенсивно развивающегося, по сравнению с переносом всего на Pig / Hive с несколькими UDF?какие работы я не смогу выполнить?я буду страдать от снижения производительности (работая с сотнями ТБ)?я потеряю способность настраивать и отлаживать мой код при обслуживании?смогу ли я транслировать часть заданий как Java map-Reduce и использовать их ввод-вывод с моими заданиями Pig / Hive?

Answer 1

Ссылка Twitter : Как правило, сценарий Pig составляет 5% кода собственной карты / редукции, написанного примерно в 5% времени. Однако для выполнения запросов обычно требуется от 110 до 150% времени, которое потребовалось бы для задания родного сопоставления / сокращения. Но, конечно, если есть подпрограмма, которая очень чувствительна к производительности, у них все еще есть возможность вручную закодировать нативную карту / уменьшить функции.

Приведенная выше ссылка также рассказывает о плюсах и минусах Pig в разработке приложений в MapReduce.

Как и в случае любого языка или абстракции более высокого уровня, гибкость и производительность теряются в Pig / Hive за счет производительности разработчика.

Answer 2

В этой статье по состоянию на 2009 г. указано, что Pig работает в 1,5 раза медленнее, чем обычный MapReduce. Ожидается, что инструменты более высокого уровня, построенные поверх Hadoop, работают медленнее, чем обычный MapReduce, однако верно, что для оптимального выполнения MapReduce требуется опытный пользователь, который пишет много стандартного кода (например, двоичные компараторы).

Я считаю уместным упомянуть новый API под названием Pangool (разработчиком которого я являюсь), целью которого является замена простого Hadoop MapReduce API путем упрощения написания и понимания многих вещей ( вторичная сортировка, соединения со стороны уменьшения). Pangool не налагает накладных расходов на производительность (всего 5% по сравнению с первым тестом ) и сохраняет всю гибкость оригинального API MapRed.