Память driver'а против памяти executor'а: это не одна и та же задача по настройке

Driver выполняет принципиально другую работу, чем executor: он строит и планирует DAG, а не обрабатывает партиции данных — а значит, давление на его память возникает из совершенно других мест.

Что на самом деле выполняется на driver'е

Построение плана и планирование DAG, координация назначения задач executor'ам, сбор значений аккумуляторов и всё, что явно возвращает данные обратно в процесс driver'а — collect(), toPandas(), take() для большого результата. Ничто из этого не является «обработкой партиций вашего датасета» — это целиком работа executor'ов.

Почему у OOM драйвера другие реальные причины

Самая частая, безусловно: кто-то вызвал .collect() или .toPandas() на DataFrame, оказавшемся гораздо больше ожидаемого, стянув всё целиком в память единственного процесса driver'а вместо того, чтобы оставить данные распределёнными. На втором месте: broadcast join (см. статью о broadcast join), где «маленькая» сторона на деле маленькой не оказалась — driver собирает эти данные прежде, чем передать их executor'ам, так что падает по OOM первым. На третьем: задача, отслеживающая огромное число партиций или очень глубокий DAG, где сами накладные расходы на планирование — без каких-либо реальных данных — съедают heap driver'а.

Почему увеличение памяти executor'а тут не поможет

spark.executor.memory и spark.driver.memory — действительно раздельные настройки, управляющие раздельными JVM-процессами: увеличение одной никак не влияет на давление на другую. OOM драйвера из-за неожиданного collect() требует либо исправления кода (агрегировать перед сбором, или не собирать вовсе), либо конкретно spark.driver.memory; добавление памяти executor'у в этом случае адресует процесс, который никогда и не был тем, у кого кончалась память.