Ван Хачатрян — Spark Streaming: в погоне за оптимальной утилизацией и прозрачностью на hadoop

Transcript

1. Spark Structured Streaming на кластере Hadoop Ван Хачатрян Руководитель отдела ML и матчинга
2. Почитайте нас на Хабр 2
3. Содержание Почему мы отказались от батч-подхода Введение в Spark Structured Streaming Первое приложение стриминга на Hadoop Масштабируемость и интеграция с Kafka Алёртинг не из "коробки" Магия pandas_udf и демоны
4. Стэк в отделе ML 4 Разработка: Python, Golang, Scala Данные: Hadoop/Hive, Kafka, Vertica, PostgreSQL, Clickhouse, S3 Мониторинг: Prometheus, Grafana затронем в докладе как-нибудь в другой раз
5. Как выглядел наш ETL 5
6. Кажется, есть что-то лишнее 6
7. Spark Structured Streaming
8. К чему пришли 8
9. Ликбез по kafka 9 Kafka — позволяет хранить и работать потоками событий — Topic — способ группировки потоков сообщений в отдельную тему — Producer — издатель потоков сообщений — Consumer — подписчик на потоки сообщений — Partition — файл содержащий подмножества сообщений из topic — Offset — уникальный для тройки topic-consumer-partition номер сообщения
10. Что мы насчитываем 10
11. Зачем переходить на Streaming 11 — непрерывный стрим микробатчей — обработка потока данных без расписания — возможность масштабирования — отказоустойчивость — low latency — оптимальная утилизация ресурсов
12. Особенности при использовании 12 — порядок обработки потока — сложный подбор конфигураций Spark приложения — непрозрачный мониторинг в Spark UI — нет SOTA подхода для деплоя
13. Первое приложение
14. Запустить — НЕ полдела Результат — DataFrame Доступны: • Операции Join • Применение функций на группах или окнах • Применение UDF (user defined functions)
15. Базовые конфигурации 15  maxOffsetPerTrigger — максимальное количество обработанных сообщений за интервал  minPartitions — число Spark задач, на которое разбивается прочитанный батч из topic  startingOffsets — точка старта в kafka-topic при первом запросе → https://spark.apache.org/docs/latest/structured-streaming-kafka-integration.html
16. Прослушали: что дальше
17. Интеграция с Kafka
18. Три партиции и три «мушкетёра» 18
19. Ускорит ли Д’Артаньян процесс? 19
20. minPartitions = 6 20
21. Мониторинг
22. Что имеем в Spark UI 22 Не имеем: — состояния топика — номер текущего offset — возможности навесить алёрт
23. Как мы настроили алёртинг — коммитим обратно в kafka обработку offset через Streaming Query Listener — метрики по topic и consumer группе в Prometheus — рисуем метрики в Grafana, используя PromQL-запросы — алёрты на основе метрик из Prometheus
24. Применение ML-моделей
25. Ангелов нет — только демоны! 25 — parent process запускается при появлении каждого экзекутора — ограничения на fork позволяют использовать сopy-on-write — экономия памяти и избежание повторной инициализации модели
26. Бенчмарки 26 Расчет векторов: — BERT 1x768: 1 CPU, 50 эмб./с. — FastText 1x128: 1 CPU, 100 эмб./с. — *ResNet-50 1x128: 1CPU, 1.5-3 эмб./с. — **Prod2Vec 1x256: 1CPU, 1.5-3 эмб./с. * зависит от скорости скачивания картинки и от того, как они подаются на вход ** Prod2Vec (2xTinyBert + 1xResNet-34) — подробнее на Хабр переходите по QR-коду
27. Ван Хачатрян Спасибо за внимание! vkhachatryan@ozon.ru