GT
Жмака
Это все в скала аппликации должно бежать
Так вы таблицу один раз создайте
Size: a a a
2020 August 31
R
В зеппелине в емр создайте просто таблицу, даже афина не нужна
А что дальше? Чем это поможет? Ну создаст человек таблицу, обратится к ней sql апи, а какой профит то?
GT
Зачем каждый раз
R
Жмака
Это просто очень медленно. Больше 3 часов
А во что упираетесь, кстати? В ядра/память, сеть, диски?
Ж
В количество данных и последовательное чтение файлов
K
Жмака
В количество данных и последовательное чтение файлов
val read = files.map(Future(spark.read(...)).sequence
K
Await.result(read,inf// я не помню )
GT
А что дальше? Чем это поможет? Ну создаст человек таблицу, обратится к ней sql апи, а какой профит то?
Действительно, сейчас подумал, что все файлы в одной директории же, ничем не поможет, если не разносить
K
Это самый минимальный кривой пример
K
Но будет работать
Ж
val read = files.map(Future(spark.read(...)).sequence
А как сюда добавить фильтр условия, groupby?
K
Жмака
А как сюда добавить фильтр условия, groupby?
Потом можно юнион сделать по всем датафреймам
K
Ну короче прочитайте параллельно и сделайте
Ж
Юнион вроде тяжелая операция
K
Жмака
Юнион вроде тяжелая операция
Сделайте и ее параллельно
K
Все простите , я на скалах пошёл лазить , если нужно , давайте вечером
R
Только union all, скорее всего, а не просто union
Ж
Все простите , я на скалах пошёл лазить , если нужно , давайте вечером
Буду рад помощи. Спасибо
ИК
Жмака
Юнион вроде тяжелая операция
в общем, да, хоть и говорят, что union - простая трансформация, но если объединяются несколько сотен, а тем более тысяч элементов, то выполняется невероятно долго, эта проблема уже обсуждалась здесь или в moscow spark
ИК
элемент = датафрейм