Что такое паркет файл

Обновлено: 09.05.2024

Parquet Files

Parquet is a columnar format that is supported by many other data processing systems. Spark SQL provides support for both reading and writing Parquet files that automatically preserves the schema of the original data. When reading Parquet files, all columns are automatically converted to be nullable for compatibility reasons.

Loading Data Programmatically

Using the data from the above example:

Find full example code at "examples/src/main/scala/org/apache/spark/examples/sql/SQLDataSourceExample.scala" in the Spark repo. Find full example code at "examples/src/main/java/org/apache/spark/examples/sql/JavaSQLDataSourceExample.java" in the Spark repo. Find full example code at "examples/src/main/python/sql/datasource.py" in the Spark repo. Find full example code at "examples/src/main/r/RSparkSQLExample.R" in the Spark repo.

Partition Discovery

Table partitioning is a common optimization approach used in systems like Hive. In a partitioned table, data are usually stored in different directories, with partitioning column values encoded in the path of each partition directory. All built-in file sources (including Text/CSV/JSON/ORC/Parquet) are able to discover and infer partitioning information automatically. For example, we can store all our previously used population data into a partitioned table using the following directory structure, with two extra columns, gender and country as partitioning columns:

By passing path/to/table to either SparkSession.read.parquet or SparkSession.read.load , Spark SQL will automatically extract the partitioning information from the paths. Now the schema of the returned DataFrame becomes:

Notice that the data types of the partitioning columns are automatically inferred. Currently, numeric data types, date, timestamp and string type are supported. Sometimes users may not want to automatically infer the data types of the partitioning columns. For these use cases, the automatic type inference can be configured by spark.sql.sources.partitionColumnTypeInference.enabled , which is default to true . When type inference is disabled, string type will be used for the partitioning columns.

Starting from Spark 1.6.0, partition discovery only finds partitions under the given paths by default. For the above example, if users pass path/to/table/gender=male to either SparkSession.read.parquet or SparkSession.read.load , gender will not be considered as a partitioning column. If users need to specify the base path that partition discovery should start with, they can set basePath in the data source options. For example, when path/to/table/gender=male is the path of the data and users set basePath to path/to/table/ , gender will be a partitioning column.

Schema Merging

Like Protocol Buffer, Avro, and Thrift, Parquet also supports schema evolution. Users can start with a simple schema, and gradually add more columns to the schema as needed. In this way, users may end up with multiple Parquet files with different but mutually compatible schemas. The Parquet data source is now able to automatically detect this case and merge schemas of all these files.

Since schema merging is a relatively expensive operation, and is not a necessity in most cases, we turned it off by default starting from 1.5.0. You may enable it by

Как использовать Parquet и не поскользнуться

О хранении данных в Parquet-файлах не так много информации на Хабре, поэтому надеемся, рассказ об опыте Wrike по его внедрению в связке со Spark вам пригодится.
В частности, в этой статье вы узнаете:

— зачем нужен “паркет”;
— как он устроен;
— когда стоит его использовать;
— в каких случаях он не очень удобен.

Наверное, стоит начать с вопроса, зачем мы вообще начали искать новый способ хранения данных вместо предварительной агрегации и сохранения результата в БД и какими критериями руководствовались при принятии решения?

В отделе аналитики Wrike мы используем Apache Spark, масштабируемый и набирающий популярность инструмент для работы с большими данным (у нас это разнообразные логи и иные потоки входящих данных и событий). Подробнее о том, как у нас работает Spark, мы рассказывали ранее.

Изначально нам хотелось развернуть систему быстро и без особых инфраструктурных изощрений, поэтому мы решили ограничиться Standalone кластер-менеджером Спарка и текстовыми файлами, в которые записывали Json. На тот момент у нас не было большого входного потока данных, так что развёртывать hadoop и т.п. не было смысла.

После нескольких недель работы мы поняли, что с json данными работать неудобно и трудоемко: медленное чтение, к тому же при многочисленных тестовых запросов каждый раз Spark вынужден сначала прочесть файл, определить схему и только потом подобраться непосредственно к выполнению самого запроса. Конечно, путь Спарку можно сократить, заранее указав схему, но каждый раз проделывать эту дополнительную работу нам не хотелось.
Покопавшись в Спарке, мы обнаружили, что сам он активно использует у себя внутри parquet-формат.

Что такое Parquet

