свои сурсы видать не определял никогда?

Начал вот, чтобы не пользоваться rdd снаружи, пока в процессе. Но сорс не цель, а средство

да я про олдскульность

А чем плоха старая школа? Опыт и надёжность ей сопутствуют
Я имел в виду, сохранять колонки с повторяющиеся именами в rdbms-like схемах я не пытался и не буду никаким способом, ни старым ни новым))

Ещё немного поясню:

https://habr.com/ru/company/otus/blog/529684/

Вот такую статью мне посоветовали, когда я встретил некоторые проблемы с вызовом rdd, если коротко, в ней говорится: "не используйте rdd". При том, что подход в самой статье не продуманный и поверхностный, catalyst и tungsten разработаны не просто так, и кодеген очень мощная фича. Это, конечно, не отменяет того, что rdd положены в основу и с ними можно работать при создании кастомных расширений, в том числе датасорсов. Но необязательно, вот пример DataSourceV2:

https://aamargajbhiye.medium.com/speed-up-apache-spark-job-execution-using-a-custom-data-source-fd791a0fa4b0

Может V2 чем-то нехорош?

абсолютно не понимаю как это и причем вообще тут)

мой комментарий был что в рдд нет ничего олдскульного; их ничем не заменили и не заменят
иногда они необходимость

ну а про сурсы комментарий что под капотом ты всеравно помнишь об RDD[InternalRow] которые когда ничего не работают выползают

одно время было просто популярно говорить про устаревание рдд и что там чтото ‘депрекейтед’
это лишь спекуляции датабрикс которые уже и никто не помнит (надеюсь)

В целом согласен, и в джоинах (*JoinExec и прочие классы в execution) везде RDD[InternalRow]. Я ещё очень долго буду эти джоины ковырять))
И всё же это дальше и дальше убирают под капот, под крышки на восьми болтах

Всем привет.
Вопрос такой: во второй версии спарка была функция CalendarInterval.fromCaseInsensitiveString("delay"). Но в третьей её убрали. Вообще апи CalendarInterval сильно изменился. Так вот, что можно использовать вместо устаревшей fromCaseInsensitiveString?

Всем привет. Подскажите, пожалуйста, если мне необходимо в одной спарк сессии постоянно кэшировать датафреймы. Как то можно ограничить используемое на диске место?

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

Спасибо. то что постоянно не надо кэшировать это понятно, просто периодически это приходится делать.

Господа, привет. Кто как делает динамическое выделение стриминговым джобам?
Ситауция: стриминг джоб, читает несколько топиков кафки (всего на стейдж получается за 200 спарк-партиций). Нагрузка там неравномерная, то ручеек, то довольно много.
Собственно у меня цель, чтобы оно не жрало зазря экзекуторы, когда поток маленький.
Так вообще можно?
Я пытался покрутить разные сочетания настроек spark.dynamicAllocation.*, но выглядит так, что оно все для батчевых джобов.
А  со стримом можно чего-то такого добиться? версия 2.4.0

Добры день, у меня 100к строк, 80к сложный computation, 20к скипнуть. Как можно равномерно распределить по партициями по столбцу, в которой большой стринг парсится?

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

Первое, просто хочу, чтобы executors не простаивали

У меня парсятся html страницы

в таком случае, я делаю .repartition(numParts, monotonically_increasing_id() % numParts). Чаще советуют использовать (rand() * numParts) cast IntegerType, но я не увидел разницы в производительности даже на миллиардах записей, а monotonically_increasing_id() мне просто больше нравится

numParts можно ставить пропорционально количеству экзекуторов, ну или каким-то своим способом определить. Лучше больше, потому что .repartition применит MurMur3Hash на переданное выражение и коллизии при этом не исключены. На 80k записей неплохо будет 800 партиций, я думаю, коллизии при этом неизбежны, но в целом будет равномерно

Спасибо, потыкаю

Инженеры, можно ли через Spark 2.3.1 читать транзакционные orc таблички ? Пробовал в лоб прочитать через table - df читается схему определяет но если делаешь show или save то падает с ошибкой inputFormat