Он очень специфичный, и данные которые подаются на вход получаю в ходе большого препроцессинга, да и выгрузить их нельзя :( Но сам запуск и тесты вот https://pastebin.com/WH5Qf9hP

Я думаю в нём только с объяснениями можно разобраться) Песочница, поэтому без комментов и так криво написано.

В некоторых случаях параллельный запуск джобов может ускорить обработку на порядки, а в некоторых может в разы замедлить или вообще поставить колом :). В Pravda-ml https://github.com/odnoklassniki/pravda-ml мы активно используем параллелизм при проведении кросс-валидации и тюнинге гиперпараметров. Но чтобы не выстрелить себе в ногу нужно как минимум число партиций подобрать правильное

Вообщем надо эксперементировать:)

Окей. Имхо, глупый вопрос, но нужен ответ специалистов. Можете закидать шапками или книгами, если прямо ересь :( Есть задача запустить расчеты (чтение/процессинг/ml модели) на трёх различных источниках данных. Цель посчитать максимально быстро, а не поделить время раномерно между каждым обсчетом. Можем запустить расчеты последовательно, с максимальной утилизацией кластера, либо поделить поровну экзекьюторы и запустить в параллели. Выглядит так что при параллельных расчетах не придётся ждать пока неоптимальные участки будут например данные гонять, а в это время будет исполнятся джоба которой нужны свободные ресурсы, но с другой стороны в спарке все же уже оптимально и распараллелено под капотом, и навернув сверху это разделение, я создам только дополнительный оверхэд.

Суть в том что я хочу избавиться от проседаний на графике

И с партициями и с экзекьюторами и с оптимизацией кода играл, на 100% загрузить не получается :(

fair scheduler жи

Окей, попробую его настроить, я ждал пока пнут к его настройке)

У тебя какой сетап? Спарк стэндэлон? Спарк на ярне? Какой план выполнения?

Провалы удалось локализовать с конкретными этапам в обработке?

Первый самый большой провал (12:33) связан с этой проблемой https://stackoverflow.com/questions/48880934/performance-decrease-for-huge-amount-of-columns-pyspark в частности имплементация алгоритма из ответа помеченного галочкой, следующий за ним (12:34.5) это обучение множестенных логрегрессий.

Ярн, прямо как физ план выглядит, вы имеете в виду?

Ну это мои частные заморочки по коду, я хотел услышать возможные общие варианты решения типа того что посоветовали по fair scheduler. Буду пробовать.

Не знаю, как насчёт модели, но мы запускали перекачку данных в 600 параллельных тасках на fair пуле. Кластер просидал максимум процентов на 5.

Вместо датасетов с большим числом колонок лучше делать колонку-вектор или колонку-мапу. Собственно если это результат пивота то сам бог велел OneHotEncoder сделать. Если при обучении регрессий провал то, скорее всего там мелкие задачи и идет много накладных расходов на драйвер - надо попробовать число партиций уменьшить и подумать что и в какой момент подкешить.

Сперва нужно отпроцессить длинный фрейм, а потом спивотить (и там происходила посадка из-за большого числа столбцов в результате пивота, но удалось ускорить) тут, к сожалению, без вариантов. Про ванхот не понял, это не категории, зачем он? Да, по поводу мелких задач согласен, но по партициям там и так их всего 5. Я выше код на пастебин прикладывал, там все кэшируется, я это усвоил когда в логах спарк варнинги кидал про перфоманс декриз если не будет кэша))

Хотя возможно переусердствовал...

На датафесте буду чуть-чуть об этом говорить.
Если кратко, то мы используем схему с completablefuture (треды).
На 1-1.5 ядер (256/384 *4) считаем в 8-16 потоков и получаем почти линейное ускорение рассчета истории.
Ключевое:
* рассчеты должны быть независимы
* ресурсов должно быть достаточно