Субботний вечер, а значит время смотреть конференции

Автоматический подбор параметров для Spark-приложений / Валерия Дымбицкая (OneFactor)

Ссылка на выступление: https://www.youtube.com/watch?v=Ot93PQELdcM
или
https://vk.com/video-152308462_456239627

Сложность: 3/3 (Технически насыщенный доклад, требует понимания Apache Spark, оптимизации ресурсов и машинного обучения)
Кому будет интересно: Тем, кто работает с Spark. Если ни разу не запускали Spark - смело пропускайте данный пост.

✨ Краткий пересказ и выводы по докладу Валерии Дымбицкой (OneFactor) ✨
Валерия представила систему автоматического тюнинга параметров для Spark-приложений, основанную на анализе логов и машинном обучении. Система разработана для оптимизации использования ресурсов в кластере и повышения эффективности выполнения задач.

🔍 Основные тезисы:
1️⃣ Проблемы текущего подхода:
• Кластер ограничен в ресурсах, и даже при большом количестве узлов и памяти их может не хватать.
• Одинаковые ресурсы для всех запусков приводят к недоутилизации и конкуренции за ресурсы.
• Легкие задачи могут занимать все ресурсы, оставляя тяжелые задачи в очереди.
2️⃣ Описание системы литгенерации:
• Включает базу абонентов и Spark-пайплайны для отбора данных.
• Ежедневно запускается около 600 задач, и каждый день добавляются новые триггеры и пайплайны.
• Пайплайны уникальны и создаются дата-специалистами, что усложняет унификацию параметров.
3️⃣ Первый подход: априорный тюнинг:
• Попытка определить параметры перед запуском задачи.
• Проблема: сложность выделения классов задач и необходимость экспериментов на продовой среде.
• Неэффективность из-за затрат времени и ресурсов.
4️⃣ Апостериорный подход: оптимизация на основе логов:
• Использование метрик из логов Spark для определения оптимальных параметров.
• Анализ логов в формате JSON для получения информации о шафлах, спилах и времени в GC.
• Основной фокус на оптимизации параметра Spark Executor Memory.
5️⃣ Правила оптимизации памяти:
• Правило GC: Время сборки мусора не должно превышать 10% от времени работы приложения.
• Правило сброса записи на диск:Избегать сброса данных на диск, что указывает на нехватку памяти.
• Правило использования данных:Объем данных должен укладываться в выделенную память.
6️⃣ Объединение предсказаний:
• Использование взвешенного среднего для объединения предсказаний от трех правил.
• Минимум как метод объединения для определения оптимального объема памяти.
7️⃣ Изотоническая регрессия:
• Построение регрессии для каждого пайплайна.
• Преимущества: легко обучается на малом количестве данных, удобно хранить в базе данных.
• Переобучение после каждого запуска приложения для адаптации к изменениям.
8️⃣ Проблемы и решения:
• Откат при неправильных предсказаниях: Возможность вернуться к предыдущим параметрам.
• Переобучение: Быстрое обновление регрессий после каждого запуска.
• Параллельность: Добавление параллельности для ускорения переобучения.

🚀 Рекомендации:
• Используйте логи Spark для анализа и оптимизации параметров.
• Применяйте изотоническую регрессию для быстрого и эффективного тюнинга.
• Регулярно переобучайте модели для адаптации к изменениям в задачах.
• Оптимизируйте не только память, но и другие параметры, такие как количество шафлов.

💡 Выводы:
1️⃣ Автоматизация тюнинга — ключ к эффективности:
• Ручная настройка параметров неэффективна и требует много времени.
• Автоматизация позволяет экономить ресурсы и повышать производительность.
2️⃣ Логи Spark — ценный источник данных:
• Анализ логов помогает выявить узкие места и оптимизировать параметры.
• Использование машинного обучения для анализа логов — перспективное направление.
3️⃣ Изотоническая регрессия — мощный инструмент:
• Простота обучения и интерпретации делает ее идеальной для задач тюнинга.
• Быстрое переобучение позволяет адаптироваться к изменениям в задачах.

📌 Итог:
Доклад Валерии Дымбицкой — это отличный пример того, как автоматизация и машинное обучение могут значительно улучшить эффективность работы с распределенными системами.