Parquet — это бинарный, колоночно-ориентированный формат хранения данных, изначально созданный для экосистемы hadoop. Разработчики уверяют, что данный формат хранения идеален для big data (неизменяемых).
Первое впечатление — ура, со Spark наконец-то стало удобно работать, он просто ожил, но, как ни странно, подкинул нам несколько неожиданных проблем. Дело в том, что parquet ведёт себя как неизменяемая таблица или БД. Значит для колонок определён тип, и если вдруг у вас комбинируется сложный тип данных (скажем, вложенный json) с простым (обычное строковое значение), то вся система разрушится. Например, возьмём два события и напишем их в формате Json:
“event_name”: “event 1”,
“value”: “this is first value”,
>

В parquet-файл записать их не получится, так как в первом случае у вас строка, а во втором сложный тип. Хуже, если система записывает входной поток данных в файл, скажем, каждый час. В первый час могут прийти события со строковыми value, а во второй — в виде сложного типа. В итоге, конечно, получится записать parquet файлы, но при операции merge schema вы наткнётесь на ошибку несовместимости типов.

Чтобы решить эту проблему, нам пришлось пойти на небольшой компромисс. Мы определили точно известную и гарантируемую поставщиком данных схему для части информации, а в остальном брали только верхнеуровневые ключи. При этом сами данные записывали как текст (зачастую это был json), который мы хранили в ячейке (в дальнейшем с помощью простых map-reduce операций это превращалось в удобный DataFrame) в случае примера выше ‘ “value”: ‘ превращается в ‘ “value”: “” ‘. Также мы столкнулись с некоторыми особенностями разбиения данных на части Спарком.

Как выглядит структура Parquet файлов

Если коротко, Parquet использует архитектуру, основанную на “уровнях определения” (definition levels) и “уровнях повторения” (repetition levels), что позволяет довольно эффективно кодировать данные, а информация о схеме выносится в отдельные метаданные.
При этом оптимально хранятся и пустые значения.

Структура Parquet-файла хорошо проиллюстрирована в документации:

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

Row-group — это разбиение, позволяющее параллельно работать с данными на уровне Map-Reduce
Column chunk — разбиение на уровне колонок, позволяющее распределять IO операции
Page — Разбиение колонок на страницы, позволяющее распределять работу по кодированию и сжатию

Если сохранить данные в parquet файл на диск, используя самою привычную нам файловую систему, вы обнаружите, что вместо файла создаётся директория, в которой содержится целая коллекция файлов. Часть из них — это метаинформация, в ней — схема, а также различная служебная информация, включая частичный индекс, позволяющий считывать только необходимые блоки данных при запросе. Остальные части, или партиции, это и есть наши Row group.

Для интуитивного понимания будем считать Row groups набором файлов, объединённых общей информацией. Кстати, это разбиение используется HDFS для реализации data locality, когда каждая нода в кластере может считывать те данные, которые непосредственно расположены у неё на диске. Более того, row group выступает единицей Map Reduce, и каждая map-reduce задача в Spark работает со своей row-group. Поэтому worker обязан поместить группу строк в память, и при настройке размера группы надо учитывать минимальный объём памяти, выделяемый на задачу на самой слабой ноде, иначе можно наткнуться на OOM.
В нашем случае мы столкнулись с тем, что в определённых условиях Spark, считывая текстовый файл, формировал только одну партицию, и из-за этого преобразование данных выполнялось только на одном ядре, хотя ресурсов было доступно гораздо больше. С помощью операции repartition в rdd мы разбили входные данные, в итоге получилось несколько row groups, и проблема ушла.

Column chunk (разбиение на уровне колонок) — оптимизирует работу с диском (дисками). Если представить данные как таблицу, то они записываются не построчно, а по колонкам.

Представим таблицу:

Тогда в текстовом файле, скажем, csv мы бы хранили данные на диске примерно так:

В случае с Parquet:

Благодаря этому мы можем считывать только необходимые нам колонки.

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

Каждая колонка делится на страницы (Pages), которые, в свою очередь, содержат метаинформацию и данные, закодированные по принципу архитектуры из проекта Dremel. За счёт этого достигается довольно эффективное и быстрое кодирование. Кроме того, на данном уровне производится сжатие (если оно настроено). На данный момент доступны кодеки snappy, gzip, lzo.

Есть ли подводные камни?

Выводы:

Достоинства хранения данных в Parquet:

• Несмотря на то, что они и созданы для hdfs, данные могут храниться и в других файловых системах, таких как GlusterFs или поверх NFS
• По сути это просто файлы, а значит с ними легко работать, перемещать, бэкапить и реплицировать.
• Колончатый вид позволяет значительно ускорить работу аналитика, если ему не нужны все колонки сразу.
• Нативная поддержка в Spark из коробки обеспечивает возможность просто взять и сохранить файл в любимое хранилище.
• Эффективное хранение с точки зрения занимаемого места.
• Как показывает практика, именно этот способ обеспечивает самую быструю работу на чтение по сравнению с использованием других файловых форматов.

