Организация процесса регулярной обработки больших...

Организация процесса

регулярной обработки

больших объемов данных

Группа разработки Крипта

Дмитрий Кукса, разработчик

Что такое Крипта?

▌ Отвечает на вопрос – «Кто?»

▌ Определяет характеристики

пользователя по поведению в

интернете

▌ Используется для таргетинга рекламы

Как это работает?

▌ Объем регулярно обрабатываемых данных ~ 50 ТБ/час

6

Логи

Обучение Контроль

Логи Профили

Профили

+

Матрикснет

Матрикснет

ОбучениеКлассификация

MapReduce

7

MapReduce

8

▌ Модель распределенных вычислений

▌ Входные / выходные данные – пары (k, v)

▌ Две основных операции:

Map: (k, v) → {(k1*, v1*), …, (kn*, vn*)}

Reduce: (k, {v1, …, vm}) → {(k1*, v1*), …, (kn*, vn*)}

▌ Фреймворки – YT, Hadoop (http://hadoop.apache.org)

http://hadoop.apache.org/

9

Inputs

id1, [email protected]






10

Inputs Map




gmail.com, 1

gmail.com, 1

yandex.ru, 1

mail.ru, 1

yandex.ru, 1

yandex.ru, 1




11

Inputs Map Group




gmail.com, 1

gmail.com, 1

yandex.ru, 1yandex.ru, {1 ,1, 1}

mail.ru, 1

yandex.ru, 1

yandex.ru, 1

gmail.ru, {1, 1}

mail.ru, {1}id3, [email protected]



12

Inputs Map ReduceGroup




gmail.com, 1

gmail.com, 1

yandex.ru, 1yandex.ru, {1 ,1, 1}

mail.ru, 1

yandex.ru, 1

yandex.ru, 1

gmail.ru, {1, 1}

mail.ru, {1}

yandex.ru, 3

gmail.ru, 2

mail.ru, 1id3, [email protected]



Что обеспечивает MR?

▌ Распределение задач между узлами

▌ Распределенное хранение данных

▌ Группировка данных перед Reduce

▌ Cортировки и слияния

▌ Отказоустойчивость

13

Так все ОК, MapReduce все сделает!

14

,

, ,

Клиент - Сервер

15

▌ Задачу на выполнение мастеру MR ставит клиент

▌ Проблемы

Потеря канала связи между сервером и клиентом

Отказ машины клиента

В этом месте MR ничего не гарантирует!

Что нужно для хорошей жизни?

▌ Выполнение задачи ровно один раз в час/день/неделю

▌ Недопустимы потери данных

▌ Допустима задержка в обработке

▌ Минимальное количество вмешательств «руками»

▌ Информирование о необходимости ручного вмешательства

16

Комплекс решений

▌ Конкурирующий запуск с нескольких клиентов

▌ Автоматическое восстановление задачи при падении

▌ Система мониторинга

17

Аспекты

18

АОП

▌ Инкапсуляция кода, не имеющего отношения к бизнес логике

▌ Часто – выполнение действий «до» и «после»

▌ Логирование, авторизация, транзакционный контроль

19

АспектыRun() {

RunTask();

}

RunTask() {

RunOperation();

}

Аспекты. MonitoringRun() {

MonitoringBefore(); // Логирование

RunTask();

MonitoringAfter(); // Логирование

}

RunTask() {


RunOperation();


}

Аспекты. Monitoring

22

Monitoring

Application

Аспекты. BlockerRun() {

BlockerBefore(); // Проверка возможности запуска. Блокировка


RunTask();


BlockerAfter(); // Снятие блокировки

}

RunTask() {


RunOperation();


}

Аспекты. Blocker

24

▌ Разделяемое состояние – YT таблица

Time – время блокировки

▌ Пролонгация во время работы

▌ Мьютекс с протуханием

▌ Нет лишних точек отказа

Time = 00:15 24-02-2015

Аспекты. Blocker

25

▌ Не чаще раза в сутки – блокировка

▌ Done – флаг завершения

▌ Решает проблемы:

Одновременного запуска

Выполнения по расписанию

Time = 00:00 25-02-2015

Done = true

Аспекты. Raise UpRun() {

BlockerBefore(); // Проверка возможности запуска. Блокировка

RaiseUpBefore(); // Определение контекста задачи. Сохранение


RunTask();


RaiseUpAfter(); // Удаление контекста

BlockerAfter(); // Снятие блокировки

}

RunTask() {

RaiseUpBefore(); // Определение контекста задачи. Сохранение


RunOperation();


RaiseUpAfter(); // Запись информации об окончании

}

Аспекты. Raise Up

27

▌ Контекст задачи

Аргументы бинарника

▌ Контекст операции

Входные таблицы

1

Tmp_123 Tmp_042

2

Failed start Current start

2

1

Аспекты. Raise Up

▌ Разделяемое состояние – журнал (YT)

▌ Задача - воссоздание условий упавшего запуска

▌ Выполнение только незавершенных операций

▌ Запускается тот же бинарник

▌ Единственный механизм влияния – аспекты

28

Raise Up. Нормальное исполнение

29

Task -src //crypta/fresh/offers/

-dst //crypta/state/

-ts 1424791640


30

Task

operation_1

-src //crypta/fresh/offers/


-ts 1424791640

Name = operation_1

Src = //crypta/fresh/offers/1

Dst = //crypta/state/offers_123


31

Task

operation_1



-ts 1424791640

Name = operation_1



Done = true


32

Task

operation_1

operation_2



-ts 1424791640

Name = operation_1



Done = true

Name = operation_2

Src = //crypta/state/offers_123

Dst = //crypta/state/accum


33

Task

operation_1

operation_2



-ts 1424791640

Name = operation_1



Done = true

Name = operation_2




34

Task

operation_1

operation_2



-ts 1424791640

-failures 1

Name = operation_1



Done = true

Name = operation_2



Аспекты

▌ Blocker, RaiseUp, Monitoring

▌ Довольно простые механизмы

▌ Не порождают ненужных зависимостей

35

А что насчет цепочки?

36

Цепочки задач

▌ Скрипт

▌ Нужна поддержка аспектов (запуск с помощью бинарника)

▌ В целом - все аналогично бинарнику

37

Цепочки задач. Восстановление

38

2

падения

8

падений--- ---

10

падений


39

2

падения

8

падений--- ---

10

падений

force_drop_journal = true


40

17:00 17:00 --- 16:00

skip executeСтарт 16:30 skip execute


41

17:00 17:00 --- 16:00

executeСтарт 16:30

executeСтарт 17:00

executeskip skip

executeexecute


42

17:00 17:00 --- 16:00

skip executeСтарт 16:30 skip

executeСтарт 17:00 executeexecute

До упавшей задачи - пропускать сделанные

execute

skip_done

true


43

17:00 17:00 --- 16:00

skip executeСтарт 16:30 skip

executeСтарт 17:00 executeexecute

До упавшей задачи - пропускать сделанные

После – исполнять

execute

skip_done

true

skip_done

false

Цепочки задач. Режимы запуска

44

▌ Необходимо изменять параметры аспектов по ходу цепочки

▌ Режимы

Schedule (force_drop_journal = true, skip_done = false)

Watchdog (force_drop_journal = false, skip_done = true)

▌ Передача режима исполнения - через файл

Вроде бы и норм

▌ Вмешательств руками ~ 1-2 в месяц

Но!

▌ Длинные цепочки – большая вероятность падения

▌ Обработка больших порций данных

▌ Неравномерность загрузки кластера

45

Другой подход. Конвейер

46

Обработка. Наивный подход

47

ProducerAppend Consume

Consumer


48

Producer ConsumerA

B

Append Consume


49

Producer ConsumerA

B

Append Consume


50

Producer Consumer

A

B

С

Append Consume


51

Producer Consumer

A

B

С

С – потеряно!

Append Consume

Цепочка

52

Producer Consumer

1 2

A

Всегда одна обрабатываемая часть

Append Consume

Конвейерная обработка

53

Producer ConsumerAppend Consume


54



55



56

Producer Consumer

С – проблем нет!

Append Consume


▌ Узлы работают независимо

▌ Нет последовательности выполнения

▌ Триггером запуска является наличие новых данных

Можно ли использовать всегда?

57

Возможен только один потребитель

58

Producer

Consumer

Consumer


59

Producer

Consumer

Consumer

Multiplexor


60

Producer Consumer

Consumer

Read

Move

Consume

Консистентность данных

61

▌ Два разных лога с url

▌ Общий словарь (url, id)

▌ Словарь пополняется

▌ Выход – цепочка!

Consume

R/W

Consume

R/W

Конвейер цепочек

▌ Смешение двух подходов

▌ Плюсы конвейерной обработки

▌ Количество цепочек – минимально возможное

▌ Удобно при рефакторинге

▌ Основной используемый подход

Вмешательств руками < 1 в месяц

62

Спасибо за внимание!

Контакты

[email protected]

Дмитрий Кукса

Группа разработки Крипта

64

Дополнительные слайды

Другие решения

▌ Hadoop workflow schedulers

Oozie – http://oozie.apache.org

Azkaban – http://data.linkedin.com/opensource/azkaban

▌ Конфигурационные файлы (XML)

▌ У нас – другой подход

Обслуживающая функциональность – в бинарниках

Workflow = скрипт

66

http://oozie.apache.org/

http://data.linkedin.com/opensource/azkaban

Характерные задачи Крипты

▌ Парсинг логов

▌ Агрегация данных из разных источников

▌ Фильтрация противоречивых данных

▌ Подготовка выборок для Матрикснет

▌ Классификация пользователей

Нужны регулярные последовательности действий

67

Организация процесса регулярной обработки больших...

Software