Комментарии 12
формат ORC поддерживает транзакции, реализации формата (например, Hive) — проверьте свою версию (в нашем кластере Hive поддерживает транзакции). Почитать можно там же — вот короткая ссылка (https://orc.apache.org/docs/acid.html), достаточно подробно написано.
Если совсем кратко — то перезаписывается конечно же не весь файл (на то есть партиции), с поддержкой ACID в HDFS появляются базовые файлы и дельты. Почитайте, я погружусь в это чуть позже, если будет о чем написать — поделюсь.
И да, сравнение с паркетом было бы очень интересным. Для себя я знаю минимум один недостаток ORC — его не поддерживает (или очень плохо поддерживает) Impala, по крайней мере в нашей ее версии. Это практически отсекает его использование для тех случаев, когда данные нужны конечным пользователям, которые в нашем случае как раз из Impala и пользуются.
Да, конечно, 10 тыс строк — это не про хадуп… Прекрасно понимаю, но просто абсолютные цифры поразили воображение (и подтолкнули разобраться).
На больших файлах получается тоже неплохо: CSV — 38 ГБ, ORC — 5.7 ГБ, какой вклад внесло просто сжатие (этот ORC, конечно же, его использует), какой — кодирование, сколько "съели" индексы — надо разбираться.
С паркетом сравню, про Impala — да, это так. Причина, как мне кажется, как раз в том, что воспользоваться всеми возможностями ORC сложно. Научатся со временем (надеюсь...).
Буду очень признателен если после описани различных форматов родится статья подведение итогов с плюсами и минусами и примерами.
сравнить с паркетом еще интереснее. У меня примерно в 10 раз зачастую различается размер просто паркета, и паркета со сжатием. При этом сжатий этих больше одного, что еще добавляет вариантов.
про сжатие достаточно объяснимо (чудес не бывает), разные алгоритмы сжатия по-разному работают на разных данных — тоже понятно.
Сравню, напишу — согласен, "итого" напрашивается, только еще раз подчеркну — сравнивать получится не форматы, а то, как hive (видимо, сравнивать буду на нем) "умеет" ими пользоваться.
В частности больше акцент на то, чем придется пожертвовать, если выбирается какой-то формат, а не другой (но тут наверно также придется раскрыть не только данные о самих фалйах-испытателях, но и о том, что за окружение, сколько нод и всё такое).
Очень интересно, поскольку в ходе работы на проекте были вынуждены экстренно переезжать на orc исключительно, но мб просто что-то «неправильно приготовили»
511 никто не выбирал :-), это максимально возможное при использовании дельта-кодирования количество значений в одном run-е…
В колонке Y все симметрично, просто там шаг другой (не 1, а 3), рекомендую посмотреть jupyter notebook — обновил статью, вставил ссылку на гитхаб, где лежит книжка с разбором формата: там все подробно (и можно попробовать самому)
О сравнении форматов хранения в Hadoop: начнем с ORC