Комментарии 10
текстом даже понятнее чем в докладе на хайлоаде - который про это был у автора
Отличная статья, Валерия ?
Коротко, понятно и по делу.
Руки прямо так и чешутся попробовать ?
Параметров же несколько побольше, хотя бы число executors. Да и такие вещи, как размер стека для scala, иногда приходится подстраивать (по ощущениям, когда очень широкие таблицы попадаются). Ну то есть, у нас параметров где-то штук 10 примерно.
Да, вы правы, параметров действительно гораздо больше. Нам в первую очередь была интересна память потому, что она напрямую влияла на описанную проблему неоптимального выделения контейнеров. Число экзекьютеров регулируется у нас динамической аллокацией, а вот завышенный размер приводил к недоутилизации кластера. Пул памяти использовался практически весь, а CPU при этом простаивал. Тюнингом spark.executor.memory мы как раз сместили баланс где-то на 16%, об этом ещё будет во второй части статьи, которая выйдет позже.
Приятно слышать, что смогли затащить это в прод.
Подскажи, вы же используете ступенчатый набор параметров или вы индивидуально рассчитываете для каждого пайплайна?
val metrics2 = taskEndMetrics
.selectExpr("application_attempt", "explode(Task Info.Accumulables) as acc")
.selectExpr("acc.*")
.where("Name = 'internal.metrics.peakExecutionMemory'")
.groupBy("application_attempt")
по очевидной причине: колонка для группировки не выбрана вот тут: .selectExpr(«acc.*»), то есть после этой строки в датасете ее нет.
Автоматический подбор параметров для Spark-приложений