Size: a a a

Scala User Group

2020 December 11

VM

V. M. in Scala User Group
Иван Калининский
нет, не iterator=>iterator, сама смена контекста df.rdd; spark.createDataFrame(newRdd, df.schema)
т.е. изначальная коллекция меняется? если нет то проще то один раз её создать (импортировать, сохранить) и итерировать её
источник

Oℕ

Oleg ℕizhnik in Scala User Group
тогда следующий партишен не узнает об этом 0
источник

ИК

Иван Калининский... in Scala User Group
Oleg ℕizhnik
Ну это решение не будет работать. если 0 будет в самом конце партишена
такого не должно быть, если что, это поймает технический контроль данных и завершит приложение с сответствующим исключением
источник

Oℕ

Oleg ℕizhnik in Scala User Group
0 не должно быть в конце партишена?
источник

Oℕ

Oleg ℕizhnik in Scala User Group
интересно
источник

ИК

Иван Калининский... in Scala User Group
Oleg ℕizhnik
0 не должно быть в конце партишена?
не должно, если так есть, то это считается ошибкой и продолжение работы приведет к порче данных
источник

Y

Yevhen in Scala User Group
можно както в идеевские скратчи подтягивать либы проекта?
источник

Oℕ

Oleg ℕizhnik in Scala User Group
да, в скретче, как и в любом воркшите можно указывать модуль
источник

ИК

Иван Калининский... in Scala User Group
V. M.
т.е. изначальная коллекция меняется? если нет то проще то один раз её создать (импортировать, сохранить) и итерировать её
меняется, да. Вначале, когда все было на датафреймах, не было таких проблем (другие проблемы, конечно, были)), но я захотел лучшего, стал переносить обработку в собственные структуры и классы и обнаружил, что партиционирование rdd партишенером из двух строк почему-то заметно дольше выполняется, чем то же партиционирование датафрейма, а там еще и Murmur3 вычисляется и тасков больше, чтобы снизить вероятность коллизии.
Сейчас пытаюсь понять, есть ли положительный эффект на производительности, если интересно, то напишу результат, когда он будет
источник

E

Elijah in Scala User Group
Иван Калининский
Спасибо! Действительно хорошо, и в цикле и без дополнительных затрат, практически.
Тут надо понять вот что: общий объем данных, которые пойдут на вход, может достигать двух терабайт и больше, что довольно много, поэтому использовать структуру, которая должна находиться в памяти полностью - довольно дорого. Я попробую бенчмаркнуть использование Vector, и может быть, подставить вместо него Stream. Сам алгоритм, на мой взгляд, очень элегантный и идиоматичный
тогда вот так. по идее reverse не должен давать лишнего оверхеда, как было бы с обычным листом. к тому же, стрим задепрекейтили, и рекоммендуется использовать LazyList

https://scastie.scala-lang.org/ElijahLaMoon/SOz6nSvnRPSpgoV4YDazeg/28
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Elijah
тогда вот так. по идее reverse не должен давать лишнего оверхеда, как было бы с обычным листом. к тому же, стрим задепрекейтили, и рекоммендуется использовать LazyList

https://scastie.scala-lang.org/ElijahLaMoon/SOz6nSvnRPSpgoV4YDazeg/28
там 2.11
источник

E

Elijah in Scala User Group
Oleg ℕizhnik
там 2.11
а, ну земля пухом
источник

Oℕ

Oleg ℕizhnik in Scala User Group
reverse даст, конечно оверхед
источник

E

Elijah in Scala User Group
тогда стрим
источник

Oℕ

Oleg ℕizhnik in Scala User Group
он вынужден всё в память выгрузить
источник

E

Elijah in Scala User Group
Oleg ℕizhnik
он вынужден всё в память выгрузить
если вызвать reverse на LazyList, то он его не выгрузит в память
источник

E

Elijah in Scala User Group
или это позже происходит просто?
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Elijah
тогда вот так. по идее reverse не должен давать лишнего оверхеда, как было бы с обычным листом. к тому же, стрим задепрекейтили, и рекоммендуется использовать LazyList

https://scastie.scala-lang.org/ElijahLaMoon/SOz6nSvnRPSpgoV4YDazeg/28
эта реализация не O(1) от памяти
источник

Oℕ

Oleg ℕizhnik in Scala User Group
она накапливает
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Elijah
если вызвать reverse на LazyList, то он его не выгрузит в память
выгрузит
источник