Получение информации из метаданных файлов - быстрая и не дорогая операция (если речь не про nrt). Если позволяют объёмы и время - лучше брать всё - но если нет, то ничто не мешает взять первый файл, первые 10 или сколько сочтёте нужным - и на их основании рассчитать. Что касается расчёт числа строк на ширину строки - это иногда применяем, но уже при записи датафрейма: зная усреднённый размер строки в сжатом виде, можно посчитать сколько строк записать в конкретный файл и репартицировать при записи (это редко применяем, потому что адаптивка в 3 спарке, в целом, хорошо справляется почти везде)
Гибкое определение (которое дальше уже называется автоопределение, т.к. появилась функция. которая позволяет определять размеры блоков) - это когда в начале каждого расчёта мы смотрим на объём данных, который у нас будет и исходя из этого задаём конфигурацию для spark. В случае с предрасчётом - мы во время тестов смотрим данные, с помощью той же функции определяем подходящие параметры, усредняем их и хардкодим.
Вся разница между гибким определением и гибким определением + repartition в том, что мы дополнительно заставляем данные перемешаться, что вызывает накладные расходы на перемещение между экзекьюторами. Это может быть полезно в определённых ситуациях - но чаще всего достаточно правильно подобрать размеры блоков для чтения.
Насколько я понима, это стандартная функциональность как для 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!
Вообще хорошо было бы проверить на разных данных(если таблица маленькая и если большая) ещё и работу с трино, и с импалой. А уж если ещё и кроме встроенных особенностей использовать оптимизации движков, дума, можно добиться ещё лучших результатов.
Разумеется нет. В статье упоминаются именно spark и hive. У коллег забирающие эти данные в кликсенс проблем тоже не было.
Так же все оптимизации и настройки были только из внутренних для orc, чтобы отвязаться от конкретного инструмента. А так для обоих форматов есть разные оптимизации на хайве, спарке и наверняка других. В орке действительно есть и Блум и acid(хоть и реализован по другому)
Если что-то из этих настроек не работает - значит уже на платформе, с которой работаете, нормально не прописали взаимодействие с форматом.
Итак, я проверил сейчас и при работе с parquet при ручном подкладывании файлов таблица сама считывает метаданные и перекладывает столбцы в правильном порядке (обратите внимание, что при чтении из файла отдельно, порядок будет "как записывали", т.е. может быть col1, col2; col2, col1; col3, col2, col1 - но в таблице будет разложено как должно). Вот пример удачного использования для parquet: если невозможно соблюдать порядок записи столбцов. В то же время в устоявшихся витринах этот плюс не сильно нужен.
Посмотрим, что ещё реализуют в ORC2.0, возможно что они переймут удачные решения parquet =)
Правильно ли я понимаю, что в ORC можно вставлять новые колонки только в конец таблицы
Верно. В parquet можно после создания таблицы добавить потом поле в середину и это будет работать на уровне таблицы. При этом если посмотреть старые файлы, там останется всё "как было".
В итоге приведет нас к беспорядку, данные в таблице лягут не в те колонки и перепутаются? Т.е. только данные из 1ого файла лягут нормально, остальные данные поедут.
Данные кладутся, как их будете записывать. Если у колонок будет одинаковый тип данных - да, в таблице они перепутаются (как и в parquet, так и в orc в описанном вами случае, если просто "подкладывать" файлы).
Таблица с ORC просто не даст добавить в таблицу поле в середину - только в конец, иначе выдаст ошибку. С Parquet - даст. Но если просто класть внутрь файлы с случайным порядком колонок будет перепутано при совпадении типов или ошибка при не совпадении.
Получение информации из метаданных файлов - быстрая и не дорогая операция (если речь не про nrt). Если позволяют объёмы и время - лучше брать всё - но если нет, то ничто не мешает взять первый файл, первые 10 или сколько сочтёте нужным - и на их основании рассчитать. Что касается расчёт числа строк на ширину строки - это иногда применяем, но уже при записи датафрейма: зная усреднённый размер строки в сжатом виде, можно посчитать сколько строк записать в конкретный файл и репартицировать при записи (это редко применяем, потому что адаптивка в 3 спарке, в целом, хорошо справляется почти везде)
Привет!
Да, это действительно не вошло в статью - слишком много кода в статье начинают путать =) Подробнее есть в коде на git (ссылка есть в статье, но я только сейчас понял, что она сливается с текстом) - https://github.com/SacredDiabloPub/highload2024/blob/master/src/main/scala/GroupFunction.scala
Гибкое определение (которое дальше уже называется автоопределение, т.к. появилась функция. которая позволяет определять размеры блоков) - это когда в начале каждого расчёта мы смотрим на объём данных, который у нас будет и исходя из этого задаём конфигурацию для spark. В случае с предрасчётом - мы во время тестов смотрим данные, с помощью той же функции определяем подходящие параметры, усредняем их и хардкодим.
Вся разница между гибким определением и гибким определением + repartition в том, что мы дополнительно заставляем данные перемешаться, что вызывает накладные расходы на перемещение между экзекьюторами. Это может быть полезно в определённых ситуациях - но чаще всего достаточно правильно подобрать размеры блоков для чтения.
Насколько я понима, это стандартная функциональность как для 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.
Если с adhoc я вижу причину - регулярная необходимость добавлять столбцы и менять их порядок, то в остальных случаях я не вижу причин.
*Под разумеется име ввиду что нет единственно верного формата =)
Разумеется нет. В статье упоминаются именно spark и hive. У коллег забирающие эти данные в кликсенс проблем тоже не было.
Так же все оптимизации и настройки были только из внутренних для orc, чтобы отвязаться от конкретного инструмента. А так для обоих форматов есть разные оптимизации на хайве, спарке и наверняка других. В орке действительно есть и Блум и acid(хоть и реализован по другому)
Если что-то из этих настроек не работает - значит уже на платформе, с которой работаете, нормально не прописали взаимодействие с форматом.
Итак, я проверил сейчас и при работе с parquet при ручном подкладывании файлов таблица сама считывает метаданные и перекладывает столбцы в правильном порядке (обратите внимание, что при чтении из файла отдельно, порядок будет "как записывали", т.е. может быть col1, col2; col2, col1; col3, col2, col1 - но в таблице будет разложено как должно).
Вот пример удачного использования для parquet: если невозможно соблюдать порядок записи столбцов. В то же время в устоявшихся витринах этот плюс не сильно нужен.
Посмотрим, что ещё реализуют в ORC2.0, возможно что они переймут удачные решения parquet =)
Верно. В parquet можно после создания таблицы добавить потом поле в середину и это будет работать на уровне таблицы. При этом если посмотреть старые файлы, там останется всё "как было".
Данные кладутся, как их будете записывать. Если у колонок будет одинаковый тип данных - да, в таблице они перепутаются (как и в parquet, так и в orc в описанном вами случае, если просто "подкладывать" файлы).
Таблица с ORC просто не даст добавить в таблицу поле в середину - только в конец, иначе выдаст ошибку. С Parquet - даст. Но если просто класть внутрь файлы с случайным порядком колонок будет перепутано при совпадении типов или ошибка при не совпадении.
Да, это хороший вариант если размеры таблиц позволяют