Hadoop - откуда задачи сокращения карты знают, какую часть файла обрабатывать? - PullRequest
Новая
       20

Hadoop - откуда задачи сокращения карты знают, какую часть файла обрабатывать?

3 голосов
/ 17 января 2012

Я начал изучать hadoop, и в настоящее время я пытаюсь обработать файлы журнала, которые не слишком хорошо структурированы - в том смысле, что значение, которое я обычно использую для клавиши M / R, обычно находится в верхней части файл (один раз). Таким образом, в основном моя функция отображения принимает это значение в качестве ключа, а затем сканирует остальную часть файла, чтобы собрать значения, которые необходимо уменьшить. Таким образом, [поддельный] журнал может выглядеть так: 

## log.1
SOME-KEY
2012-01-01 10:00:01 100
2012-01-02 08:48:56 250
2012-01-03 11:01:56 212
.... many more rows

## log.2
A-DIFFERENT-KEY
2012-01-01 10:05:01 111
2012-01-02 16:46:20 241
2012-01-03 11:01:56 287
.... many more rows

## log.3
SOME-KEY
2012-02-01 09:54:01 16
2012-02-02 05:53:56 333
2012-02-03 16:53:40 208
.... many more rows

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

1. Распределение файлов

Учитывая, что HDFS hadoop работает в блоках по 64 МБ (по умолчанию), и каждый файл распределяется по кластеру, могу ли я быть уверен, что правильный ключ будет сопоставлен с правильными числами? То есть, если блок, содержащий ключ, находится в одном узле, а блок, содержащий данные для того же ключа (другая часть одного и того же журнала), находится на другом компьютере - как инфраструктура M / R соответствует двум (если вообще)?

2. Назначение блока

Для текстовых журналов, таких как описанные, как определяется точка среза каждого блока? Это после окончания строки, или точно на 64Mb (бинарный)? Имеет ли это значение? Это относится к моему # 1, где я обеспокоен тем, что правильные значения сопоставляются с правильными ключами по всему кластеру.

3. Файловая структура

Какова оптимальная файловая структура (если таковая имеется) для обработки M / R? Я бы, наверное, меньше волновался, если бы типичный журнал выглядел так: 

A-DIFFERENT-KEY 2012-01-01 10:05:01 111
SOME-KEY        2012-01-02 16:46:20 241
SOME-KEY        2012-01-03 11:01:56 287
A-DIFFERENT-KEY 2012-02-01 09:54:01 16
A-DIFFERENT-KEY 2012-02-02 05:53:56 333
A-DIFFERENT-KEY 2012-02-03 16:53:40 208
...

Однако журналы огромны, и было бы очень дорого (время) преобразовать их в вышеуказанный формат. Должен ли я быть обеспокоен?

4. Распределение вакансий

Назначены ли задания таким образом, что только один JobClient обрабатывает весь файл? Скорее, как ключи / значения согласованы между всеми JobClients? Опять же, я пытаюсь гарантировать, что моя теневая структура журнала все еще дает правильные результаты.

1 Ответ

1 голос
/ 17 января 2012

Учитывая, что HDFS hadoop работает в блоках по 64 МБ (по умолчанию), и каждый файл распределен по кластеру, могу ли я быть уверен, что правильный ключ будет сопоставлен с правильными числами? То есть, если блок, содержащий ключ, находится в одном узле, а блок, содержащий данные для того же ключа (другая часть одного и того же журнала), находится на другом компьютере - как инфраструктура M / R соответствует двум (если вообще)?

Как ключи и значения отображаются, зависит от класса InputFormat. В Hadoop есть пара классов InputFormat, и можно также определить пользовательские классы InputFormat.

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

Может случиться так, что связанные данные в файле журнала, как в OP, могут быть разбиты по блокам, каждый блок будет обрабатываться другим преобразователем, и Hadoop не может их связать. Один из способов - позволить одному преобразователю обработать весь файл с помощью метода FileInputFormat # isSplitable. Это не эффективный подход, если размер файла слишком велик.

Для текстовых журналов, таких как описанные, как определяется точка среза каждого блока? Это после окончания строки, или точно на 64Mb (бинарный)? Имеет ли это значение? Это относится к моему # 1, где я обеспокоен тем, что правильные значения сопоставляются с правильными ключами по всему кластеру.

Каждый блок в HDFS по умолчанию имеет размер точно 64 МБ, если размер файла не превышает 64 МБ или размер блока по умолчанию не был изменен, границы записи не учитываются. Некоторая часть строки на входе может находиться в одном блоке, а остальная часть - в другом. Hadoop понимает границы записей, поэтому даже если запись (строка) разделена на блоки, она все равно будет обрабатываться только одним преобразователем. Для этого может потребоваться передача некоторых данных из следующего блока.

Назначены ли задания таким образом, что только один JobClient обрабатывает весь файл? Скорее, как ключи / значения согласованы между всеми JobClients? Опять же, я пытаюсь гарантировать, что моя теневая структура журнала все еще дает правильные результаты.

Не совсем понятно, что это за запрос. Предложил бы пройтись по некоторым учебникам и вернуться с вопросами.

...