на самом деле ещё не всё, если есть skew, то можно создать слишком большие таски и всё станет только хуже. Поэтому возможно придётся добавить соль - дополнительное поле, например (rand() * 10) cast IntegerType, где 10 - число, которое придётся подобрать, чтобы не было этих больших тасков.
Предыдущий девелопер реализовал эту задачу с помощью partitionBy поэтому и создаются файлы для каждой партиции, что тормозит в определенных случаях (надеюсь, что с помощью ваших советов это значительно ускорится). Я же хочу переписать это решение таким образом, что необходимость в создании отдельных файлов отпадет и нужно будет создать только один файл.
> А кто-нибудь имел опыт с parallel job submitting в Spark (через scala futures)? Есть какие-нибудь подводные камни и вообще есть ли интерес в этом? Что конкретно интересует? Смысл есть всегда, когда ваш джоб не может прогреть все воркеры и они простаивают
Это не совсем верное утверждение. Если джоб 1 запустился в момент времени 1 и не выгреб все доступные ядра, то джоб 2 будет аллоцирован сразу и получит оставшиеся ядра под часть тасков