spark, mapPartitions(), столкнулся с проблемой переполнения хипа практически в той же ситуации
https://stackoverflow.com/questions/42539315/apache-spark-effectively-using-mappartitions-in-java

там предложили вместо такой конструкции, которая в mapPartitions() набивает огромный ArrayList


такую


вопрос - поможет ли вторая конструкция сберечь память ?

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


в моем случае приходит длинная строка (ну в смысле в датасете миллионы строк), а в этой mapPartitions() строка парсится и в массив пихаются ошибки валидации строки. потом датасет пишет в паркет с struct полем (тот самый массив).
вот и мне кажется что по частям же return не отдаст, когда бы это код не выполнился. значит в какой-то момент ".map(s -> transformRow(s))" наплодит миллионы объектов


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

flatMap вроде если мне на одну строку надо больше одной наплодить. у меня на одну строку хоть и много ошибок, но для спрака это одна ячейка со struct значением.



не, вроде не так. RDD это по любому в памяти. после вычисления RDD, его можно закешировать/заперсистить в memory, disk/memory и т.п. что бы напимер сделав банальный терминальный count() заново не пришлось бы вычислять.
то что у меня все ерроры валидации будут в памяти RDD это понятно, но сейчас, как я понимаю, кроме RDD они еще и дублируются в ArrayList<OutObj> out

не понял идеи. если csv превышает и я сделаю repartition(1), что бы весь файл зачитывал один еднственный executor, он упадет. да.
в этом сомнений нет.
вот если бы было возможно подготовить такой файл, какой в структуры RDD влазит ровно один раз, а в виде RDD+ArrayList не влезет. но я хз как RDD хранит стринги. может более плотно чем ArrayList, а может и наоборот.

Верно.

спасибо! собственно я именно за этим ответом приходил
значит пробовать смысл есть.



1) я то ипользую датасет api, но под низом у спарка это все равно RDD. я себе представлял данные в spark как набор байтов в объекте RDD, потому казалось, что у спарка не получится сделать ссылку из RDD на мой ArrayList, ему придется deep copy в RDD делать. а это представление у меня сложилось потому, что у спарка есть проект Tungsten, который научил спарк хранить данные в off-heap.
2) да, вытягивается конфигурация описывающая колонки соответствуящая файлику и подбирается класс для парсера
3) я думаю в партицию могут попасть миллионы строк, а у строки оказалось могут быть сотни ошибок. оказалось источник может набить строки непечатными символами, каждый символ запись в массивчике.