Тут как раз задача, выгрузки раз в день, но почитаю про штуку что вы написали. Спасибо

вопрос по спарк 3.2 и адаптивному выполнению:

у нас есть утилитные методы по добавлению соли/функции для репартишена
есть тесты на это всё
(условно создали датафрейм с солью на 5-10 элементов, сделали репартишен и тд)
так как партиций задали побольше, то получали сколько-то партиций с 1 елементом внутри

и вот адаптив теперь понимает что "хм, пару мелких партиций, давай я их в 1 солью"

там где после репартишена мелких таблиц на 1000 элементов раньше было несколько партиций, то сейчас остаётся 1 партиция после выполнения

с точки зрения оптимизации это понятно, датафрейм то мелкий

@SparkApplicationMaster может сталкивались с этим?

3.2 ещё не раскапывал пока, а надо чётко их разделить, или это приемлемое поведение?

То есть он делает coalesce without shuffle, я правильно понял?

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

и вот теперь эти тесты посыпались

да

Тесты на число файликов итоговых в папке?

да

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

в случае тестов значения занижены и в файликах по 1-2 записи
а сейчас 1 файлик 😁

то есть понятно что с точки зрения спарка всё валидно, он и не давал гарантий никаких на это
оптимизация валидна

но от этого не легче и непонятно как тестировать

Спарк отнимает мою работу🤔☹️😆

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

решат они константы у себя поменять внутри и опять всё упало

Но по сути он решает задачу разбиения

Может параметры есть?

Но не в доке, конечно же