я не проверял - но легко поверю)

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

это не кастомный сурс

над спарком

ну катсомная шляпа

она легко может быть быстрее спарка))

но там тоже спарк под капотом

не только может, но и будет. потому что алгоритмика тулзы заточена под специфическую задачу, а не общего вида

+

для меня например разница между "полчаса на копирование" и "12 минут" выливается в 2х стоимость проекта напрямую для заказчика

смотрите, вы написали целый проект, который копирует логику другого проекта, в котором захардкожено куча всего , вы экономите деньги заказчику сейчас - но удорожаете поддержку этого кода вашей фирме, потому что еще одному человеку придется разбираться с нестандартными компонентами, при этом для другого заказчика придется писать цсв с другими разделителями,а не стнадратные, которые захордкожены, поэтому кономика мне не понятна. При этом можно было решить задачу в 50-100 строчек на питоне + bash / java / scala и радоваться жизни не имея проседания.
Подойти допустим творчески и решить задачу в два этапа
dist cp + отдельная обработка на спарке по конвертации в файлы
сразу сделать на спарке все

и посмотреть

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

так можно о чем угодно сказать

можно

но мы сча говорим о задаче, на  которой спарк специализируется

ну я короче конкретно не согласен сейчас
если говорить конкретно про сейчас то получается что ты считаешь что list.map(Future(spark.read)).sequence.await менее колхозно чем нормальный продуманный вариан (более ложный) под юзкейс конкретный

где-то я слышал сказку про

> При этом можно было решить задачу в 50-100 строчек на питоне + bash / java / scala и радоваться жизни не имея проседания.

особенно про питон + баш
после этого проще выкинуть чем разбираться что там написано

конечно, потому что это одна строчка условно

но никто не мешает написать скрипт который делает дистцп