на дальнейшей

может имеет смысл сделать не репартишен при записи, а параллельное чтение

с partitionby не очень понятен кусок кода, я думал, что тогда надо обязательно указывать lowerbound и upperbound

чтение за минуту/две происходит, а вот с запьсиью проблема

Это AWS Glue не факт что там так можно

Если чесно я даже не понимаю

если сделать partitionby с lower/upperbound на чтении, то сразу получится несколько партиций и дальше спокойно по одной запишутся в столько потоков, сколько экзекьюторов найдётся

а можно какую-то статейку про это, что-то в доках не могу найти (

Спасибо!

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

А лучше ставьте количество репартишена так, чтоб потом хдфс от миллиона килобайтных файликов не разгребать

Джоба закончится, а тормоза - нет

Если загружать все экзекуторы при записи)

Всем привет! Подскажите пожалуйста, есть директория на хдфс с большим количеством мелких паркетов с общим размером 3.4Гб. Я хочу переложить эти файлы в новую директорию и сократить их количество для оптимизации хранения, а от старой избавиться. Соответственно прикинул количество файлов, которые мне нужно получить по окончании спарк джобы как 3.4 * 1024 / 128 ~ 28. Написал простую джобу вида spark.read.parquet().repartition(28).write.parquet(). Запустил и в результате получил 28 файлов с общим объёмом 6.1Гб, что почти в 1.6 раза больше. Почему так происходит? И можно ли как-то добиться результата близкого к оригиналу? Попробовал запустить такую же джобу с repartition(1) и получил 3.7Гб в аутпуте, но скорость работы меня не устраивает.

А сжатие какое? Может те мелкие гзипом сжаты, а у вас на выходе снаппи получился

Снаппи и там, и там

Гипер странно, что 1 файл получился меньше, чем куча мелких

Проверьте ещё раз объём на входе, на всякий пожарный, вдруг туда кто-то 15 гигов догрузил)

возможное объяснение:
1) в мелких была сортировка по некоторым полям (например какой customer_name и тд, где dictionary encoding может работать), поэтому сжатие отработало получше
2) когда делал репартишен, то это всё поплыло
3) в одном файле худо-бедно оно опять работало