Шаблоны проектирования 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
Недостатки паттерна:
1. Угроза масштабируемости: надо хранить результаты
промежуточных вычислений, пока mapper не обработает
все поданные на него данные.
2. Наличие внутренних состояний внутри mapper создает
возможность появления ошибок связанных с порядком
выполнения.
Одно из решений 1): делать emit после каждых n
обработанных пар <ключ, значение>
In-mapper combining
•
Combiner в MapReduce - оптимизационная опция, поэтому
корректность выполнения алгоритма не должна от него
зависеть.
•
Reducer должен принимать на вход пары <ключ,значение>
того же типа что и пары испускаемые mapper’ом.
Задача
•
Рассмотрим пример, в котором обыграны два этих
правила.
•
Есть много .log документов, хранящих данные вида
<user_id, SpentTime>. Нужно посчитать среднее время
пребывания на сайте.
•
Учесть правило:
Простое решение
Неправильное решение
Неправильное решение
Правильное решение
Еще одно решение
“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
попадают пары <term, Stripe[term1,term2,…]>,
поэтому можно вычислять знаменатель на месте.
Order inversion
•
В случае Pairs нужно проявить изобретательность: идея
этого шаблона состоит в сохранении масштабируемости.
1. Заведем специальные key-value: <(wi,*),1> для подсчета
знаменателя.
2. В reducer введем свой порядок сортировки, чтобы
специальные пары суммировались до вычисления
частот.
3. Определим свой partitioner который будет отправлять
пары с одинаковым первым словом на один reducer.
4. Для правильного порядка сортировки(.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 более прост и потому
популярен.
Вопросы?