Самый надежный

Пробовал, никому не советую

Минусы: Пришлось доработать чуть-чуть, код оставил неприятное впечатление, можно было сделать лучше. Уплотнение как цена за быстрый update/delete есть, конечно, но сделать его на ограниченных ресурсах затруднительно. Также не совсем понял, как можно влиять на размер файла, но тогда еще я не сильно упирался, не было критично. Куча проблем с совместимостью версий hive, насчет impala - полтора года назад поддержки не было

Из плюсов - строки по индексу достаются невероятно быстро для файлового формата, впрочем, хорошая реализация бакетов должна работать примерно также. Быстрые изменения данных, изолированные от текущих чтений. Относительно удобная организация таблицы по сегментам. Возможность создания mat views с автообновлением.

в орке файл побит на страйпы, где хранится статистика (min/max) и части файла могут не читаться целиком, если нет соотвествия в pushdown фильтре

@Pihel в паркете всё точно так же сделано, в орке вроде ещё блумфильтры есть, в паркете не уверен

да, все так, есть еще блум фильтры

@KaiNie_R импала да, не было и маловероятно что когда-либо будет, они даже орк не завезли нормально
скажем спасибо плюсовым реализациям форматов в импале

Блум в паркете есть (не пользовался, но статью читал), но вот когда я стал смотреть min/max в футере паркета, они сохранены как байтовые массивы, а байты в Java имеют знак и не всегда совпадали с представлением в беззнаковом виде, тот же DecimalType или строка в UTF-8, в данных были значения как больше max из футера, так и меньше min из футера! Я был очень расстроен, потому что хотел их взять и использовать в явном виде

Может содержание футера parquet зависит от реализации writer, не разбирался, потому что не представлял, как заменить эту реализацию, не был уверен, что записанные файлы читаться пользователями без проблем. Просто стал делать свои бакеты и складывать граничные значения отдельно, по этой информации можно получить отдельные строки за секунды на десятках терабайт (400000-600000 файлов). Разумеется, если обращаться по ключу, который используется в бакетах, по другим полям так не сработает, и это вполне естественно

Кстати если кому-то надо сделать публикацию (или ведет студентов которым надо), отличная тема - обзор работы PDO по Parquet/ORC для разных компьют фреймворков - и в журнал возьмут, и на конференцию.. У меня был студент который было начал, но отвалился в середине семестра :(

Похоронили штоле?

Как лучше смерджить куски 10ГБ данных с 20 шардов при размере оперативки в 65ГБ? Задача сделать один паркет файл и присоединить к hive table.

Публикации часто ограничиваются тем, что показывают планчик spark, в котором видно pushed-down predicate ‘x’=42, спасибо, так и мы можем)) Хорошо бы сделать действительно жирную статью, где и плюсы и минусы, и как вообще к этому подойти. Но я вот работаю только с parquet, а тут я видел ссылку на интересный материал по ORC, но паркет там не упоминался. Если делать коллективно, значит надо договариваться, обмениваться опытом, работать в общем ^^

На Rust бы допилили поддержку parquet, было бы здорово.

не то чтобы похоронили, но сообщество очень маленькое и adoption снижается

Для простых кейсов pyarrow работает, но на больших файлах вылетает.

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

можно ссылку на орк? мы активно в хайв испольузем орк

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

Конечно можно, я думаю, вам будет приятно увидеть свой материал, впрочем, вряд ли там будет что-то для вас новое и неизвестное ))
http://blog.skahin.ru/2019/08/orc.html

:)