• Колончатый вид заставляет задумываться о схеме и типах данных.
• Кроме как в Spark, Parquet не всегда обладает нативной поддержкой в других продуктах.
• Не поддерживает изменение данных и эволюцию схемы. Конечно, Spark умеет мерджить схему, если у вас она меняется со временем (для этого надо указать специальную опцию при чтении), но, чтобы что-то изменить в уже существующим файле, нельзя обойтись без перезаписи, разве что можно добавить новую колонку.
• Не поддерживаются транзакции, так как это обычные файлы а не БД.

В Wrike мы уже достаточно давно используем parquet-файлы в качестве хранения обогащённых событийных данных, наши аналитики гоняют довольно много запросов к ним каждый день, у нас выработалась особая методика работы с данной технологией, так что с удовольствием поделимся опытом с теми, кто хочет попробовать parquet в деле, и ответим на все вопросы в комментариях.

P.S. Конечно, в последствии мы не раз пересматривали свои взгляды по поводу формы хранения данных, например, нам советовали более популярный Avro формат, но пока острой необходимости что-то менять у нас нет.

Для тех, кто до сих пор не понял разницу между строково-ориентированными данными и колончато-ориентированными, есть прекрасное видео от Cloudera,
а также довольно занимательная презентация о форматах хранения данных для аналитики.

Что такое паркет файл

Автор Анна Вичугова Категория Kafka, Spark, Статьи

Еще материалы по теме

Горизонтальное масштабирование кластера Apache Kafka: тонкости переназначение разделов

Как сохранить датафрейм вне кучи: секреты Apache Spark для разработчиков

Потоковая аналитика больших данных в Grafana с Apache Kafka, Flink…

АКЦИИ

Новое на сайте

• Горизонтальное масштабирование кластера Apache Kafka: тонкости переназначение разделов
• Как сохранить датафрейм вне кучи: секреты Apache Spark для разработчиков
• Потоковая аналитика больших данных в Grafana с Apache Kafka, Flink и SQL Stream Builder
• Сложная обработка событий от IoT-устройств в Apache Kafka: кейс Tesla
• Строим масштабируемые ETL/ELT-конвейеры обработки данных с Apache Spark и AirFlow: 4 совета дата-инженеру

Отзывы на Google

07:42 27 Apr 21

Курсы от инженеров и для инженеров. Всё чётко, по делу. Тренеры глубоко знают продукты, о которых читают лекции. read more

04:43 12 Mar 21

Принимал участие в обучении по курсу "KAFKA: Администрирование кластера Kafka". В целом понравилось, но хотелось бы более качественной организации работы с лабгайдами. Когда лектор выполняет лабораторную работу, не совсем удобно выполнять её параллельно - где-то отстаешь, где-то убегаешь вперед. Может будет лучше разделить на более мелкие модули. read more

18:31 22 Dec 20

Прошел Курс Администрирование кластера Hadoop. Подача материала хорошая, размеренная. Преподаватель отвечает на все вопросы, и пытается как можно прозрачней приподнести материал. read more

14:47 18 Dec 20

Обучался на программе HADM. Подача материала доступная. Порадовало соотношение теории и практики 50/50. Отзывчивый преподаватель. Однозначно рекомендую. read more

15:07 17 Dec 20

Заканчиваю прохождения курса "ADH: Администрирование кластера Arenadata Hadoop". Хочу сказать, что выстроен грамотный план обучения, где отслеживается отличное соотношение практики и теории. Преподаватель, Комисаренко Николай, обладает отличным чувством юмора, что позволило не скучать на серьезных темах, и обладает отличным навыком объяснять сложные вещи простыми словами. На курс приходил с большим числом вопросов, на все из которых получил грамотные ответы, после чего все разложилось по полочкам. read more

19:17 12 Dec 20

