Или оно на уровне RDD API чё-то делает?

В первую очередь sql и датафреймы Но не удивлюсь если и на рдд что-то влетает, там они всё сейчас пытаются в планер пихать

мде. пишуть, что As of Spark 3.0, there are three major features in AQE: including coalescing post-shuffle partitions, converting sort-merge join to broadcast join, and skew join optimization.

Первые 2 были и до, но как отдельные конфиги (бродкаст точно)

И да и нет Адаптив замержен в 3.0 Включено по дефолту в 3.2 В первую очередь это часть каталиста (датафрейм и sql) Но конкретно для вас spark.sql.adaptive.coalescePartitions.enabled When true and spark.sql.adaptive.enabled is true, Spark will coalesce contiguous shuffle partitions according to the target size (specified by spark.sql.adaptive.advisoryPartitionSizeInBytes), to avoid too many small tasks. spark.sql.adaptive.coalescePartitions.minPartitionSize The minimum size of shuffle partitions after coalescing. Its value can be at most 20% of spark.sql.adaptive.advisoryPartitionSizeInBytes. This is useful when the target size is ignored during partition coalescing, which is the default case. Default 1MB spark.sql.adaptive.advisoryPartitionSizeInBytes The advisory size in bytes of the shuffle partition during adaptive optimization (when spark.sql.adaptive.enabled is true). It takes effect when Spark coalesces small shuffle partitions or splits skewed shuffle partition Default 64MB У нас для всяких датафреймов и тд кастомных партишенеры есть, и в свое время когда переходили на 3.2 все юнит тесты поплыли Повторюсь: в первую очередь это sql и dataframe, но не удивлюсь если часть вещей ещё и рдд цепляют (как минимум для сбора различной статистики, а это уже тригерит другое поведение). Или амазон своих патчей докинул. Поэтому и предложил как первый и самый очевидный шаг отключить и посмотреть что изменится Особенно учитывая что у вас 12.5гб на 7к партиций это по 1.78 мб / партицию на выходе, что как-то не много

Может, там спарк дергает бинарь какой. А спарк как процесспоол

1. по ходу эти настройки не влияют на уровень RDD вообще никак. что с ними, что без результат абсолютно одинаковый. на спарке 3.2 кстати оно работает, а на 3.3 падает. (если бы влияло, то логично падало бы и на 3.2, коли там оно уже включено) 2. партиции по 1.8 мб (45к записей) в данном кейсе не баг, а фича. там по ходу пьесы внутре происходит что-то алгоритмически похожее на бродкаст джойн, потом на group by ... having по этому джойну, и соответственно с генерацией массива промежуточной даты на каждую запись, который ещё и сортируется. памяти под это надо порядочно ну и по ходу дела, в самих данных аналитики допустили какую-то лажу, завтра обещают поменять массив. но я-то с сэмплом отлаживаюсь, который от прода довольно далёк, и точно качественный. вот перезапустят с реальной датой, посмотрим ещё раз