Вообще я ни разу не против спарка, но у всего есть своя ниша, в большинстве клиентских архитектур Спарк это инструмент для пайплайнов и местами ДС, а в конце данные попадают в redshift, big query или vertica, и для своих задач они конечно лучше подходят

Я пока от коллег ещё не слышал позитивных отзывов о ДС на спарке, и сатанистов, которые на нем делают МЛ, ещё не встречал. Но должен отметить, что и круг знакомых у меня небольшой. У вас есть позитивный опыт, или есть какие-то плюсы для МЛ на спарке?

А чем они учат мл бигдатой?

Я пока от коллег ещё не слышал позитивных отзывов о ДС на спарке, и сатанистов, которые на нем делают МЛ, ещё не встречал. Но должен отметить, что и круг знакомых у меня небольшой. У вас есть позитивный опыт, или есть какие-то плюсы для МЛ на спарке?

Когда я делал консалтинг то мои клиенты в ДС в основном использовали Спарк для подготовки данных, при этом конечно они плюются и им нужно много hand holding со стороны опсов, но такие решения не от хорошей жизни

Спарк для ДС в таких случаях это проявление shadow IT, когда в Вертику или Терадату айтишные начальники непускают (хотя verticapy или teradataml гораздо удобнее чем pyspark, это те же датафреймы но не надо думать о числе экзекьюторов, памяти, очередях в ярне и вот это все)

Мне казалось, что для ДС куда привычнее тот же пандас и привычные МЛ фреймворки в питоне.

Ну как раз идея библиотек как verticapy и teradataml в том что у пользователя датафрейм API передранный с пандас, он транслируется в SQL (со всеми возможностями базы), и всегда можно сказать df.to_pandas, тогда весь датафрейм выкачивается и становится локальным

Понял. Полагаю, с той же целью датабрикс делает коалас.

Мне кажется, обычно все делают интуитивно, а не реальной loseless decomposition для нормализации

Народ, есть куча паркет файлов в S3 bucket, в которые нужно добавить несколько полей из других паркет файлов по ключу. Пока что видится это всё как lambda + glue pyspark dataframe -> S3. Вопрос: а как быть если файл большой и не помещается в памяти? Можно ли как-то распараллелить чтение паркета, чтобы glue job не вывалилась из-за нехватки памяти?
Дополнение:
В одном случае нужно сохранять как паркет (то есть один к одному), в другом объединять содержимое нескольких бакетов в zip file.

Athena + CTAS?

У нас есть этап data lake, etl , data lake, а затем уже аналитика типа athena и т.д.
Перепрыгнуть не получится.

Про ml и возврат к СУБД - наверное, пока на kaggle и подобных площадках не начнут чуваки выигрывать с использованием ml на СУБД, возврат с СУБД не произойдёт. Точнее это один из возможных путей захвата рынка) потому что в основном подходы к ml промышленному транслируются от туда.(наприсем тот же xgboost от туда стал хайповым)