В декабре 2020 прошел курс "Администрирование кластера Kafka". Курс проводился удаленно. В части организации обучения придраться не к чему. Необходимую информацию прислали заранее, лабораторный стенд и портал обучения работали стабильно. Немного разочаровали лабораторные работы. На месте BigDataSchool я бы их переделал. В документах с лабами нужно сделать нормальное форматирование и нумерацию пунктов. Все пункты, необходимые для выполнения, нужно сделать в виде текста. В лабах много работ по созданию «обвязки» kafka (создание самоподписных сертификатов, развертывание MIT и т.п), которые можно сделать заранее. Это позволит студентам уделять больше времени изучению самой kafka. BigDataSchool идет навстречу и позволяет пользоваться лабораторным стендом гораздо дольше установленных часов обучения. Это очень к стати, если в течении дня Вы вынуждены отвлекаться от обучения. В целом, курс дает хорошую базу по kafka. Преподаватель хорошо подает материал, делает акценты в нужных местах, подробно отвечает на вопросы. read more

02:55 10 Dec 20

С 30 ноября по 4 декабря прошел курс "Администрирование кластера Hadoop". Учитывая, что я обладал довольно поверхностной информацией в данной теме (я CIO) - ушел с курсов просветленным. Многое стало понятным, в процессе обучения наложил знания на существующую инфраструктуру компании, в которой работаю. Рекомендую коллегам руководителям в ИТ - прокачаться на данном курсе, вы поймете куда двигаться в ближайшие 2-3 года. Админам, работающим или стремящимся в BigData- обязательно! Рекомендация - настойчиво, для тех кто "думает, что знает": перед курсом уделите время работе с командной строкой Linux! Total recall - обязательное условие. Много практической работы, и если есть затык в Linux - будете безнадежно отставать при выполнении лабораторных работ. read more

13:49 26 Oct 20

В октябре прошел курс Анализ данных с Apache Spark, это был второй раз, когда я обучался в этом месте. В целом, все хорошо, думаю что не последний. Не могу не подчеркнуть профессионализм преподавателя Королева Михаила, отвечал на поставленные вопросы, делился своим опытом. В общем, рекомендую! read more

16:36 25 Sep 20

Прошел тут курс "NIFI: Кластер Apache NiFi", вёл Комисаренко Николай. Живое и понятное обучение. Преподаватель отвечал на все вопросы от самых глупых, до самых умных и это было приятно. Так же порадовало, что преподаватель не идёт по заранее проложенным рельсам, а проходит весь путь вместе с вами, стараясь привнести, что-то новое. read more

14:16 18 Sep 20

Спасибо за обучение!

18:18 24 Jan 20

Очень крутое место, много практики, понятное объяснение заданной темы. Еще вернусь :) read more

14:03 04 Oct 19

Обучался на курсе HADM администрирование кластера Arenadata Hadoop. Интересный курс, хорошая подача. read more

20:16 10 Apr 19

Обучался на курсе по администрированию Apache Kafka. Хорошая подача материала, интересные практические задачи. Возникающие вопросы доходчиво и ясно объясняют. Остался очень доволен. read more

19:20 03 Apr 19

Был на курсе "Администрирование кластера Hadoop". Отличная подача материала. Очень много практики и технических подробностей. Подробный обзор стека технологий, платформы и инструментов. Рекомендую! read more

07:08 01 Apr 19

Учился на курсе Администрирование Hadoop. Курс вёл Николай Комиссаренко. Отлично подготовленная, продуманная, системная программа курса. Практические занятия организованы так, что у студентов есть возможность познакомиться с реальными особенностями изучаемого продукта. Отключил голову и прощёлкал лабы по книжке - здесь не работает. Преподаватель легко и развёрнуто отвечает на возникающие вопросы не только по теме предмета, но и по смежным. read more

03:24 07 Feb 19

Прошёл курс по администрированию Apache Kafka. Очень понравилась как подача материала, так и структура курса. Только вот времени маловато оказалось. не всё успел доделать, но это уже не к курсу претензии :). Практики было довольно много, и это хорошо read more

11:37 22 Dec 18

Прошёл курс "Hadoop для инженеров данных" у Николая Комиссаренко. Информация очень актуальна и полезна, заставляет задуматься о текущих методах работы с большими данными в нашей компании и, возможно, что-то поменять. Занятия с большим количеством практики, поэтому материал хорошо усваивается. Отдельное спасибо Николаю за то, что некоторые вещи объяснял простым языком, понятным даже для "чайников" в области Hadoop. read more

17:23 21 Dec 18

I did not find any disadvantages in the course. Pluses: + A lot of practice (50% of the time). + The teacher can explain difficult topics easy way. + Announced topics were considered. Besides additional materials were studied. read more

08:23 20 Dec 18

