Паркет против ORC против ORC с Snappy

Я провожу несколько тестов форматов хранения, доступных в Hive, и использую Parquet и ORC в качестве основных опций. Я включил ORC один раз со сжатием по умолчанию и один раз с Snappy.

Я читал много документов, в которых утверждается, что Parquet лучше по сложности во времени и пространстве по сравнению с ORC, но мои тесты противоположны документам, через которые я прошел.

Следуют некоторые подробности моих данных.

Table A- Text File Format- 2.5GB

Table B - ORC - 652MB

Table C - ORC with Snappy - 802MB

Table D - Parquet - 1.9 GB

Для моего стола хуже всего было сжатие паркета.

Мои тесты с приведенными выше таблицами дали следующие результаты.

Операция подсчета строк

Text Format Cumulative CPU - 123.33 sec

Parquet Format Cumulative CPU - 204.92 sec

ORC Format Cumulative CPU - 119.99 sec 

ORC with SNAPPY Cumulative CPU - 107.05 sec

Сумма операции столбца

Text Format Cumulative CPU - 127.85 sec   

Parquet Format Cumulative CPU - 255.2 sec   

ORC Format Cumulative CPU - 120.48 sec   

ORC with SNAPPY Cumulative CPU - 98.27 sec

Среднее значение операции столбца

Text Format Cumulative CPU - 128.79 sec

Parquet Format Cumulative CPU - 211.73 sec    

ORC Format Cumulative CPU - 165.5 sec   

ORC with SNAPPY Cumulative CPU - 135.45 sec 

Выбор 4 столбцов из заданного диапазона с помощью предложения where

Text Format Cumulative CPU -  72.48 sec 

Parquet Format Cumulative CPU - 136.4 sec       

ORC Format Cumulative CPU - 96.63 sec 

ORC with SNAPPY Cumulative CPU - 82.05 sec 

Означает ли это, что ORC быстрее Parquet? Или есть что-то, что я могу сделать, чтобы он лучше работал с временем ответа на запрос и степенью сжатия?

Благодарность!

Я бы сказал, что у обоих этих форматов есть свои преимущества.

Parquet может быть лучше, если у вас есть сильно вложенные данные, потому что он хранит свои элементы в виде дерева, как это делает Google Dremel ( см. Здесь ).
Apache ORC может быть лучше, если ваша файловая структура плоская.

И насколько мне известно, паркет пока не поддерживает Индексы. ORC поставляется с облегченным индексом, а начиная с Hive 0.14 - с дополнительным фильтром Блума, который может быть полезен для лучшего времени ответа на запрос, особенно когда речь идет о суммировании операций.

Сжатие Parquet по умолчанию - SNAPPY. Таблицы A - B - C и D содержат один и тот же набор данных? Если да, похоже, что в этом есть что-то сомнительное, когда он сжимается только до 1,9 ГБ

Вы видите это, потому что:

• У Hive есть векторизованный считыватель ORC, но нет векторизованного считывателя паркета.

• В Spark есть векторизованный считыватель паркета и нет векторизованного считывателя ORC.

• Spark лучше всего работает с паркетом, hive - с ORC.

Я видел похожие различия при запуске ORC и Parquet с Spark.

Векторизация означает, что строки декодируются партиями, что значительно улучшает локальность памяти и использование кеша.

(правильно с Hive 2.0 и Spark 2.1)

И Parquet, и ORC имеют свои преимущества и недостатки. Но я просто стараюсь следовать простому практическому правилу - «Насколько вложены ваши данные и сколько там столбцов» . Если вы следите за Google Dremel, вы можете узнать, как устроен паркет. Они используют иерархическую древовидную структуру для хранения данных. Больше гнездо, глубже дерево.

Но ORC разработан для плоского хранилища файлов. Поэтому, если ваши данные сглажены с меньшим количеством столбцов, вы можете использовать ORC, иначе паркет вам подойдет. Сжатие уплощенных данных прекрасно работает в ORC.

Мы провели сравнительный анализ большого плоского файла, преобразовали его в Spark Dataframe и сохранили в формате parquet и ORC в S3, а также выполнили запросы с помощью ** Redshift-Spectrum **.

Size of the file in parquet: ~7.5 GB and took 7 minutes to write
Size of the file in ORC: ~7.1. GB and took 6 minutes to write
Query seems faster in ORC files.

Вскоре мы проведем сравнительный анализ вложенных данных и обновим результаты здесь.

Мы провели сравнительный тест, сравнивая различные форматы файлов (Avro, JSON, ORC и Parquet) в разных случаях использования.

https://www.slideshare.net/oom65/file-format-benchmarks-avro-json-orc-parquet

Все данные общедоступны, а исходный код эталонного теста открыт по адресу:

https://github.com/apache/orc/tree/branch-1.4/java/bench

У обоих есть свои преимущества. Мы используем Parquet при работе вместе с Hive и Impala, но просто хотели указать несколько преимуществ ORC перед Parquet: во время длительных запросов, когда Hive запрашивает таблицы ORC, GC вызывается примерно в 10 раз реже . Может быть пустяком для многих проектов, но может иметь решающее значение для других.

ORC также занимает гораздо меньше времени, когда вам нужно выбрать всего несколько столбцов из таблицы. Некоторые другие запросы, особенно с объединениями, также занимают меньше времени из-за выполнения векторизованных запросов, что недоступно для Parquet.

Кроме того, сжатие ORC иногда бывает немного случайным, тогда как сжатие Parquet намного более согласованное. Похоже, когда таблица ORC имеет много столбцов с числами - она ​​тоже не сжимается. Это влияет как на zlib, так и на быстрое сжатие