NN
Ну, я так понимаю, мб листинг сократился из-за того, что вы неймноду разгрузили. А расчеты там какие у вас - дохера широких трансформаций, или в основном всякие селекты и выгрузки?
Size: a a a
2021 June 16
СХ
фуллсканы, после которых идёт обогощение
СХ
и запись
AZ
Мелкие файлы не только неймноду травмируют, джобы тоже тормозят
NN
А, ну, тогда наверное, для тебя это норм решение.
СХ
у нас сплошные фуллсканы
AZ
Колоночное сжатие работает тем лучше чем больше файл, меньше данных с дисков (в сумме)поднимать надо
AZ
Это первое что надо делать в любом даталейке, внедрять мониторинг размеров файлов, наказывать виновных, давать плохим командам джобы для компакции
NN
Блин, я вот сколько през не посмотрел, в том числе от тех же датабриксов - все как один говорят, что лучше файлы по 100-200 мб примерно, потому что эмпирически так шаффла меньше. Ну и у меня опыт такой же, здоровенные файлы ничего, кроме проблем, не вызывали - еле читаются, параллелизм снижается.
А
dw.write.option("maxRecordsPerFile", N")
AZ
200 мб это не мелкие файлы)
А
какая разница, если спарк прочитает в партиции по 128мб?
NN
А, ну тогда ок. А то я часто с мнением встречаюсь, что в хадупе ничего, кроме гигабайтных файлов, не должно быть.
NN
Ну, вообще-то нет. Я вот на сколько партиций разбиваю при сохранении, вот именно столько тасок у меня и поднимается потом, если я потом эту табличку читаю, например.
А
я тестил, менял настройку spark.sql.files.maxPartitionBytes и у меня менялось число партиций на входе
NN
Ну так и я тестил, и у меня тасок ровно столько, сколько партиций было создано.
Мб это зависит от формата/метастора/etc?
Мб это зависит от формата/метастора/etc?
А
странно, может файл был записан в 1 блок, как в соседнем чате обсуждалось. Надо еще раз проверить..
СХ
ну у нас орки
NN
У нас тоже
СХ
у нас орк и авро, - 80% орков и 20% авро