[Moscow.pm] Идеальный Map-ер и Reduce-ер

[Ruslan Zakirov]

2009/1/21 Михаил Монашёв <postmaster на softsearch.ru>:
> Здравствуйте, Руслан.
>
> RZ> Я так понимаю, что нужно иметь несколько компонентов:
> RZ> Dispatcher, Mappper, Combiner, Reducer, Reporter
>
> Угу.  Всё  верное. И похоже писать надо все 5 компонентов, а не только
> Mappper и Reducer.
>
> RZ> И однозначно нужно иметь расшареное хранилище с локальным куском на
> RZ> каждой работающей машине. Для эффективности нужно знать куда попал
> RZ> кусок, когда мы его запихнули в хранилище.
>
> RZ> Например: у нас есть результат мапинга и комбинирования (key1 =>
> RZ> [val1, val1, val1]) вот мы его и запихиваем это в хранилище под ключом
> RZ> taks-123-mapped-<key1>. Если мы знаем алгоритм распределения в
> RZ> хранилище, то мы знаем, что все результаты необходимые для reducer'ов
> RZ> собрались на одной ноде и можем ее определить и отдать задачу на
> RZ> reduce конкретно данной ноде.
>
> Cache::Memcaced::Fast может класть сразу в нужное хранилище в виде
> MemcacheBD.

В доке к MCDB я увидел, что там репликация master->slave и так понял,
что репликация 1-н к 1-му. Вы предлагаете поднимать несколько MCDB и с
помощью C::M::F конектиться к ним без шаринга данных между этими БД?

Тут возникает заковыка небольшая. Так как MCDB в общем не предназначен
для хранения больших записей, то ключ придется менять используя
main-key-xxx, где xxx атомарный счетчик иначе поле мапа записи могут
стать очень большими.

>
> RZ> Мне кажется, что dispatcher тоже должен складывать задачи в хранилище.
> RZ> И когда к нему приходят ноды и говорят, что им нужна задача, то
> RZ> диспетчер по возможности выдает ключ от задачки с этой ноды. Простоя
> RZ> быть не должно и если на этой ноде нет ничего, то можно выдать любой
> RZ> другой ключик и тогда будет перенос данных по сети.
>
> Диспатчеры,  ИМХО, должны не перекладывать из хранилища в хранилище, а
> обращаться  к  локальным  хранилищам, читать из них данные, и если они
> имеются, запускать маперов и давать им на вход поток этих данных.

Моя идея была в том, что диспатчер находится вне работающих нод.
Рассмотрим пример с одним диспечером. Есть какая-то группа работяг,
которые умеют делать набор операции X, допустим нам нужно посчитать
статистику по IP из логов апача за месяц и это операция x1. Мы заходим
на диспечер и запускаем операцию x1 на файл f1. Диспечер режет от лога
1M плюс пару байт дойти до конца строки. Берет этот чанк и кладет в БД
под ключом x1-block1, внутри может быть дополнительная информация,
типа названия операции, адреса диспечера и так далее. Свободные ноды
обращаются к диспечеру, он им дает ключ и что сделать(map, reduce,
report), после выполнения нода должна отчитаться за ключ.

Какие задачи решает диспетчер:
* самое главное: определение завершения этапов map, reduce. Ведь в
общем случае MapReduce не потоковый, например "подсчет слов" или
"статистка" по хостам. Да, вы можете начать комбинировать до получения
всех данных, но вот результат даже по одному ключу получить не можете,
пока не закончен этап map для всего задания.

Дополнительно:
* запуск заданий в возможно уже нагруженную систему
* параметризация заданний
* приоритезация заданий
* распределение нагрузки
* контроль выполнения
** тайм-ауты
** повторный запуск в случае ошибок
** остановка задачи если что-то сломалось и много блоков не обработано
** перезапуск (например обновили все ноды)
* статистика
* даже можно загружать новые или обновления модулей с него

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

>
> А для очереди задач есть MemcacheQ. От автора MemcacheBD. Правда я
> пока не вникал как у MemcacheQ с устойчивостью к падениям...
>
>
> --
>
> С уважением,
> Михаил Монашёв, SoftSearch.ru
> mailto:postmaster на softsearch.ru
> ICQ# 166233339
> http://michael.mindmix.ru/
> Без бэкапа по жизни.
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
Best regards, Ruslan.