Каковы плюсы и минусы формата паркета по сравнению с другими форматами?

Question

Характеристики Apache Parquet:

• Самоописание
• Колоночный формат
• Независимый от языка

По сравнению с Avro, Sequence Files, RC File и т. Д. Я хочу краткий обзор форматов. Я уже читал: как Impala работает с форматами файлов Hadoop, он дает некоторое представление о форматах, но я хотел бы знать, как осуществляется доступ к данным и их хранение в каждом из этих форматов. Как паркет имеет преимущество перед остальными?

Answer 1

Я думаю, что основное различие, которое я могу описать, касается форматов, ориентированных на записи и на столбцы. Форматы записи - это то, к чему мы все привыкли - текстовые файлы, такие форматы с разделителями, как CSV, TSV. AVRO немного круче, чем те, потому что он может со временем изменять схему, например, добавлять или удалять столбцы из записи. Другие приемы различных форматов (особенно включая сжатие) связаны с тем, можно ли разделить формат, то есть вы можете прочитать блок записей из любого места в наборе данных и все еще знать, что это схема? Но вот более подробно о столбчатых форматах, таких как паркет.

Паркет и другие столбчатые форматы очень эффективно справляются с обычной ситуацией Hadoop. Обычно таблицы (наборы данных) имеют намного больше столбцов, чем можно ожидать в хорошо спроектированной реляционной базе данных - сто или двести столбцов не являются необычными. Это так, потому что мы часто используем Hadoop в качестве места для денормализации данных из реляционных форматов - да, вы получаете много повторяющихся значений и множество таблиц, сведенных в одну. Но запрос становится намного проще, так как все объединения разработаны. Есть и другие преимущества, такие как сохранение данных о состоянии во времени. Так или иначе, в таблице часто встречается множество столбцов.

Допустим, есть 132 столбца, и некоторые из них являются действительно длинными текстовыми полями, каждый отдельный столбец один за другим и использует, возможно, 10 КБ на запись.

Хотя запрос к этим таблицам прост с точки зрения SQL, часто требуется получить некоторый диапазон записей, основанный только на нескольких из этих более ста столбцов. Например, вам могут потребоваться все записи в феврале и марте для клиентов с объемом продаж> 500 долларов.

Чтобы сделать это в формате строки, запрос должен будет сканировать каждую запись набора данных. Прочитайте первую строку, проанализируйте запись в полях (столбцах) и получите столбцы даты и продаж, включите их в свой результат, если он удовлетворяет условию. Повторение. Если у вас 10 лет (120 месяцев) истории, вы читаете каждую запись, чтобы найти 2 из этих месяцев. Конечно, это отличная возможность использовать раздел по годам и месяцам, но, несмотря на это, вы читаете и анализируете 10K каждой записи / строки за эти два месяца, просто чтобы определить, превышает ли объем продаж клиента 500 долларов.

В столбчатом формате каждый столбец (поле) записи хранится вместе с другими в своем роде, разбросанными по множеству различных блоков на диске - столбцы за год вместе, столбцы за месяц вместе, столбцы для справочника сотрудника заказчика (или другое длинный текст), и все остальные, которые делают эти записи такими огромными в отдельном месте на диске, и, конечно, столбцы для продаж вместе. Черт возьми, дата и месяцы - это числа, и продажи - это всего лишь несколько байтов. Разве не было бы замечательно, если бы мы только считали несколько байтов для каждой записи, чтобы определить, какие записи соответствуют нашему запросу? Колонное хранилище на помощь!

Даже без разделов сканирование небольших полей, необходимых для удовлетворения нашего запроса, выполняется очень быстро - все они расположены по порядку по записям и имеют одинаковый размер, поэтому диск ищет гораздо меньше данных для проверки включенных записей. Не нужно читать руководство для этого сотрудника и другие длинные текстовые поля - просто игнорируйте их. Таким образом, группируя столбцы друг с другом вместо строк, вы почти всегда можете сканировать меньше данных. Выиграть!

