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

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

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

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

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

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

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

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

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

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

интернете

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

5

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

▌ Объем регулярно обрабатываемых данных ~ 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)

9

Inputs

id1, nagibator1995@gmail.com

id2, nagibator1996@gmail.com

id3, superman@yandex.ru

id3, whosyourdaddy@mail.ru

id4, superman2@yandex.ru

id5, superman3@yandex.ru

10

Inputs Map

id1, nagibator1995@gmail.com

id2, nagibator1996@gmail.com

id3, superman@yandex.ru

gmail.com, 1

gmail.com, 1

yandex.ru, 1

mail.ru, 1

yandex.ru, 1

yandex.ru, 1

id3, whosyourdaddy@mail.ru

id4, superman2@yandex.ru

id5, superman3@yandex.ru

11

Inputs Map Group

id1, nagibator1995@gmail.com

id2, nagibator1996@gmail.com

id3, superman@yandex.ru

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, whosyourdaddy@mail.ru

id4, superman2@yandex.ru

id5, superman3@yandex.ru

12

Inputs Map ReduceGroup

id1, nagibator1995@gmail.com

id2, nagibator1996@gmail.com

id3, superman@yandex.ru

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, whosyourdaddy@mail.ru

id4, superman2@yandex.ru

id5, superman3@yandex.ru

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

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

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

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

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

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

13

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

14

,

, ,

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

15

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

▌ Проблемы

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

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

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

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

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

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

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

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

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

16

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

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

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

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

17

Аспекты

18

АОП

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

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

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

19

АспектыRun() {

RunTask();

}

RunTask() {

RunOperation();

}

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

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

RunTask();

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

}

RunTask() {

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

RunOperation();

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

}

Аспекты. Monitoring

22

Monitoring

Application

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

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

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

RunTask();

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

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

}

RunTask() {

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

RunOperation();

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

}

Аспекты. 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(); // Определение контекста задачи. Сохранение

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

RunTask();

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

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

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

}

RunTask() {

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

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

RunOperation();

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

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

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

30

Task

operation_1

-src //crypta/fresh/offers/

-dst //crypta/state/

-ts 1424791640

Name = operation_1

Src = //crypta/fresh/offers/1

Dst = //crypta/state/offers_123

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

31

Task

operation_1

-src //crypta/fresh/offers/

-dst //crypta/state/

-ts 1424791640

Name = operation_1

Src = //crypta/fresh/offers/1

Dst = //crypta/state/offers_123

Done = true

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

32

Task

operation_1

operation_2

-src //crypta/fresh/offers/

-dst //crypta/state/

-ts 1424791640

Name = operation_1

Src = //crypta/fresh/offers/1

Dst = //crypta/state/offers_123

Done = true

Name = operation_2

Src = //crypta/state/offers_123

Dst = //crypta/state/accum

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

33

Task

operation_1

operation_2

-src //crypta/fresh/offers/

-dst //crypta/state/

-ts 1424791640

Name = operation_1

Src = //crypta/fresh/offers/1

Dst = //crypta/state/offers_123

Done = true

Name = operation_2

Src = //crypta/state/offers_123

Dst = //crypta/state/accum

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

34

Task

operation_1

operation_2

-src //crypta/fresh/offers/

-dst //crypta/state/

-ts 1424791640

-failures 1

Name = operation_1

Src = //crypta/fresh/offers/1

Dst = //crypta/state/offers_123

Done = true

Name = operation_2

Src = //crypta/state/offers_123

Dst = //crypta/state/accum

Аспекты

▌ 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

Producer ConsumerAppend Consume

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

55

Producer ConsumerAppend Consume

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

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

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

Контакты

dkuksa@yandex-team.ru

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

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

64

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

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

▌ Hadoop workflow schedulers

Oozie – http://oozie.apache.org

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

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

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

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

Workflow = скрипт

66

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

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

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

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

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

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

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

67