А, ну это да, когда весь диск можно по своему усмотрению разметить, это другой вопрос)

Единственное, что меня не радует в спарк бакетах - то, что они ну вот вообще никак не читаются хайвом

Так как при создании таблицы схема в хайве создаётся заведомо кривая

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

Спарк допишет новые файлы с бакетАйди, при этом потеряет сортировку

В смысле? Каким образом он дописывает на лету?

https://blog.jetbrains.com/kotlin/2021/04/ki-the-next-interactive-shell-for-kotlin/
Мы ещё для котлинспарка и шелл с автодополнением и стюардессами сделали!

В одном бакете может содержаться много файлов. Спарк хранит bucketId в имени файла прямо перед расширением (там ещё номер записанного файла, но и бох с ним)). Можно докидать файлов в бакет (напоминаю, всё дело в имени файла) и потом читать его как одну большую секцию

Сортировка в пределах секции RDD в случае одного файла на бакет гарантируется, если больше одного файла хоть в одном бакете, то дело плохо, сортировка не обеспечена

Управлять размером файлов спарк не умеет и не собирается

А стандартными средствами можно попросить спарк при аппенде данных их в уже готовый соответствующий бакет записать, или это костыль городить?

при указании такого же способа партиционирования и бакетирования, то есть, df.write.mode(SaveMode.Append).bucketBy(n,field,fields:_*).sortBy(field2,fields2:_*).saveAsTable(tableName) каждый раз будет записывать в одни и те же бакеты записи, которые дают одинаковый хеш по модулю n. Существующие файлы не будут изменены, потому что это в общем случае невозможно. Сколько бы строк ни было добавлено в бакет, будет создан минимум один новый файл в бакете

невозможно - это я говорю с точки зрения современной реализации, вообще, конечно, можно переписать файл или присоединить к нему блок, и упаковать всё это в FormatWriter, но сейчас этого совершенно точно нет в спарк 2.4.0, файлы не изменяются, только новые создаются

А где-то в коде джойна есть опора на гарантию сортировки в бакетах, или это так, для оптимизации хранения используется?

есть

пользуюсь, но очень недолго

Спасибо за инфу!

первые результаты впечатляют, шафл уменьшился на два десятичных порядка

но это с учётом специфики, джоины у всех разные))

Вот это ещё беспокоит - если аппенды мелкие, то в итоге получится неоптимально - огромное количество мелких файлов это не оч, и в итоге придется все равно это дело конкатить

да, или писать свою реализацию (это возможно) или ждать, пока сделают (не дождёмся)