Но подождите, это становится лучше. Если ваш запрос должен был знать только эти значения и еще несколько (скажем, 10 из 132 столбцов) и не заботился об этом столбце справочника сотрудника, после того как он выбрал правильные записи для возврата, ему теперь нужно будет только перейти Вернемся к 10 столбцам, необходимым для отображения результатов, игнорируя остальные 122 из 132 в нашем наборе данных. Опять же, мы пропускаем много чтения.

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

Еще одно преимущество колонок: данные распространяются вокруг. Чтобы получить одну запись, у вас может быть 132 работника, каждый считывающий (и записывающий) данные из / в 132 разных места в 132 блоках данных. Ура за распараллеливание!

А теперь самое важное: алгоритмы сжатия работают намного лучше, когда могут найти повторяющиеся шаблоны. Вы могли бы сжать AABBBBBBCCCCCCCCCCCCCCCC как 2A6B16C но ABCABCBCBCBCCCCCCCCCCCCCC не станет таким маленьким (ну, на самом деле, в этом случае, но поверьте мне:-)). Итак, еще раз, меньше читать. И писать тоже.

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

Колонка хороша, когда ваша входная сторона велика, а ваш вывод - отфильтрованное подмножество: от большого к маленькому - отлично Не так выгодно, когда вход и выход примерно одинаковы.

Но в нашем случае Impala взяла наши старые запросы Hive, которые выполнялись через 5, 10, 20 или 30 минут и заканчивались чаще всего за несколько секунд или минут.

Надеюсь, что это поможет ответить хотя бы на часть вашего вопроса!

Answer 2

Avro - это формат хранения для Hadoop на основе строк.

Parquet - это формат хранения Hadoop на основе столбцов.

Если ваш вариант использования обычно сканирует или извлекает все поля в строке в каждом запросе, Avro обычно является лучшим выбором.

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

Источник

Answer 3

Ответ Тома довольно подробный и исчерпывающий, но вас также может заинтересовать это простое исследование о "Паркет против Авро", проведенное в Allstate Insurance, кратко изложенное здесь:

"В целом, Parquet показывал либо похожие, либо лучшие результаты в каждом тесте [чем Avro]. Различия в запросах и производительности для больших наборов данных в пользу Parquet частично связаны с результатами сжатия; при запросе широкого набора данных Spark приходилось читать 3,5x для Parquet меньше данных, чем для Avro. Avro, как и предполагалось, не показала хороших результатов при обработке всего набора данных ".

Answer 4

Выбор правильного формата файла важен для создания эффективных приложений для обработки данных. Концепции, изложенные в этом посте, переносятся на Pandas, Dask, Spark и Presto / AWS Athena.

Обрезка столбика

Отсечение столбцов - это значительное улучшение производительности, которое возможно для форматов файлов на основе столбцов (Parquet, ORC) и невозможно для форматов файлов на основе строк (CSV, Avro).

Предположим, у вас есть набор данных со 100 столбцами и вы хотите прочитать два из них в DataFrame. Вот как вы можете сделать это с помощью Pandas, если данные хранятся в файле Parquet.

import pandas as pd

pd.read_parquet('some_file.parquet', columns = ['id', 'firstname'])

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

Если данные хранятся в файле CSV, вы можете прочитать их следующим образом:

import pandas as pd

pd.read_csv('some_file.csv', usecols = ['id', 'firstname'])

usecols невозможно пропустить целые столбцы из-за строкового характера формата файла CSV.

Spark не требует, чтобы пользователи явно указывали столбцы, которые будут использоваться в запросе. Spark составляет план выполнения и по возможности автоматически использует сокращение столбцов. Конечно, отсечение столбцов возможно только в том случае, если основной формат файла ориентирован на столбцы.

Популярность

Spark и Pandas имеют встроенные средства чтения и записи для CSV, JSON, ORC, Parquet и текстовых файлов. У них нет встроенных читателей для Avro.

Avro популярен в экосистеме Hadoop. Паркет приобрел значительную популярность за пределами экосистемы Hadoop. Например, проект Delta Lake строится на файлах Parquet.