Посетил курс администрирование Hadoop. На курсе устанавливали кластер с нуля на виртуалках в облаке Amazon. Настраивали Kerberos, тестировали выполнение задач на кластере, управление ресурсами кластера. Т.к. кластер развернут в облаке, после завершения занятий можно самостоятельно работать с кластером из дома. Лекции вел Николай Комиссаренко, после обучения предоставил все материалы. На занятиях отвечал на дополнительные вопросы, рассмотрели как решить пару живых задач от студентов. Хороший курс для начала изучения BigData. Update Дополнительно прошел обучения по Airflow и NiFi. Курсы двух дневные упор на занятиях делался на использовании продуктов, администрированию уделялось меньше времени. Т.к. курсы короткие, то перед занятиями желательно почитать обзорные статьи по продуктам, чтобы не терять время на базовое погружение и задавать более предметные вопросы. Перед началом занятий желательно связаться с школой и запросить что больше интересуется на обучении. Может быть предложить свои кейсы, чтобы на лабораторных отработать не только общий функционал. read more

05:51 14 Dec 18

Был на основах хадупа, все материалы описаны доступным языком. В частности хочу отметить преподавателя Николая Комисаренко, как очень квалифицированного преподавателя и специалиста. read more

16:40 12 Oct 18

Отличные курсы по "Администрированию Hadoop" и отличная организация проведения занятий, все по делу и понятно. Очень понравилось, знания получены основательные. Материал подаётся основательно. Постараюсь ещё попасть на другие курсы. read more

05:25 11 Oct 18

Курс по Isilon у Николая Комиссаренко мне тоже понравился. Грамотный и отзывчивый. Возникали вопросы по курсу он отвечал на все вопросы. Спасибо. Успехов ему read more

21:32 09 Oct 18

Посетил курс администрирование Hadoop. На курсе устанавливали кластер с нуля на виртуалках в облаке Amazon. Настраивали Kerberos, тестировали выполнение задач на кластере, управление ресурсами кластера. Т.к. кластер развернут в облаке, после завершения занятий можно самостоятельно работать с кластером из дома. Лекции вел Николай Комиссаренко, после обучения предоставил все материалы. На занятиях отвечал на дополнительные вопросы, рассмотрели как решить пару живых задач от студентов. Хороший курс для начала изучения BigData. read more

16:33 09 Oct 18

Эффективный практический курс. Прошел курс Администрирование Hadoop в октябре 2018. Хорошо наполненный материал, оптимальная длительность курса и все делалось своими руками. Местами было непросто, но преодолимо. Оправдал все ожидания, после курса появилось целостное понимание создания и работы кластера. Николай, большое спасибо read more

10:22 05 Oct 18

Прошёл курс по администрированию Hadoop Cloudera. Отличная "живая" подача материала на "простом" языке. Как плюс работа с кластером построена на платформе AWS. На курсах не скучно, рекомендую! read more

04:34 04 Oct 18

Я узнал много нового посетив курс уважаемого Николая Комиссаренко по айзелону. Очень грамотный специалист обучение было очень полезным и грамотным. Спасибо вам большое read more

Русские Блоги

==> Что такое паркет
Parquet - это тип файлов для хранения столбцов.

==> Официальное описание сайта:
Apache Parquet is a columnar storage format available to any project in the Hadoop ecosystem, regardless of the choice of data processing framework, data model or programming language

Независимо от выбора структуры обработки данных, модели данных или языка программирования, Apache Parquet - это столбчатый формат хранения, доступный для любого проекта в экосистеме Hadoop.

==> Происхождение
Parquet вдохновлен статьей Dremel, опубликованной Google в 2010 году. В статье представлен формат хранения, который поддерживает вложенную структуру и использует столбчатое хранилище для повышения производительности запросов. В Dremel В документе также описывается, как Google использует этот формат хранения для реализации параллельных запросов.Если вам это интересно, вы можете обратиться к статье и реализации Apache Drill с открытым исходным кодом.

-> Вы можете пропустить данные, которые не соответствуют условиям, и прочитать только необходимые данные, уменьшив количество данных ввода-вывода

-> Кодирование со сжатием может уменьшить дисковое пространство для хранения (поскольку типы данных одного и того же столбца одинаковы, можно использовать более эффективное кодирование со сжатием (например, кодирование длины цикла t Дельта-кодирование) для дополнительной экономии места для хранения)

-> Чтение только необходимых столбцов, поддержка векторных операций и повышение производительности сканирования

-> Формат Parquet - это источник данных по умолчанию для Spark SQL, который можно настроить с помощью spark.sql.sources.default

==> общие операции с паркетом
-> функции загрузки и сохранения

Паркет - это формат столбцов, который используется в нескольких системах обработки данных.

