Size: a a a

Scala User Group

2020 September 06

K

KrivdaTheTriewe in Scala User Group
Переслано от KrivdaTheTriewe
import zio._
import zio.blocking.Blocking
def execute(path:String) = blocking.effectBlocking {
spark.read.parquet(path)
}
val load = paths.map(x => execute(x))
   ZIO.collectAllPar(load).map(x => x.reduce(_.union(_)))
источник

Oℕ

Oleg ℕizhnik in Scala User Group
KrivdaTheTriewe
Переслано от KrivdaTheTriewe
import zio._
import zio.blocking.Blocking
def execute(path:String) = blocking.effectBlocking {
spark.read.parquet(path)
}
val load = paths.map(x => execute(x))
   ZIO.collectAllPar(load).map(x => x.reduce(_.union(_)))
зачем такая фигня
источник

K

KrivdaTheTriewe in Scala User Group
Вместо паркета jdbc может быть
источник

Oℕ

Oleg ℕizhnik in Scala User Group
зачем нужно параллельно инициализировать читатели паркета
источник

Oℕ

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

K

KrivdaTheTriewe in Scala User Group
Oleg ℕizhnik
зачем такая фигня
Spark.read по сути запускает сбор метаинформации из источника, и оно будет последовательным
источник

Oℕ

Oleg ℕizhnik in Scala User Group
KrivdaTheTriewe
Spark.read по сути запускает сбор метаинформации из источника, и оно будет последовательным
яснопонятно
источник

K

KrivdaTheTriewe in Scala User Group
Oleg ℕizhnik
они же всё равно ничего не начнут читать при инициализации
Начнут читать да, а метаинформацию будут вытягивать сразу, чтобы построить оптимальный план
источник

Oℕ

Oleg ℕizhnik in Scala User Group
я думал, там совсем лениво
источник

K

KrivdaTheTriewe in Scala User Group
Oleg ℕizhnik
я думал, там совсем лениво
С rdd может быть лениво, но rdd сча не используется в велью джобах ( ну типа не стоит наверное, если тебе там прочитать , сделать что то и положить обратно в базу , а не случай как у Гриши )
источник

K

KrivdaTheTriewe in Scala User Group
Oleg ℕizhnik
я думал, там совсем лениво
Ну  и union тож последовательный будет по сути , и там при объединении 1000 датафреймов будет медленно , так что можно тоже в параллели обьединить ,
источник

K

KrivdaTheTriewe in Scala User Group
Но , стоит ещё почитать всякие настройки, возможно опций каких добавили , чтобы этой ерундой не заниматься
источник

K

KrivdaTheTriewe in Scala User Group
Oleg ℕizhnik
я думал, там совсем лениво
Но вообще идея твоя верна, она как минимум даёт гарантиии того , что либо данные загрузятся  полностью, либо  будет фейл
источник

Oℕ

Oleg ℕizhnik in Scala User Group
KrivdaTheTriewe
Ну  и union тож последовательный будет по сути , и там при объединении 1000 датафреймов будет медленно , так что можно тоже в параллели обьединить ,
а sc.union вот
источник

Oℕ

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

K

KrivdaTheTriewe in Scala User Group
Да
источник

Oℕ

Oleg ℕizhnik in Scala User Group
понятно
источник

K

KrivdaTheTriewe in Scala User Group
Oleg ℕizhnik
а sc.union вот
Ну  у тебя тут rdd, чисто теоретически, наверное , твой код будет сильно быстрее , чем над датафреймами, и над распараллеливанием можно не задумываться, но лучше писать на датафреймах или датасетах
источник

λ

λoλdog in Scala User Group
Непривычно видеть Олега в Спарк дискуссиях
источник

Oℕ

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