Arrow - важный проект, который упрощает работу с файлами Parquet на различных языках (C, C++, Go, Java, JavaScript, MATLAB, Python, R, Ruby, Rust), но не поддерживает Avro. С файлами Parquet легче работать, потому что они поддерживаются множеством различных проектов.

Схема

Parquet сохраняет схему файла в метаданных файла. Файлы CSV не хранят метаданные файлов, поэтому читателям необходимо либо предоставить схему, либо схему необходимо вывести. Предоставление схемы утомительно, а вывод схемы подвержен ошибкам / дорого.

Avro также хранит схему данных в самом файле. Наличие схемы в файлах - огромное преимущество и одна из причин, по которой современный проект данных не должен полагаться на JSON или CSV.

Метаданные столбца

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

Метаданные минимального / максимального значения столбца позволяют выполнять фильтрацию вниз по предикату Parquet, которая поддерживается кластерными вычислительными средами Dask & Spark.

Вот как получить статистику столбца с помощью PyArrow.

import pyarrow.parquet as pq

parquet_file = pq.ParquetFile('some_file.parquet')
print(parquet_file.metadata.row_group(0).column(1).statistics)

<pyarrow._parquet.Statistics object at 0x11ac17eb0>
  has_min_max: True
  min: 1
  max: 9
  null_count: 0
  distinct_count: 0
  num_values: 3
  physical_type: INT64
  logical_type: None
  converted_type (legacy): NONE

Сложные типы столбцов

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

Сжатие

Столбчатые форматы файлов хранят связанные типы в строках, поэтому их легче сжимать. Этот CSV-файл относительно сложно сжать.

first_name,age
ken,30
felicia,36
mia,2

Эти данные легче сжать, если связанные типы хранятся в одной строке:

ken,felicia,mia
30,36,2

Файлы Parquet обычно сжимаются с помощью алгоритма сжатия Snappy. Мгновенно сжатые файлы можно разделить и быстро раздуть. Системы больших данных хотят уменьшить размер файла на диске, но также хотят быстро раздуть мух и выполнить аналитические запросы.

Изменчивая природа файла

Файлы паркета неизменяемы, как описано здесь. Файлы CSV изменяемы.

Добавить строку в файл CSV очень просто. Вы не можете легко добавить строку в файл Parquet.

Озера данных

В среде больших данных вы будете работать с сотнями или тысячами файлов Parquet. Важно разбивать файлы на разделы, избегать больших файлов и уплотнять небольшие файлы. Оптимальная структура данных на диске зависит от ваших шаблонов запросов.

Answer 5

Я изучал различные форматы файлов, такие как Avro, ORC, Parquet, JSON, файлы деталей для сохранения данных в больших данных. И обнаружил, что напильник Parquet лучше во многих аспектах.

Вот мои выводы.

Преимущества хранения в виде файла Parquet:

1. Безопасность данных, поскольку данные не читабельны для человека
2. Низкое потребление памяти
3. Эффективное чтение данных за меньшее время, поскольку это столбчатое хранилище и минимизирует задержку.
4. Поддерживает расширенные вложенные структуры данных. Оптимизирован для запросов, обрабатывающих большие объемы данных.
5. Файлы паркета можно дополнительно сжимать.

Результаты тестирования в реальном времени с помощью Numbers:

Импорт Sqoop таблицы с 13193045 записями дал на выходе обычный размер файла 8,6 ГБ. но тот же импорт Sqoop таблицы с теми же 13193045 записями, что и файл паркета, дал выходной файл размером всего 1,6 ГБ, что дает ~ 500% экономии места.

Кроме того, мы можем создавать внешние таблицы улья, ссылаясь на этот файл паркета, а также обрабатывать данные непосредственно из файла паркета.

Хотя время, затраченное на импорт sqoop в виде обычного файла, составило всего 3 минуты, а для файла Parquet — 6 минут в виде файла, состоящего из 4 частей. Я был удивлен, увидев разницу во времени хранения файла паркета. Эта часть времени требует дополнительных исследований.