Spark SQL обеспечивает поддержку чтения и записи файлов Parquet, то есть схемы, которая автоматически сохраняет исходные данные.При записи файлов Parquet все столбцы автоматически преобразуются в допускающие значение NULL из-за совместимости.

---- Прочтите данные в формате Json, преобразуйте их в формат паркета, создайте соответствующую таблицу и используйте оператор SQL для запроса

---- Схематическое объединение: сначала определите простую схему, а затем постепенно увеличивайте описание столбца, пользователь может получить несколько файлов Parquet с разными схемами, но совместимыми друг с другом.

-> Наборы данных Json (два способа записи)

-> JDBC способ чтения данных в реляционной базе данных (необходимо добавить драйвер JDBC)

Русские Блоги

csv, parquet, orc чтение и запись производительность и методы

Недавно я работал над проектом платформы для анализа больших данных. В процессе разработки проекта для расчета каждого шага расчета в проекте рабочего процесса использовалась искра. Многократная отправка вычислений с отправкой в ​​виде искры представляла собой работу. Расчет процесса. Среди них csv используется в качестве промежуточного файла хранения результатов между несколькими этапами вычислений, но csv как метод хранения несжатого текста, очевидно, имеет некоторую производительность, поэтому я хочу найти формат файла, который хранит файлы более эффективно или работает более эффективно. Как альтернатива.

Способ хранения
csv

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

parquet
Apache Parquet - это новый тип столбчатого формата хранения в экосистеме Hadoop. Он совместим с большинством вычислительных сред (Mapreduce, Spark и т. д.) в экосистеме Hadoop и поддерживается несколькими механизмами запросов ( Hive, Impala, Drill и т. Д.), И это не зависит от языка и платформы. Первоначально паркет был разработан Twitter и Cloudera в сотрудничестве и с открытым исходным кодом, а в мае 2015 года он окончил инкубатор Apache и стал главным проектом Apache.

Первоначально паркет был вдохновлен статьей Dremel, опубликованной Google в 2010 году. В статье представлен формат хранения, который поддерживает вложенные структуры и использует столбцовое хранилище для повышения производительности запросов. В статье Dremel также рассказывается, как Google использует это. Один вид формата хранения реализует параллельный запрос, если вы заинтересованы в этом, вы можете обратиться к статье и реализации с открытым исходным кодом Drill.

Файлы паркета хранятся в двоичном формате и не могут быть непосредственно прочитаны и изменены. Файлы паркета разбираются автоматически, а данные и метаданные файла включаются в файл. В файловой системе HDFS и файлах Parquet существуют следующие концепции:

Можно видеть, что информация об индексе метаданных в формате хранения сохраняется в конце, поэтому при чтении строки данных вам нужно найти последнюю информацию об индексе, и, наконец, вы можете прочитать соответствующие данные строки.  

Формат файла ORC - это столбчатый формат хранения в экосистеме Hadoop, созданный в начале 2013 года и изначально созданный из Apache Hive для сокращения пространства хранения данных Hadoop и ускорения Hive. Скорость запроса. Как и в Parquet, это не чисто столбчатый формат хранения, а первый разделитель всей таблицы по группе строк и сохранение ее в столбцах внутри каждой группы строк. Файл ORC имеет самоописание, его метаданные сериализуются с использованием буферов протокола, а данные в файле сжимаются настолько, насколько это возможно, чтобы уменьшить потребление памяти. В настоящее время он также поддерживается механизмами запросов, такими как Spark SQL и Presto. Без поддержки паркет по-прежнему используется в качестве основного столбчатого формата хранения. В 2015 году Apache Project Foundation выдвинул проект ORC на топовый проект Apache.
Как и в Parquet, файл ORC также хранится в двоичном режиме, поэтому его нельзя прочитать напрямую, файл ORC также анализируется самостоятельно, он содержит много метаданных, все эти метаданные Изоморфный ProtoBuffer сериализуется. Файловая структура ORC показана на рисунке 6, которая включает в себя следующие концепции:

