Паркет против 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 быстрее, чем Паркет? Или есть что-то, что я могу сделать, чтобы улучшить работу с временем отклика и коэффициентом сжатия?

Спасибо!

Ответ 1

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

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

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

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

Ответ 2

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

В улье есть векторизованный читатель ORC, но без векторизованного считывателя паркета.
Spark имеет векторизованный считыватель паркета и без векторизованного считывателя ORC.
Spark лучше всего работает с паркетами, hive лучше всего работает с ORC.

Я видел подобные различия при работе ORC и Parquet с Spark.

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

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

Ответ 3

Мы провели несколько тестов, сравнивая различные форматы файлов (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

Ответ 4

Два самых больших соображения для ORC над паркеем в улье:

Многие улучшения производительности, представленные в инициативе Stinger, зависят от особенностей формата ORC, включая индекс уровня блока для каждого столбца. Это приводит к потенциально более эффективному вводу-выводу, позволяя Hive пропускать чтение целых блоков данных, если он определяет значения предиката, которых нет. Оптимизатор затрат также имеет возможность рассматривать метаданные уровня столбца, присутствующие в файлах ORC, для генерации наиболее эффективного графика.

Операции ACID возможны только при использовании ORC в качестве формата файла.

Несколько соображений для Паркета над ORC в Spark: 1) Простое создание Dataframes в искры. Нет необходимости указывать схемы. 2) Работает с сильно вложенными данными.

Искра и паркет - хорошая комбинация

Ответ 5

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

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

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

Ответ 6

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

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

Мы провели некоторый сравнительный анализ с более крупным плоским файлом, преобразовали его в искровой Dataframe и сохранили его в формате паркет и 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.

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