Как отладить зависание Pig после отправки задания

У меня есть работа по уменьшению карты, написанная на Pig, которая делает следующее.

Учитывая набор файлов журнала Apache, представляющих посещения определенного ресурса на веб-сайте.

  • очистить логи от роботов и от ненужных строк логов
  • создавать кортежи (ip, resource_id), найденные в журналах

Например, этот журнал:
1.1.1.1 - [14/Jun/2014:06:26:27 +0000] "GET /path/to/resource/<resource_id>" "Agent"

будет переведено в (если это не робот):
(1.1.1.1, <resource_id>)

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

Проблема заключается в следующем:

  • Я могу выполнить работу свиньи на месте.
  • Я загрузил скрипт в Amazon Elastic Map Reduce с 5 ГБ журналов для обработки.
  • Я запустил скрипт на 1 час с 10 m1.large экземплярами.
  • Работа не была закончена, и я прекратил ее.

Созданные журналы Hadoop не показывают большого прогресса и, похоже, застряли на начальной стадии подготовки, описанной ранее.

2014-07-07 06:31:17,609 [main] INFO org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.MapReduceLauncher - detailed locations: M: pre1[4,7],pre2[-1,-1],pre3[7,7],pre4[8,7],r2[13,5] C: R: r5[-1,-1] 2014-07-07 06:31:17,661 [main] INFO org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.MapReduceLauncher - 0% complete

Как бы вы предложили отладить проблему, начиная с этого момента?
Считаете ли вы, что с учетом размера данных количество машин является разумным?
Я действительно ожидал, что закончу работу за такое количество времени.

Спасибо


apache-pig elastic-map-reduce
person mottalrd    schedule 07.07.2014    source источник
comment
Есть ли у вас доступ к JobTracker, чтобы вы могли детально отслеживать каждую задачу? Вы должны быть в состоянии пройти 5 ГБ за 1 час на своей собственной машине, не говоря уже о 10 экземплярах Amazon...   -  person reo katoa    schedule 07.07.2014
comment
Я вижу папку журнала task-attempts. Внутри у меня есть все подробности различных выполняемых задач (cl.ly/image/122g2G3x221X) . Каждый из них выглядит следующим образом ===> Открытие 's3n://path/to/log/access.log.22' для чтения [...] Псевдонимы, обрабатываемые на этапе задания (Имя псевдонима [строка, смещение]): М: пре1[4,7],пре2[-1,-1],пре3[7,7],пре4[8,7],r2[13,5] C: R: r5[-1,-1] 07.07.2014 06:33:09,202 ИНФОРМАЦИЯ [Thread-5] amazon.emr.metrics.MetricsUtil: состояние контроллера экземпляра завершено 07.07.2014 06:33:09,809 INFO [Thread-5] amazon.emr.metrics. MetricsSaver: показатели EMR отключены   -  person mottalrd    schedule 07.07.2014
comment
Я видел подобное поведение при работе с большим количеством небольших файлов в S3 (файлы не распределяются одинаково между картографами). Наблюдаете ли вы такое же поведение при копировании файлов из S3 в HDFS (таким образом вы можете комбинировать небольшие файлы) с помощью s3distcp (docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/)?   -  person user2303197    schedule 07.07.2014

Ответы (1)


arrow_upward
0
arrow_downward

Если у вас есть огромное количество файлов журналов, я могу предположить, что обработка может быть медленной. В этом случае вы можете объединить их перед размещением на HDFS. Общий объем 5 ГБ не должен быть проблемой для простого скрипта синтаксического анализа на таком оборудовании.

Общим следующим шагом для такого рода ситуаций было бы уменьшение проблемы.

  1. Работает ли это на амазоне, если вы просто скармливаете ему несколько небольших файлов вместо 5 ГБ.
  2. Если да, то как увеличится время выполнения, если вы сначала дадите ему 1%, затем 2%, а затем 10%?
  3. Если это не сработает, что произойдет, если вы сделаете свою функцию синтаксического анализа тривиальной или вообще ее пропустите?
person Dennis Jaheruddin    schedule 14.03.2016