Файл ORC: обычный двоичный файл, хранящийся в файловой системе. Файл ORC может содержать несколько полос, и каждая полоса содержит несколько записей. Эти записи хранятся независимо в соответствии со столбцами, что соответствует концепции группы строк в Parquet.
Метаданные на уровне файлов: включая информацию описания файла PostScript, метаинформацию файла (включая статистическую информацию всего файла), всю информацию о полосах и информацию о схеме файлов.
Полоса : группа строк образует полосу. Каждый раз, когда файл читается, блок представляет собой группу строк, которая обычно представляет собой размер блока HDFS, в котором хранятся индекс и данные каждого столбца.
метаданные полосы: сохраните положение полосы, статистику каждого столбца в полосе и все типы и позиции потока.
Группа строк : наименьшая единица индекса, полоса содержит несколько групп строк, значение по умолчанию состоит из 10000 значений.
Поток : поток представляет собой часть допустимых данных в файле, включая индекс и данные. Индексный поток хранит положение и статистическую информацию каждой группы строк. Поток данных включает в себя несколько типов данных, и конкретный тип зависит от типа столбца и метода кодирования.

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

Размер хранилища (эффективность хранения)

Операционная среда кластера:

5 комплектов / память: 24G / ядро: 16 ядер

Данные одинаковы, преобразованы из CSV в следующие различные форматы, эффективность чтения и записи выглядит следующим образом:

формат	размер	Время чтения и записи	отсчет времени работы
csv	36G	3.6min	59s
parquet	6G	1.1min	5s
orc	5.9G	1.2min	5s
avro	13G	1.3min	25s

Размер: видно, что по сравнению с csv, parque и orc напрямую уменьшают размер в 6 раз. Теоретически он может достичь 6-10-кратной эффективности сжатия. В этот раз использовался метод сжатия gzip по умолчанию для паркета.

время: стоит отметить, что для метода работы со столбцами count, parquet, orc и avro достигли довольно хороших результатов. Можно предположить, что этот набор данных не нужен для расчета, а используются только некоторые столбцы. Можно рассчитать, уменьшив масштаб расчета.

Читать и писать код

1. csv слишком распространен и здесь будет опущен

Но, конечно, avro использует блоки данных для чтения, а не забывает добавить зависимость maven для блоков данных.

вывод

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

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

orc также представляет собой список сохраненных двоичных файлов, которые не могут быть непосредственно поняты и поняты при открытии, но потому что в формате файлов каждый блок строк имеет легкий индекс в начале, поэтому по сравнению с паркетом, при поиске строк, orc Скорость относительно быстрее,

Русские Блоги

Давайте поговорим о формате хранения колонок Паркет

Паркет является основным форматом магазина в экологическом круге Hadoop, который был впервые разработан в Twitter и Cloudera и окончил инкубатор Apache от инкубатора Apache из лучших программ Apache от Apache.

Существует такое предложение, чтобы распространиться: если HDFS является фактическим стандартом для файловой системы ERA больших данных, паркет является фактическим стандартом для формата хранения большой эры данных.

01 Общее введение

Паркет - это формат хранения колонок, который поддерживает вложенные структуры.

Идеально подходит для сцен, хранения и сканирования OLAP

Характеристики или преимущества такого хранения, такие как паркет, в основном отражаются в двух аспектах.

1, более высокое соотношение сжатия

Память облегчает использование эффективного сжатия и кодирования для каждого столбца, уменьшая дисковое пространство. (Интернет-случай не сжимается, GZIP, Snappy может достигать отношения сжатия 11/27/19 соответственно)

2, меньшая операция IO

Использование карт и Presticate Push, только необходимые столбцы, пропустить ненужные столбцы, могут уменьшить ненужные сканирования данных, принести улучшение производительности и более очевидно, когда поле таблицы больше

О сопоставлении и предикате:

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

Предварительные предикаты нажимаются, относится к снижению результатов, установленных, выполнив некоторые условия фильтрации для снижения результатов. Предварительным предикатам относятся к этим условиям фильтрации, то есть экспрессия Bool: True и False, таких как SQL, больше, чем меньше или равно, как, является NULL и т. Д.

02 Обзор проекта

Паркет не связан с языком и не связан ни с какими-либо структурами обработки данных. Он адаптирует различные языки и компоненты, а запрос двигатель, адаптирующийся к паркету, включает в себя улей, импалу, свинью, престо, дрель, дрель, TAJO, HAMQ, IBM Big SQL и т. Д., Вычислительные кадры включают в себя Mapreatuce, Spark, Cascading, Crunch, Sparce, Kite и т. Д., Модели данных включают в себя AVRO, Rebift, Protocol Buffer, Pojos и т. Д.

Путь проекта Parquety и способ взаимодействия, как показано на рисунке:

Это можно разделить на три слоя.

Слой хранения данных: определите формат файла паркета, где метаданные определяются в проекте паркетного формата, включая определение в паркете первоначального типа, тип страницы, тип кодирования, тип сжатия и многое другое.

