Комментарии 7
"Например, Parquet чрезвычайно эффективен для запросов, потому что это столбцовое хранилище данных, хотя сжатие не так хорошо, как Avro, поскольку он сжимает данные по столбцам "
Ну что за ерунда. Хранение по столбам всегда будет иметь лучшее сжатие тк данные в столбце однородны и применение кодирования будет более эффективным чем если делать гибридное сжатие. Если вы возьмете паркет и примените в нему zstandard то получите лучшее сжатие + производительность из того что есть вообще на свете.
Так же замечу, то паркет это тоже schema evolution формат ;)
Привет, про evolution формат я не понял пункт. Он да, поддерживает, но не так как Avro, я написал, по-моему, об этом.
На счет сжатия, я не был бы так категоричен, как Вы. Но я не тестировал развернуто именно этот аспект. Вот тут есть сравнение (раздерл Preliminary tests): https://ericdraken.com/comparison-time-series-data-transport-formats/ Из которого видно, что нельзя быть категоричным, и что нужны всегда детали. Avro в этом сравнении, при определенных настройках, имеет лучшее сжатие, чем Parquet.
в вашей ссылке черным по белому написано что к авро применили компрессию снаппи а паркет вообще не сжимали (по сути там только кодироаание используется). так и кто тут категоричен? может лучше попробовать сжать самому чем "читать советские газеты"? а то при определенных настройках и мерседес жигулями покажется )
А можно пассивно-агресивный тон убрать из дискуссии?
Спасибо за указание неточности в тесте. Изучу внимательнее этот момент. Судя по еще и этой статье https://www.adaltas.com/en/2021/03/22/performance-comparison-of-file-formats/ разница не столь существенна. Возможно, в каких-то сценариях важна. У вас это важный момент?
Принимаю замечания за тон. Извиняюсь.
Формат хранения и кодек сжатия конечно выбирается в зависимости от сценария использования и от движка которым собираетесь пользоваться. Некоторые движки эффективно читают индексы в заголовках того же parquet или orc и выполняют динамическую фильтрацию что очень хорошо сказывается на производительности. Повторюсь, parquet + zstandard = лучшее сжатие не только в hdfs или s3, но и среди всех других big data не hadoop движков (greenplum,vertica, iq, hana, exadata, teradagta) Применительно к авро, по моему опыту, это же не аналитический формат. Да, запись будет быстрее, но на сложных аналитических запросах паркет и орк гораздо предпочтительнее.
В нашем случае, файлы мы используем, главным образом, чтобы иметь оригинальные данные, которые сохраниются "как есть". А аналитику вcю делаем в BigQuery, предварительно выполнив обработку файлов, приведя их к некоему формату и добавив в BQ таблицы. Таким образом мы обрабатываем входящие данные, практически, сразу, как они попадают в Data Lake. Поэтому мы ушли сначала от Parquet к Avro, а потом от Avro к JSON. В нашем случае, данные поступают с сильно разной схемой от записи к записи. Буквально, в одном и том же файле должны находиться данные с разным кол-вом колонок (в том числе и во вложенных стркутурах). Хотя, я сейчас допускаю, что мы не нашли, как это сделать в Avro.
Если не сложно, можете, пожалуйста, рассказать немного подробнее, какого характера у Вас аналитические запросы к самим файлам и как часто вы их выполняете?
Создание Data Lake и Warehouse на GCP