Паркет проти ORC проти ORC за допомогою Snappy

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

Я прочитав багато документів, у яких зазначено, що паркет кращий за часом / простором у порівнянні з 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 швидший за паркет? Або я можу щось зробити, щоб покращити роботу із часом відгуку запиту та коефіцієнтом стиснення?

Дякую!

Я б сказав, що обидва ці формати мають свої переваги.

Паркет може бути кращим, якщо у вас є високо вкладені дані, оскільки він зберігає свої елементи у вигляді дерева, як це робить Google Dremel ( див. Тут ).
Apache ORC може бути кращим, якщо ваша файлова структура вирівняна.

І наскільки я знаю, паркет ще не підтримує покажчики. ORC постачається з невеликим індексом, а з Hive 0,14 додатковим фільтром Bloom, що може бути корисним, тим кращий час відповіді на запит, особливо коли мова йде про операції підсумовування.

Типовим стисненням паркету є SNAPPY. Чи містять таблиці A - B - C та D однаковий набір даних? Якщо так, схоже, в цьому є щось тіньове, коли воно стискається лише до 1,9 ГБ

Ви бачите це, тому що:

• У вулику є векторизований зчитувач ORC, але немає зчитувача паркету.

• У Spark є векторизований зчитувач паркету, а також не зчитується ORC.

• Іскра найкраще працює з паркетом, вулик найкраще працює з ORC.

Я бачив подібні відмінності при запуску ORC та паркету з іскоркою.

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

(виправлення щодо Hive 2.0 та Spark 2.1)

І паркет, і 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.

Незабаром ми проведемо порівняльний аналіз для вкладених даних і оновимо результати тут.

Ми провели порівняльний аналіз різних форматів файлів (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

Обидва вони мають свої переваги. Ми використовуємо паркет на роботі разом з Hive та Impala, але просто хотіли вказати на кілька переваг ORC перед паркетом: під час тривалих запитів, коли запити Hive ORC таблиці GC викликаються приблизно в 10 разів рідше . Для багатьох проектів це може бути нічим, але може мати вирішальне значення для інших.

ORC також займає набагато менше часу, коли вам потрібно вибрати лише кілька стовпців із таблиці. Деякі інші запити, особливо з об'єднаннями, також займають менше часу через векторизоване виконання запитів, яке недоступне для паркету

Крім того, стиснення ORC іноді буває трохи випадковим, тоді як стиснення паркету набагато більш послідовне. Схоже, коли таблиця ORC має багато числових стовпців - вона також не стискається. Це впливає як на zlib, так і на швидке стиснення