Мож у тебя просто все экзеки равномерно медленно делают все

А может они у тебя не загружены потому что ты дал им по 100 ядер на таску и они более одной партиции за раз не процессят

Мне кажется тормоза на больших количествах из-за partitionBy

На 3 млн по любому будет тормозить

репартишн делаешь перед партишн бай ?

Нет

а как ты получаешь 50к партиций

И партишн бай сколько у тебя хочет сделать партиций

Он просто медленный и тупой

Там выше код, данные от 50 тысяч записей до млн, я так понимаю для каждой комбинации создается отдельная партиция, или я путаю что-то.

.write.partitionBy(f1, f2, f3) работает так: сортирует партиции RDD по f1, f2, f3 (sortWithinPartitions(….)), затем начинает писать файлы. Как только значение (f1, f2, f3) отличается от предыдущего, создается новый файл в новой партиции. Если одна партиция создает фигово количество файлов, каждый таск работает очень долго (с json, может быть, не так долго, как с паркет, но всё же не быстро). Поэтому если есть возможность, сделай repartition по этому датасету, как советует Григорий, поставив количество numParts равным удвоенному количеству файлов

да, почитай что делает партишнБай

он глупый и работает не как ты ожидаешь

где-то был пример, если у тебя 10 партиций в которых по 7 дней недели содержится и ты партишнБай делаешь (по дням) на них, то скок как ты думаешь он файлов запишет? vs ты сделаешь репартишн по дню и каждая партиция один день содержит

но тогда будет широкая трансформация и обмен данными, но может сильно помочь. У меня был кейс - от примерно шестидесяти часов без repartition до шести-восьми часов выполнения c repartition.
Особенности Glue я не знаю

Понял, спасибо большое!

7 файлов?

70

О классно, обязательно попробую.

Действительно, не очень то  оптимально. А какие-то альтернативы имеются?