Комментарии 12
говорят ORC поддерживает update, правда ли это и есть ли где почитать как именно это делается? перезаписывает весь файл?

формат ORC поддерживает транзакции, реализации формата (например, Hive) — проверьте свою версию (в нашем кластере Hive поддерживает транзакции). Почитать можно там же — вот короткая ссылка (https://orc.apache.org/docs/acid.html), достаточно подробно написано.


Если совсем кратко — то перезаписывается конечно же не весь файл (на то есть партиции), с поддержкой ACID в HDFS появляются базовые файлы и дельты. Почитайте, я погружусь в это чуть позже, если будет о чем написать — поделюсь.

Все классно, только пример на 10 тыс строк — это немного странно. Я думаю многие помнят, что размер блока в хадупе 64 или 128 мегабайт (не килобайт даже). Ну какие такие 628 байт (хотя это несомненно хорошо)? Хочется что-то более реалистичное, например, во что ужмется гигабайт более-менее случайных данных.

И да, сравнение с паркетом было бы очень интересным. Для себя я знаю минимум один недостаток ORC — его не поддерживает (или очень плохо поддерживает) Impala, по крайней мере в нашей ее версии. Это практически отсекает его использование для тех случаев, когда данные нужны конечным пользователям, которые в нашем случае как раз из Impala и пользуются.

Да, конечно, 10 тыс строк — это не про хадуп… Прекрасно понимаю, но просто абсолютные цифры поразили воображение (и подтолкнули разобраться).


На больших файлах получается тоже неплохо: CSV — 38 ГБ, ORC — 5.7 ГБ, какой вклад внесло просто сжатие (этот ORC, конечно же, его использует), какой — кодирование, сколько "съели" индексы — надо разбираться.


С паркетом сравню, про Impala — да, это так. Причина, как мне кажется, как раз в том, что воспользоваться всеми возможностями ORC сложно. Научатся со временем (надеюсь...).

Буду очень признателен если после описани различных форматов родится статья подведение итогов с плюсами и минусами и примерами.

>CSV — 38 ГБ, ORC — 5.7 ГБ
сравнить с паркетом еще интереснее. У меня примерно в 10 раз зачастую различается размер просто паркета, и паркета со сжатием. При этом сжатий этих больше одного, что еще добавляет вариантов.

про сжатие достаточно объяснимо (чудес не бывает), разные алгоритмы сжатия по-разному работают на разных данных — тоже понятно.


Сравню, напишу — согласен, "итого" напрашивается, только еще раз подчеркну — сравнивать получится не форматы, а то, как hive (видимо, сравнивать буду на нем) "умеет" ими пользоваться.

Да, насчет hive — вполне логично. Можно еще spark, есть некоторые различия.
Было бы интересно увидеть статью-сравнение форматов csv, orc и parquet.
В частности больше акцент на то, чем придется пожертвовать, если выбирается какой-то формат, а не другой (но тут наверно также придется раскрыть не только данные о самих фалйах-испытателях, но и о том, что за окружение, сколько нод и всё такое).

Очень интересно, поскольку в ходе работы на проекте были вынуждены экстренно переезжать на orc исключительно, но мб просто что-то «неправильно приготовили»

Понял про интерес к сравнению, с csv сравнивать можно только как с самым худшим из возможных случаев (медленный и большой). Сравнение с паркетом последует.

Про колонку X разобрались (хотя неясно почему именно 511 было выбрано оптимальным числом строк). А что по поводу Y?

511 никто не выбирал :-), это максимально возможное при использовании дельта-кодирования количество значений в одном run-е…
В колонке Y все симметрично, просто там шаг другой (не 1, а 3), рекомендую посмотреть jupyter notebook — обновил статью, вставил ссылку на гитхаб, где лежит книжка с разбором формата: там все подробно (и можно попробовать самому)

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.