А вот датабрикс, где половина параметров скрыта или настраивается автоматически...

Не очень корректное сравнение, оракл сам паркеты, цсв и прочие жисоны обычно не лопатит.

А тот же big data appliance сам с хадупом

Привет!
Как посчитать операт. память для spark приложения?  
Например, есть две таблицы, 1 - весит 20 Гб , а 2 - 3 ГБ,  выполняется left  join . (оч тривиальный кейс)
Количество ядер и экзек  можно взять минимальные (1 - exec, 1-core), распределение exec memory оставляем дефолтные (75  на 25 % ), броадкаст оставляем на каталист.
До этого момента выбирал эмпирическим методом оперативку для своего приложения (если падает с oom выделяю больше), а также под рукой нет графаны.

где -то читал ,что  в зависимости от кол parquet-файлов которые будут сплитится (для map), можно посчитать оперативку

Проверенный экзекутор - 4 ядра, 16гб оперативы и 2гб оверхэд

Зависит от размера партиции

Обычно всасывается в один поток до 128мб файла

Если на нём что-то не работает - размер входной партиции можно урезать, размер любого таска можно урезать

С помощью снижения spark.files.maxPartitionBytes и увеличения spark.sql.shuffle.partitions соответственно

если я не ошибаюсь, то это от block size зависит (block=split)

а как это посчитать самому ? )  если отправите статейку буду очень благодарен

Никак, просто запустить 10 тысяч джобов с разными видами экзекуторов и убедиться, что этот в среднем лучше всего работает😐

Ну, конечно, чем больше оперативы в экзекуторе, тем ему проще

Но чаще всего упирается в то, что оперативки на кластере примерно и есть 4гб на ядро

Первая точка, от которой нужно отталкиваться - а сколько памяти и коров у вас вообще есть

на кластере достаточно ресурсов (500 коров , 2Тб ), но мне не все доступно (ограничения ярна)

Кек, 4гб на ядро)

К счастью, это очень легко диагностировать

Ну просто это стандартное соотношение

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