Восстановить стандарт из неудачного задания Hadoop

Question

Я выполняю большое потоковое задание Hadoop, где обрабатываю большой список файлов, каждый из которых обрабатывается как единое целое.Для этого мой вход в потоковое задание представляет собой один файл со списком всех имен файлов в отдельных строках.

В общем, это работает хорошо.Тем не менее, я столкнулся с проблемой, когда частично прошел большую работу (~ 36%), когда Hadoop столкнулся с некоторыми файлами с проблемами, и по какой-то причине он, похоже, вылетел из-за всей работы.Если задание выполнено успешно, то для стандартного вывода будет напечатана строка для каждого файла, поскольку она была завершена вместе с некоторыми статистическими данными из моей программы, которая обрабатывает каждый файл.Тем не менее, с этой неудачной работой, когда я пытаюсь посмотреть вывод, который был бы отправлен на стандартный вывод, он пуст.Я знаю, что примерно 36% файлов были обработаны (потому что я сохраняю данные в базе данных), но мне нелегко составить список, какие файлы были успешно обработаны, а какие остались.Можно ли как-нибудь восстановить эту запись в стандартном режиме?

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

Спасибо за любые предложения.

Answer 1

Hadoop захватывает данные system.out здесь:

/ мнт / Hadoop / журналы / userlogs / TASK_ID

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

Для каждого из ваших документов вы можете суммировать характеристики документа: например, длину, количество обычных символов ascii, количество новых строк.

Тогда вы можете иметь 2 счетчика: счетчик «хороших» файлов и счетчик «плохих» файлов.

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

Наконец, вам, очевидно, придется посмотреть на результаты после выполнения задания.

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

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

Сценарий WORST CASE: ВАМ ДЕЙСТВИТЕЛЬНО НУЖЕН ОТЛАДКА ТЕКСТА, и вы не хотите его во временном файле

В этом случае вы можете использовать MultipleOutputs для записи вспомогательных файлов с другими данными в них. Вы можете отправлять записи в эти файлы так же, как и для данных part-r-0000 *.

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