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

Я начал изучать 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. Назначение блока

Для текстовых журналов, подобных описанным, как определяется точка отсечки каждого блока? Это после окончания строки или точно на 64 Мб (бинарный)? Это даже имеет значение? Это относится к моему № 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? Опять же, я пытаюсь гарантировать, что моя теневая структура журнала по-прежнему дает правильные результаты.

sa125 17.01.2012 источник

Ответы (1)

arrow_upward
1
arrow_downward

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

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

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

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

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

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