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

А, ну там не пожато вообще

Поэтому чаще всего лучше сохранить в паркет, а не кэшить

А если sortWithinPartitions по тем же колонкам, что и в исходнике, после репартишена сделать?

Действительно может помочь пожать раза в 2, если не больше

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

Если сортировка данных в разных колонках прям сильно коррелирует

ждём что скажет автор вопроса =)

Все причины, перечисленные Алексом возможны. Плюс ещё одна: мелкие файлы состоят из одного блока. Поэтому в них dictionary encoding работает лучше (меньше вариантов, не превышен порог), run length encoding также лучше и нет оверхеда на заголовки. То есть корневые причины всё те же. Snappy при этом тоже может немного сильнее сжиметь, но это будет малозаметно.

Ради интереса, можно уточнить количество исходных файлов и инструмент, которыем они были записаны?

Тут не нужны lowerbound/upperbound. Это сохранение, а не чтение, например, с помощью JDBC из RDBMS

В исходной директории 7 тысяч файлов. Это сырые данные из кафки, перегруженные в хдфс джобой структурного стриминга спарка без какой-то дополнительной сортировки

В исходнике данные не отсортированы 🤷‍♂️

Тогда фиг знает вообще)

в каком-то смысле сортировка есть: таймстемпы и даты событий идут последовательно по возрастанию, как и суррогатные ключи - айдишники. Некоторые категории (внешние ключи) тоже могут быть одними и теми же, если партишен топика кафки завязан на них, или по другим причинам

Вот этот кейс - ещё одна причина задуматься перед тем, как сделать repartition(n). Перетасованные по хешам записи - не всегда именно то, что нужно. Очень возможно, что изучение распределения данных в исходных файлах прояснит причины, но это отдельная и достаточно большая активность.

Но часто достаточно того, что файлов стало меньше, пусть и увеличился их размер

Ходуб большой😆

"...ему видней"

всем привет!
есть одна проблема с которой не могу справиться, прошу помочь, процесс  падает с ошибкой job aborted  когда начинает писать, но что странное, иногда работает иногда падает, и мне не понятна причина , может есть каки-то идеи

поищи в логе в стеке исключения caused by. Там будет исключение, которое вызвало остановку джобы

спасибо , щас гляну попробую разобраться. если что обращусь )