Это pyspark на кластере, ООМ на драйвере при получении списка партишенов, отфильтрованных по предикату (listPartitionsByFilter)
С этим фильтром их должно получаться 365 (даты за год)
У драйвера 10G памяти, и памяти дать драйверу я могу больше, и это работает, но мне интересно понять механизм - что за метадату (?) Спарк сохраняет, что 300 партишенов вызывает у него ООМ (с моей точки зрения - это довольно небольшое число)

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

Ну так надо сделать heapdumponoutofmemoryerror и посмотреть

Какой смысл гадать на кофейной гуще когда jvm даёт всё инструменты?

Попробую, спасибо

Разбирать хипдамп потом легче всего mat - eclipse memory analyser tool

ребят, а кто-нибудь может скинуть ссылки на хорошие статьи по best practices в DE/ построение ETL и т.д. ?

@asm0dey ну все теперь будут в котлине имплиситы (https://github.com/Kotlin/KEEP/blob/context-receivers/proposals/context-receivers.md), будешь переделывать спарк котлен апи?

Это ж кип :(
Но вообще это, кажется, одна из возможных имплементаций multiple recievers, которую я давно жду и дизайн прототип которой давно в роадмапе.
А в котлин-Спарк есть буквально три функции дизайн которых это бы улучшило

А ещё давно жду тайпклассы

гвоорили ж что тупклассов и имплиситов не будет

А где ты видишь имплиситы?

Это галлюцинации, конечно

это экстеншены

читай как работает https://github.com/Kotlin/KEEP/blob/context-receivers/proposals/context-receivers.md#contextual-functions-and-property-accessors

Это просто расширенный контекст, его и сейчас можно сделать и, более того, примерно во всех dsl он используется

ресиверы ет имплиситы

А где имплиситы?

ну там так написано я не выдумываю