Глаза боятся, руки из жопы но я не сдаюсь ))

Видимо для таких случаев как раз

Но он работает x2 времени

у меня спарк 3.1

В принципе сортировка с совместным партицированием сложная операция

В общем, если кому интересно, проблему с временной папкой решил через управление (создание, удаление) временной папкой через Python (tempfile). Но вот то, что новые сессии берут конфиги от предыдущих сессий, это я пока не знаю как решить. Перегружать ядро jupyter не подходит, т.к. теряются все вычисления, а мне нужно в рамках одного python процесса всё выполнить. Единственная гипотеза, парсить параметр sun.java.command и его менять.

я не совсем понимаю, почему это проблема. можете в двух словах описать свой workflow? и зачем вам много сессий в одном кернеле? (как я понял)

почему у вас теряются вычисления? можно же их сохранить паркетом на диск / хдфс / что там у вас

Как к компьютеру вернусь, опишу ситуацию

У меня такой пайплайн, качаю данные из hive и перевожу их в pandas для дальнейшей работы - это одна сессия, далее происходит несколько этапов без запуска Спарк, после этого запускаю распределённый оптимизатор гиперпараметров - это вторая сессия, ещё несколько этапов на чистом питоне, и потом записываю результаты пайплайна обратно в hive. Собственно говоря, я бы всё на одной сессии делал, но вот время между активностями Спарка будет довольно долгим, т.е. ресурсы будут заняты, а по факту ничего не исполняется. Хотел обойтись малой кровью, чтобы не переписывать пайплайн и остановиться на 3-х разных сессиях, но подозреваю, что так не получается.

Решается переводом spark.dynamicAllocation.enabled в true и установкой в spark.dynamicAllocation.minExecutors минимального числа executors, которое нужно постоянно сохранять привязанными к текущей сессии (обычно можно хоть в й выставить).

Остальные после достижения spark.dynamicAllocation.executorIdleTimeout будут освобождены, их смогут использовать другие сессии. Если minExecutors=1, то ресурсы будет занимать фактически только драйвер.

Но executor'ы освобождаются только в том случае, если на них ничего не закэшировано.

Пробовал с только с этой spark.dynamicAllocation.enabled конфигурацией запускать, но оптимизатор в некоторых случаях не запускался и нужно смотреть, что у него под капотом, может он и кеширует что-то. Вроде, решалась через тюнинг других конфигов, но точно каких не скажу, нужно будет над логами посидеть.
Всем спасибо за советы, попробую на одной сессии с динамической аллокацией выехать!

Кешированные данные тоже выгружаются, там другой таймаут

А минэкзекуторс случаем 0 не ставили?

С 0 не всегда стартует

По крайней мере в спарк 2.3-

Нет, конфиг состоял из одного параметра spark.dynamicAllocation.enabled, true

Ну этого маловато)

Там 5 штук параметров

Ну похоже настал момент, когда нужно углубиться в динамическую аллокацию, а то до этого обычно на статической сессии всё запускал