для операции сверху план выглядит примерно так

Конвертация в rdd это недёшево, а суть операции ровно такая же

Ну а чукча что видит, то и поёт

Репартишен = эксченж

суть не такая же, repartitionAndSortWithinPartitions не делает сортировку в партициях, а делает k-merge уже отсортированных shuffle-партиций

Судя по плану .repartition(…).sortWithinPartitions(…) так не делает, и у меня это вызывает вопрос

Оно делает ровно то, что и написано, непонятно, в чём вопрос)

Недоумение вызывает то, что .repartitionAndSortWithinPartitions(…) делает это более оптимально чем .repartition(…).sortWithinPartitions(…), но этот API доступен только из RDD

Я бы ожидал что .repartition(…).sortWithinPartitions(…) транслировался в подобный repartitionAndSortWithinPartitions физический план, но такого не происходит

Rdd api щас ничего общего не имеет с dataframe api

Никакого недоумения не должно быть, это разные операции, они не сливаются в одну. Указан repartition - будет repartition, потом локальный сорт - он и будет, возможно, по другим полям. Если нужно, чтобы выполнен был .repartionAndSortWithinPartitions, его и надо выполнять

repartionAndSortWithinPartitions как раз позволяет репартицировать по одним полям и сортировать по другим. Почему из DataFrame API оно не фьюзится в то, как это делается в repartionAndSortWithinPartitions?

Потому что так не сделано в стратегиях Spark))

def repartitionAndSortWithinPartitions(partitioner: Partitioner): RDD[(K, V)] = self.withScope {
 new ShuffledRDD[K, V, V](self, partitioner).setKeyOrdering(ordering)
}
private val ordering = implicitly[Ordering[K]]

Я отдельно делал, чтобы был k-way merge по другим полям

версия 2.4, да

я как раз понимаю что не сделано, просто на мой взгляд странно что эта техника по дефолту доступна из RDD API и недоступна из DataFrame API

Через кастомный оператор делал?

Было бы очень интересно как можно это фокус провернуть, не проваливаясь в RDD

https://habr.com/ru/company/sberbank/blog/583018/

Вот вторая часть статьи, опубликовал в октябре, код прямо в ней (особенности публикации)

Иван, спасибо!

Коллеги, всем привет!
В Спарке 2.4 включена dynamic allocation.

Джоба в процессе выполнения запрашивает какое-то бешеное количество экзекьюторов.
В логах вижу сообщения типа:

Request 20 additional executors.
New desirable count of executors = 250

Request 35 additional executors.
New desirable count of executors = 285.

При запуске было указано число экзекьюторов=9, 5 ядер на каждом, 10 Гб памяти на каждом.

С чем может быть связан такой большой запрос на новые экзекьюторы? Там цифры до 400 доходят