Презентация на тему Шаблоны проектирования Hadoop MapReduce

Шаблоны проектирования Hadoop MapReduce

Сильвестров Алексей

26 апреля 2011 г

Введение
In-mapper combining
“Pairs” and “stripes”
Order inversion
Value-to-key conversion
Базы данных: map-side join, reduce-side join

План доклада

Архитектура MapReduce

Задача

Подсчитать количество вхождений всех слов в наборе документов {d1,d2,…}

Типичное решение

In-mapper combining

In-mapper combining

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

Одно из решений 1): делать emit после каждых n обработанных пар <ключ, значение>

In-mapper combining

Combiner в MapReduce - оптимизационная опция, поэтому корректность выполнения алгоритма не должна от него зависеть.
Reducer должен принимать на вход пары <ключ,значение> того же типа что и пары испускаемые mapper’ом.

Задача

Рассмотрим пример, в котором обыграны два этих правила.
Есть много .log документов, хранящих данные вида . Нужно посчитать среднее время пребывания на сайте.
Учесть правило:

Простое решение

Неправильное решение

Неправильное решение

Правильное решение

Еще одно решение

“Pairs” и “stripes”

Учебник Python 3 покупают вместе с K&R, но никогда наоборот. Учебник SICP не покупают вместе с “Мечты роботов” Азимова.
Нужно построить матрицу совместных покупок с помощью паттерна pairs или с помощью паттерна stripes.

“Pairs” и “stripes”

Pairs:

“Pairs” и “stripes”

Stripes:

“Pairs” и “stripes”

Очевидно, что “pairs” генерирует намного больше пар <ключ,значение>, чем “stripes”.
Реализация “stripes” компактна, но сложна.
Реализация “stripes” требует временного хранения данных.
Combiner в “stripes” имеет больше возможностей для выполнения локальной агрегации.

“Pairs” и “stripes”

“Pairs” и “stripes”

Order inversion

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

Order inversion

Возникает проблема: как подсчитать знаменатель?
С помощью шаблона “Stripes”: в reducer попадают пары , поэтому можно вычислять знаменатель на месте.

Order inversion

В случае Pairs нужно проявить изобретательность: идея этого шаблона состоит в сохранении масштабируемости.
Заведем специальные key-value: <(wi,*),1> для подсчета знаменателя.
В reducer введем свой порядок сортировки, чтобы специальные пары суммировались до вычисления частот.
Определим свой partitioner который будет отправлять пары с одинаковым первым словом на один reducer.
Для правильного порядка сортировки(.2) заведем состояния в reducer.

Order inversion

Пример:

Value-to-key conversion

Рассмотрим пример: m сенсоров считывают некие данные, t – timestamp, Rx – данные.






Выделим работу одного сенсора с помощью Map:


Т.е. Reducer получит данные с конкретного сенсора, не отсортированные по timestamp’ам.

Value-to-key conversion

Очевидное решение: буферизовать данные и затем сортировать их по timestamp – потенциальная угроза масштабируемости.

Value-to-key conversion : в паре <ключ, значение> часть значения переносится в ключ, проблемы сортировки возлагаются на MapReduce:


Таким образом на reduce будут попадать отсортированные по обоим параметрам данные:

Базы данных: реляционные соединения

Hadoop часто используется для хранения данных в форме реляционных баз данных.
Рассмотрим три вида объединения отношений S и T: один к одному, один ко многим, много ко многим.




k – ключ, s – идентификатор кортежа, S и T – остальные атрибуты.

Reduce-side join. Один к одному

Идея Reduce-side join состоит в разбиении данных по ключу на map и объединении на Reduce.
В качестве примера рассмотрим объединение один к одному:





В map стадии k используется как временный ключ, остальное содержимое кортежа - как значение.

Reduce-side join. Один ко многим

Рассмотрим объединение один ко многим: пусть в S k-уникальный ключ, в T – нет.
Простейший выход- хранить оба отношения в памяти, вытаскивать кортеж из S и объединять с каждым кортежем из T - является угрозой масштабируемости.
Здесь понадобится secondary sort и вытекающий из него value-to-key conversion - в mapper создается составной ключ:




Когда бы reducer не получил пару <(k, s), S> гарантируется что ее кортеж S будет сохранен в памяти до появления T кортежа, после чего произойдет объединение.

Reduce-side join. Много ко многим

Много ко многим: в S и T k не являются уникальными ключами:









Для объединения каждого с каждым также используется Value-to-key conversion.

Map-side join

Идея Map-side join состоит в объединении данных на map и и отправке на Reduce.
Пример: S и T разделены на 10 файлов(5 для S и 5 для T), в каждом файле кортежи отсортированы по первичному ключу.
Чтобы выполнить объединение, нужно параллельно обработать файлы S1 и T1, S2 и T2 и т.д. на map-стадии.
Map-side join более эффективен чем Reduce-side, т.к. не требуется передача данных по сети на Reduce узлы.
Однако Reduce-side более прост и потому популярен.

Вопросы?