Привязка к выводу Pig STORE или DUMP в Python

Я ищу «правильный» способ написать код Python, который может работать с выходными данными заданий Pig.

Вот моя ситуация. Я написал сценарий Pig для обработки большого количества данных и вывода небольшого набора отношений. Объем выходных данных достаточно мал, чтобы их можно было сбросить на консоль напрямую. Например.:

grunt> DUMP results
(Control, column1, column2, column3, column4, column5, column6)
(Treatment1, column1, column2, column3, column4, column5, column6)
(Treatment2, column1, column2, column3, column4, column5, column6)
(Treatment3, column1, column2, column3, column4, column5, column6)
grunt>

В качестве следующего шага я хочу сделать несколько вычислений чисел в отношениях, например вычисление p-vals для значимости наблюдаемых результатов лечения. Я бы очень хотел использовать для этого Python: сам Pig явно не предназначен для такого рода задач, и я бы предпочел не переписывать существующий код на Java. Итак, что я хотел бы сделать, так это привязать к выходам команды STORE или DUMP из python каким-то образом и продолжить с этим. Моя проблема заключается в том, чтобы найти лучший способ двигаться вперед. Вот как я могу видеть:

  1. Используйте Python, чтобы написать UDF, который будет выполнять вычисления. Я могу сделать это; на самом деле мой скрипт Pig уже вызывает пару UDF Python. Однако у меня сложилось впечатление, что UDF предназначены для работы с одним отношением / строкой ввода за раз, и мне нужно получать данные из нескольких отношений для достижения моей цели. Я могу собрать какое-то хранилище состояний внутри UDF между вызовами, но это не кажется правильным решением.
  2. Используйте встроенный Python через Jython в Pig 0.9.1. Я возлагал большие надежды на этот подход, но из ограниченной документации, которую я нашел по этой функции, кажется, что он предназначен в первую очередь для управления потоком заданий (канонический пример - обнаружение сходимости в интерактивных алгоритмах), а не для работы с выходными данными напрямую. В частности, я вижу документацию о том, как привязать к метаданным задания, например, удалось ли оно успешно или нет, но не о том, как привязать к выходным данным. Хотел бы быть доказанным, что ошибаюсь в этом.
  3. Попросите сценарий Python вызвать Pig и передать ему локальные или HDFS-пути желаемых выходных местоположений, ожидая завершения задания и затем используя Python для чтения / анализа отношений из этих путей. Кажется действительно хакерским.

Есть ли очевидный вариант, который мне не хватает, или большой пробел в моем понимании вышеперечисленных вариантов? Будем рады вашим отзывам!


python apache-pig
person Inverseofverse    schedule 12.01.2012    source источник
comment
Я не знаю, как это сделать с помощью pig, но mrjob yelp - это именно то, что вы просите на # 3 в потоковой передаче hadoop. вероятно, можно как-то также использовать свинью. Google показывает несколько результатов людей, которые просят именно об этом. Хотя пример Дональда Майнера мне кажется более простым.   -  person BenH    schedule 19.04.2013

Ответы (1)


arrow_upward
3
arrow_downward

Я понимаю ваше разочарование по личному опыту. №3 - на самом деле очень разумный подход, однако я предлагаю немного другое. Вместо этого используйте оболочку сценария bash для выполнения обоих. У этого есть приятная особенность, заключающаяся в том, что вам не придется выполнять все неудобные вызовы оболочки через python.

Что-то вроде:

pig mypigscript.pig ...
mkdir /tmp/pigout/
hadoop fs -get output/part* /tmp/pigout/
cat /tmp/pigout/* | python mypostprocessing.py

Хорошая вещь в этом подходе заключается в том, что вы можете по-настоящему фантазировать с параметрами, журналированием и т. Д. В производственной среде я обычно записываю все различные фазы в файлы журналов, проверяю наличие ошибок фаз и т. Д.

Просто чтобы убедить вас, что это правильный подход - вам не нужна эта небольшая обработка нескольких записей в редукторе. Это не сработает, если у вас несколько редукторов, и на самом деле ничего вам не даст, потому что вы не используете параллелизм. Я думаю, что люди склонны пытаться объединить слишком много своих вычислений в Hadoop и не делать некоторые из простых очевидных вещей извне.

person Donald Miner    schedule 13.01.2012
comment
Спасибо за содержательный ответ. Я полностью осознаю безрассудство обработки мелкой рыбы в редукторах Hadoop вместо того, чтобы переносить результаты в более общую вычислительную среду. Я надеялся найти более разумный способ их взаимодействия; как вы указываете, №3, вероятно, лучший, хотя и далек от идеала. Благодарим вас также за предложение обернуть сценарий оболочки вокруг двух - это хорошая идея, которая сделает все проще и понятнее. - person Inverseofverse; 14.01.2012