Это делаем, но проблема в том, что это всё операции постфактум когда уже случилась фигня. Хочется такое предупреждать заранее (мечты) или в процессе работы до того как результат повлиляет на всех.

Парни пока действительно решили вопрос так: будем обрабатывать меньше данныз для обучения модели.  ¯\_(ツ)_/¯

Формул не знаю, сами эмпирически подбираем, после нескольких прогонов оптимальные параметры. И также бывает когда есть какие-то задержки и пачка становится огромной, то по памяти вылетает

Обычный совет размазать объёмы по всем воркерам, чтобы избегать проблем с памятью при больших джойнах это шафл партишинс выкручивать, но в конце надо обязательно делать репартишн, а то ещё то счастье получить можно

Всем привет!
Подскажите, пожалуйста, можно ли Спарком прочитать в один датафрейм папку, где лежат несколько csv-файлов с разным числом колонок?
Отсутствующие колонки можно оставить NULL.

Я знаю, что вроде бы можно явно прокинуть желаемую схему как параметр при чтении, но может есть ещё какая-нибудь магия

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

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

Пробовал. Если без параметров - то возвращает датафрейм с общими колонками, отсутствующие отбрасывает

а с параметрами какой результат?

У нас есть такой кейс. Просто в каждом экзекьютере поднимается отдельный тред на получение актуальных данных. Можно напрямую из апи, можно через свой периодически обновляемый кэш. Наверное можно было сделать лучше,  но банально и работает.

когда говорите "данные могут измениться" означает ли это, что по одному и тому же ключу получим разные схемы после обновления?

у меня был похожий кейс: приходящие сообщения имели ключ схемы. за схемой нужно было сходить в апи

делал примерно так: датафрейм разбивал на рандомные партиции, далее - foreachPartition (вроде) внутри его поднимался коннект к апи с кешем. делать рефреш кэша не требовалось, т. к. одному ключу всегда соответствовала одна схема. когда приходила новая схема - в апи нужно было сходить только 1 раз на 1 партицию, далее у партиции уже она была в кэше

можно еще сделать следующи паттерн: при обновлении схемы отправлять новую схему в кафку (или что там у вас) и делать broadcast join схем (которых, наверное, немного) с самой датой

да

я понимаю, что можно на каждый триггер долбить апи в экзекуторе и получать самое свежее. но не хочется раз в 5 секунд с пары десятков экзекуторов долбить апи.

долбить апи вроде никто не предлагал 🤔

Мэтью Роклин решил тут покликбейтить, но внутри все более-менее по делу https://coiled.io/blog/dask-as-a-spark-replacement/

Что за хрень происходит в последнее время?
Какой-то исключительно странный спам попер

Ты про даск?