Всем привет. читаю спарком большой gzip (внутри csv), делаю некоторые

простецкие трансформации по типу кастинга дат и затем пишу в паркет. для простоты эксперимента использую 1 воркер (глюшный G1.X).

Джоба падает (предположительно с ООМ), что в целом мне понятно, поскольку gzip не сплитабл, всё в одном партишене и тд. При этом, если добавить .repartition(N), то джоба перестает падать, всё на том же одном воркере.

Может кто-то объяснить как в этом случае помогает .repartition? у спарка есть какие-то лимиты по памяти по партишенам?

есть предположение что партишены можно хотя бы последовательно посчитать независимо друг от друга если памяти мало, а вот 1 партишен нельзя, его надо грузить весь

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

спасибо за предположения. сегодня ещё попробовал поковырять джобу в spark-ui - особо полезной информации не нашел. Также попробовал другие данные gzip-нутые запроцессить и наткнулся на какую-то интересную особенность - одна таблица 100мб gzip падает при попытке чтения/записи в паркет, другая 2гб gzip с теми же самыми операциями процессится нормально, правда долго и с каким-то дикими спиллами: Shuffle Spill (Memory): 33.9 GB Shuffle Spill (Disk): 8.1 GB

Может там троянский гзип со сжатием до 1%)