Уровень преобразования объекта: этот слой содержит несколько модулей в Parquet-MR Project, и роль заключается в том, чтобы завершить карту и преобразование других моделей объектов и моделях внутренних данных паркета, и метод кодирования паркета использует полоску и спрашиваемое алгоритм.

Объектный модельный слой: Определите, как прочитать содержимое Паркетного файла, этот слой преобразования включает в себя форматы моделей объектов / сериализации, такие как AVRO, Rebift, протокольный буфер, улей Serde и тому подобное. И для того, чтобы помочь вам понять и использовать, паркет предоставляет пакет org.apache.parquet.example для реализации преобразования объекта Java и паркетный файл.

Среди них модель объекта может просто понять представление данных в памяти, буфере AVRO, Rebift, протокола, POG CUBLE, HIVE SERDE и т. Д. - это модели объектов. Например, проект Паркет-свинью в Parquet-MR Project отвечает за сериализацию свиной кортеж в памяти и хранилище в формате паркета, а также в очередь к кортежу с свинцом.

Здесь вам нужно обратить внимание на буфер AVRO, Rebift, протокола и т. Д. У меня есть собственный формат хранения, но паркет не использует их, но использует себя в формате хранения, который вы определены в проекте паркетного формата. Поэтому, если ваш проект использует объектную модель, такую ​​как AVRO, эти данные сериализуют диск или преобразователь, определенный Parquet-MR, чтобы преобразовать их в собственный формат хранения паркета.

03 Поддержка вложенной модели данных

Паркет поддерживает модели данных вложенных структур, а не плоские модели данных, которые являются основной особенностью или преимуществом паркета относительно другой памяти, такие как ORC. Поддержка вложенных структур означает, что паркет может хранить объектные модели, такие как Protobuf, Rebift, Json.

Модель данных Parquet - также экспрессия схемы, выраженная с помощью ключевого слова. Каждое поле содержит три свойства, требуется / требуется / необязательно, тип данных (примитивный тип базового типа / группы группы) и имя поля.

Каждая запись в этой схеме представляет адресную книгу человека. Существует только один владелец, владелец может иметь 0 или более владельцемPhoneNumbers, владелец может иметь 0 или более контактов. Каждый контакт имеет только одно имя, этот контактный столбец не может иметь нет. Эта схема может быть представлена ​​структурой дерева ниже.

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

04 Модель хранения

Модель хранения здесь можно понимать как формат хранения или формата файла, а модель хранения паркета в основном состоит из группы строки, колонна Chuck, страницы (страницы).

1, Группа строк, Группа строк: Paquence делит данные в линейную группу в горизонтальном направлении, и размер группы строки по умолчанию выровнен с блоком блока HDFS, а паркет гарантирует, что ряд будет обработан Mapper.

2, Block, Column Chun: Сохраните каждый столбец в группе строки в блоке, блок имеет тот же тип данных, а разные блоки могут использовать разное сжатие.

Кроме того, Паркетный файл также содержит информацию заголовка и нижнего колонтитула и хранить код проверки файла и схемы. Изображение официального сайта:

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

05 Parquet vs ORC

В дополнение к паркету, другой общий формат хранения колонна является орк (OptimizeRC файл). Перед орком имеется формат хранения колонн, называемый rcfile (файл RechnactColounarar), и ORC является улучшением формата RCFile, в основном оптимизированным с точки зрения кодирования сжатия и производительности запроса. Следовательно, ORC / RC от улья, в основном используется для улучшения скорости запроса улей и уменьшения пространства хранения данных HADOP.

Паркет и орк суммируют следующее:

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

Обновление и кислотная поддержка: формат орки поддерживает операции обновления и кислоты, а паркет не поддерживает.

Производительность сжатия и запроса: в терминах сжатия и производительности запроса паркет не сильно отличается от ORC. Может быть, орк должен быть немного лучше, чем паркет.

Поддержка двигателя запроса: этот парк является более выгодным, поддерживая различные двигатели запросов, таких как улей, IMPALA, PRESTO и ORC и контакты с улей, и не добрутся адаптироваться к IMPALA. Мы сказали, что IMPALA не поддерживает ORC до тех пор, пока версия CDH 6.1.x не является Impala3.x, чтобы начать поддерживать формат орка в экспериментальной функции.

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

06 Паркетный инструмент

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

Читайте также:

  
• Облегченная стяжка для пола с пенопластом
  
• Лаги на неровный пол
  
• Конструктивные решения паркетных полов
  
• Теплый водяной пол от электрического котла расход электричества
  
• Из чего делают линолеум