Comments 13
Правильно ли я понимаю, что в ORC можно вставлять новые колонки только в конец таблицы? Любые операция типа:
Вставка колонки в середину;
Запись файл в каталог с таблицей с другим порядком колонок;
Запись файлов с другим составом колонок, например, добавить в середину файла не объявленной в таблице колонки.
Например в каталоге 3 файла:
- 1ый файл - кол1, кол2
- 2ой файл - кол2, кол1
- 3ий файл - кол1, кол3, кол2
Но таблица в Hive объявлена как: кол1, кол2.
В итоге приведет нас к беспорядку, данные в таблице лягут не в те колонки и перепутаются? Т.е. только данные из 1ого файла лягут нормально, остальные данные поедут.
Решает ли эту проблему parquet? Учитывая, что вы говорите, что этот формат позволяет вставлять колонки в середину файла.
Правильно ли я понимаю, что в ORC можно вставлять новые колонки только в конец таблицы
Верно. В parquet можно после создания таблицы добавить потом поле в середину и это будет работать на уровне таблицы. При этом если посмотреть старые файлы, там останется всё "как было".
В итоге приведет нас к беспорядку, данные в таблице лягут не в те колонки и перепутаются? Т.е. только данные из 1ого файла лягут нормально, остальные данные поедут.
Данные кладутся, как их будете записывать. Если у колонок будет одинаковый тип данных - да, в таблице они перепутаются (как и в parquet, так и в orc в описанном вами случае, если просто "подкладывать" файлы).
Таблица с ORC просто не даст добавить в таблицу поле в середину - только в конец, иначе выдаст ошибку. С Parquet - даст. Но если просто класть внутрь файлы с случайным порядком колонок будет перепутано при совпадении типов или ошибка при не совпадении.
Но если просто класть внутрь файлы с случайным порядком колонок будет перепутано при совпадении типов или ошибка при не совпадении.
У parquet тоже перепутаются? По названиям колонок в файле и таблице hive не сопоставляются?
А такого решения ни с одним форматом нет, чтобы таблица находила интересующую её колонку в каждом файле не зависимо от порядка хранения колонок в файлах и правильно выводила данные?
Итак, я проверил сейчас и при работе с parquet при ручном подкладывании файлов таблица сама считывает метаданные и перекладывает столбцы в правильном порядке (обратите внимание, что при чтении из файла отдельно, порядок будет "как записывали", т.е. может быть col1, col2; col2, col1; col3, col2, col1 - но в таблице будет разложено как должно).
Вот пример удачного использования для parquet: если невозможно соблюдать порядок записи столбцов. В то же время в устоявшихся витринах этот плюс не сильно нужен.
Посмотрим, что ещё реализуют в ORC2.0, возможно что они переймут удачные решения parquet =)
Да, согласен, что не нужен. Просто возник спор с коллегой насчёт того, что Spark ругается, когда несоответствие в составе колонок происходит. Проблему порядка колонок я обхожу тем, что в конце всех преобразований вызываю select(columns.map(col):_*)
А он предлагает подкладывать файлы в каталог и не писать через таблицу и не заморачиваться с колонками порядком колонок.
Я считаю это добавит лишних проблем: отсутствие контроля ETL, если мы без контрольно пишем файлы с любым порядком и составом колонок. Тем более ORC не позволяет этого делать. Да я и сам сталкивался с это проблемой пересоздание таблицы с другим порядком колонок, поверх существующих файлов приводит к перемешиванию данных.
Но это довольно странно на самом деле, что информация доступна о положении колонок в файле, но в таблице она не учитывается для каждого файла в таблице.
нет самого главного - выбирать формат надо еще в зависимомти от того каким движком вы его читать и писать собираетесь!! а то неокрепшие умы почитают про тесты с хайв и побегут внедрять ) а то у вас орк и сжимает лучше и блум умеет и даже acid
Разумеется нет. В статье упоминаются именно spark и hive. У коллег забирающие эти данные в кликсенс проблем тоже не было.
Так же все оптимизации и настройки были только из внутренних для orc, чтобы отвязаться от конкретного инструмента. А так для обоих форматов есть разные оптимизации на хайве, спарке и наверняка других. В орке действительно есть и Блум и acid(хоть и реализован по другому)
Если что-то из этих настроек не работает - значит уже на платформе, с которой работаете, нормально не прописали взаимодействие с форматом.
*Под разумеется име ввиду что нет единственно верного формата =)
Формат и его настройки (кодеки компрессии и тд) выбираются исходя из движков и задач которые будуете решать. Если например у меня Impala или Trino для ad-hoc или etl pipeine то я даже рассматривать orc не буду
А можете раскрыть почему? Для кругозора интересно понять почему в приведенных примерах не подходит формат ORC.
Если с adhoc я вижу причину - регулярная необходимость добавлять столбцы и менять их порядок, то в остальных случаях я не вижу причин.
Потому что этими движками в паркете используется storage index и page index (в новых версиях паркета) что делает такую связку самым производительным решением для такого класса задач.
Насколько я понима, это стандартная функциональность как для ORC, так и для parquet. И если верить changelog impala она уже это прекрасно поддерживает и для ORC (повторсь, для обоих форматов это встроенная возможность, которая не завязана на движок)
У trino тоже нет проблем вроде как с этим, а если верить этой статье (аж 2019 года), то и работает он там достаточно быстро https://trino.io/blog/2019/04/23/even-faster-orc.html. Можно ещё обратить внимание на фразу там:
Trino is known for being the fastest SQL on Hadoop engine, and our custom ORC reader implementation is a big reason for this speed – now it is even faster!
Вообще хорошо было бы проверить на разных данных(если таблица маленькая и если большая) ещё и работу с трино, и с импалой. А уж если ещё и кроме встроенных особенностей использовать оптимизации движков, дума, можно добиться ещё лучших результатов.
Форматы ORC и Parquet на базе HDFS