Upload
codefest
View
320
Download
3
Embed Size (px)
Citation preview
Организация процесса
регулярной обработки
больших объемов данных
Группа разработки Крипта
Дмитрий Кукса, разработчик
Что такое Крипта?
▌ Отвечает на вопрос – «Кто?»
▌ Определяет характеристики
пользователя по поведению в
интернете
▌ Используется для таргетинга рекламы
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, [email protected]
id2, [email protected]
id3, [email protected]
id3, [email protected]
id4, [email protected]
id5, [email protected]
10
Inputs Map
id1, [email protected]
id2, [email protected]
id3, [email protected]
gmail.com, 1
gmail.com, 1
yandex.ru, 1
mail.ru, 1
yandex.ru, 1
yandex.ru, 1
id3, [email protected]
id4, [email protected]
id5, [email protected]
11
Inputs Map Group
id1, [email protected]
id2, [email protected]
id3, [email protected]
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]
id4, [email protected]
id5, [email protected]
12
Inputs Map ReduceGroup
id1, [email protected]
id2, [email protected]
id3, [email protected]
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]
id4, [email protected]
id5, [email protected]
Что обеспечивает 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
Спасибо за внимание!
Дополнительные слайды
Другие решения
▌ Hadoop workflow schedulers
Oozie – http://oozie.apache.org
Azkaban – http://data.linkedin.com/opensource/azkaban
▌ Конфигурационные файлы (XML)
▌ У нас – другой подход
Обслуживающая функциональность – в бинарниках
Workflow = скрипт
66
Характерные задачи Крипты
▌ Парсинг логов
▌ Агрегация данных из разных источников
▌ Фильтрация противоречивых данных
▌ Подготовка выборок для Матрикснет
▌ Классификация пользователей
Нужны регулярные последовательности действий
67