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

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

We created Parquet to make the advantages of compressed, efficient columnar data representation available to any project in the Hadoop ecosystem.

Parquet is built from the ground up with complex nested data structures in mind, and uses the record shredding and assembly algorithm described in the Dremel paper. We believe this approach is superior to simple flattening of nested name spaces.

Parquet is built to support very efficient compression and encoding schemes. Multiple projects have demonstrated the performance impact of applying the right compression and encoding scheme to the data. Parquet allows compression schemes to be specified on a per-column level, and is future-proofed to allow adding more encodings as they are invented and implemented.

Parquet is built to be used by anyone. The Hadoop ecosystem is rich with data processing frameworks, and we are not interested in playing favorites. We believe that an efficient, well-implemented columnar storage substrate should be useful to all frameworks without the cost of extensive and difficult to set up dependencies.

Modules

The parquet-format project contains format specifications and Thrift definitions of metadata required to properly read Parquet files.

The parquet-mr project contains multiple sub-modules, which implement the core components of reading and writing a nested, column-oriented data stream, map this core onto the parquet format, and provide Hadoop Input/Output Formats, Pig loaders, and other Java-based utilities for interacting with Parquet.

The parquet-cpp project is a C++ library to read-write Parquet files.

The parquet-rs project is a Rust library to read-write Parquet files.

The parquet-compatibility project contains compatibility tests that can be used to verify that implementations in different languages can read and write each other’s files.

Building

Java resources can be build using mvn package. The current stable version should always be available from Maven Central.

C++ thrift resources can be generated via make.

Thrift can be also code-genned into any other thrift-supported language.

Releasing

Glossary

Block (hdfs block): This means a block in hdfs and the meaning is unchanged for describing this file format. The file format is designed to work well on top of hdfs.

File: A hdfs file that must include the metadata for the file. It does not need to actually contain the data.

Row group: A logical horizontal partitioning of the data into rows. There is no physical structure that is guaranteed for a row group. A row group consists of a column chunk for each column in the dataset.

Column chunk: A chunk of the data for a particular column. These live in a particular row group and is guaranteed to be contiguous in the file.

Page: Column chunks are divided up into pages. A page is conceptually an indivisible unit (in terms of compression and encoding). There can be multiple page types which is interleaved in a column chunk.

Hierarchically, a file consists of one or more row groups. A row group contains exactly one column chunk per column. Column chunks contain one or more pages.

Unit of parallelization

File format

This file and the thrift definition should be read together to understand the format.

In the above example, there are N columns in this table, split into M row groups. The file metadata contains the locations of all the column metadata start locations. More details on what is contained in the metadata can be found in the thrift files.

Metadata is written after the data to allow for single pass writing.

Readers are expected to first read the file metadata to find all the column chunks they are interested in. The columns chunks should then be read sequentially.

Metadata

There are three types of metadata: file metadata, column (chunk) metadata and page header metadata. All thrift structures are serialized using the TCompactProtocol.

Types

The types supported by the file format are intended to be as minimal as possible, with a focus on how the types effect on disk storage. For example, 16-bit ints are not explicitly supported in the storage format since they are covered by 32-bit ints with an efficient encoding. This reduces the complexity of implementing readers and writers for the format. The types are:

Logical Types

Logical types are used to extend the types that parquet can be used to store, by specifying how the primitive types should be interpreted. This keeps the set of primitive types to a minimum and reuses parquet’s efficient encodings. For example, strings are stored as byte arrays (binary) with a UTF8 annotation. These annotations define how to further decode and interpret the data. Annotations are stored as a ConvertedType in the file metadata and are documented in LogicalTypes.md.

Nested Encoding

To encode nested columns, Parquet uses the Dremel encoding with definition and repetition levels. Definition levels specify how many optional fields in the path for the column are defined. Repetition levels specify at what repeated field in the path has the value repeated. The max definition and repetition levels can be computed from the schema (i.e. how much nesting there is). This defines the maximum number of bits required to store the levels (levels are defined for all values in the column).

Two encodings for the levels are supported BITPACKED and RLE. Only RLE is now used as it supersedes BITPACKED.

Nulls

Nullity is encoded in the definition levels (which is run-length encoded). NULL values are not encoded in the data. For example, in a non-nested schema, a column with 1000 NULLs would be encoded with run-length encoding (0, 1000 times) for the definition levels and nothing else.

Data Pages

For data pages, the 3 pieces of information are encoded back to back, after the page header. We have the

The data for the data page is always required. The definition and repetition levels are optional, based on the schema definition. If the column is not nested (i.e. the path to the column has length 1), we do not encode the repetition levels (it would always have the value 1). For data that is required, the definition levels are skipped (if encoded, it will always have the value of the max definition level).

For example, in the case where the column is non-nested and required, the data in the page is only the encoded values.

The supported encodings are described in Encodings.md

Column chunks

Column chunks are composed of pages written back to back. The pages share a common header and readers can skip over page they are not interested in. The data for the page follows the header and can be compressed and/or encoded. The compression and encoding is specified in the page metadata.

Checksumming

Data pages can be individually checksummed. This allows disabling of checksums at the HDFS file level, to better support single row lookups.

Error recovery

If the file metadata is corrupt, the file is lost. If the column metdata is corrupt, that column chunk is lost (but column chunks for this column in other row groups are okay). If a page header is corrupt, the remaining pages in that chunk are lost. If the data within a page is corrupt, that page is lost. The file will be more resilient to corruption with smaller row groups.

Potential extension: With smaller row groups, the biggest issue is placing the file metadata at the end. If an error happens while writing the file metadata, all the data written will be unreadable. This can be fixed by writing the file metadata every Nth row group.
Each file metadata would be cumulative and include all the row groups written so far. Combining this with the strategy used for rc or avro files using sync markers, a reader could recover partially written files.

Separating metadata and column data.

The format is explicitly designed to separate the metadata from the data. This allows splitting columns into multiple files, as well as having a single metadata file reference multiple parquet files.

Configurations

Extensibility

There are many places in the format for compatible extensions:

Источник

Как просмотреть файл Apache Parquet в Windows?

Apache Parquet: внутреннее устройство файла Parquet и проверка файловой структуры Parquet

Я не смог найти простых объяснений на английском языке относительно файлов Apache Parquet. Такие как:

Любая помощь по этим вопросам приветствуется.

Что такое паркет Apache?

Мне нужен Hadoop или HDFS?

Нет. Файлы Parquet могут храниться в любой файловой системе, а не только в HDFS. Как упоминалось выше, это формат файла. Так что это как любой другой файл, у которого есть имя и .паркет расширение. Однако в средах больших данных обычно происходит то, что один набор данных будет разделен (или разделен) на несколько файлов паркета для еще большей эффективности.

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

Как я могу создавать / читать паркетные файлы?

Как уже упоминалось, все текущие продукты Apache для работы с большими данными, такие как Hadoop, Hive, Spark и т. Д., По умолчанию поддерживают файлы Parquet.

Таким образом, эти системы можно использовать для создания или чтения данных Parquet. Но это далеко не практично. Представьте, что для чтения или создания файла CSV вам нужно установить Hadoop / HDFS + Hive и настроить их. К счастью, есть и другие решения.

Чтобы создать свои собственные пилки паркета:

Чтобы просмотреть содержимое файла паркета:

Есть другие способы?

Теперь это возможно с помощью Apache Arrow, который помогает упростить связь / передачу между различными форматами данных, см. Мой ответ здесь или официальную документацию в случае Python.

В основном это позволяет вам быстро читать / писать файлы паркета в пандах. DataFrame как мода дает вам преимущества использования notebooks просматривать и обрабатывать такие файлы, как если бы это был обычный csv файл.

Затем вы можете просто использовать панды для управления паркетными файлами:

В дополнение к обширному ответу @ sal есть еще один вопрос, с которым я столкнулся в этом контексте:

Как я могу получить доступ к данным в файле паркета с помощью SQL?

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

Майкл Гарланик написал очень хорошее руководство по установке комбинации Spark / Python.

После настройки я могу взаимодействовать с паркетом через:

После загрузки паркетов таким образом вы можете взаимодействовать с Pyspark API, например. через:

Возможно, уже слишком поздно для этой темы, просто сделайте какое-нибудь дополнение для тех, кто хочет просмотреть файл Parquet с помощью настольного приложения, работающего на MAC или Linux.
Существует настольное приложение для просмотра Parquet, а также других данных в двоичном формате, таких как ORC и AVRO. Это чистое приложение Java, поэтому его можно запускать в Linux, Mac, а также в Windows. Пожалуйста, проверьте Bigdata File Viewer для подробностей.

Он поддерживает сложные типы данных, такие как массив, карта и т. Д.

На Mac, если мы хотим просматривать контент, мы можем установить ‘parquet-tools’

Мы всегда можем прочитать паркетный файл в фрейм данных в Spark и увидеть его содержимое.

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

Источник

Как просмотреть файл Apache Parquet в Windows?

Я не смог найти никаких простых объяснений на английском языке относительно файлов Apache Parquet. Такие как:

Любая помощь по этим вопросам приветствуется.

Что такое Apache Parquet?

Нужен ли мне Hadoop или HDFS?

Нет. Файлы паркета могут храниться в любой файловой системе, а не только в HDFS. Как уже упоминалось выше, это формат файла. Таким образом, он, как и любой другой файл, имеет имя и расширение .parquet. Что обычно происходит в средах больших данных, так это то, что один набор данных будет разбит (или разделен) на несколько файлов паркета для еще большей эффективности.

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

Как я могу создавать/читать файлы паркета?

Как уже упоминалось, все современные продукты Apache для больших данных, такие как Hadoop, Hive, Spark и т.д., Поддерживают файлы Parquet по умолчанию.

Таким образом, можно использовать эти системы для генерации или чтения данных Parquet. Но это далеко не практично. Представьте, что для чтения или создания файла CSV вам нужно было установить Hadoop/HDFS + Hive и настроить их. К счастью, есть и другие решения.

Чтобы создать свои собственные файлы паркета:

Для просмотра содержимого файла паркета:

Есть ли другие методы?

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

Источник

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

Чтение и запись файла Parquet и объединение небольших файлов Parquet

содержание

1. Введение

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

Конструкция паркета позволяет ему иметь лучшую степень сжатия и более высокую скорость фильтрации.

Один файл имеет несколько групп строк
Группа строк состоит из нескольких столбцов
В одном столбце несколько страниц

FileMetaData\Row Group metadata\column metadata

Два, схема (MessageType)

Каждая схема имеет корень с именем message, который содержит несколько полей.

Каждое поле содержит три атрибута:
repetition, type, name

Повторение бывает трех видов:

Тип может быть: int32, int64, int96, float, double, boolean, binary, group.

Остальные, кроме группы, называются примитивными типами.Группа объединяет примитивные типы.

Три, получение MessageType

3.1 Построить из строки

3.2 Создание из кода

3.3 Получить через Parquet-файл

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

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

3.4 Полный пример

Четыре, паркет читать и писать

4.1 Чтение и запись локальных файлов

4.2 Чтение и запись файлов HDFS

Второй параметр 0 в group.getString («bookName», 0) подготовлен для повторяемого поля (повторяется), чтобы получить количество значений, начиная с 0, поэтому, соответствующие требуемому типу, все равны 0.

Пять, объедините небольшие файлы Parquet

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

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

Вышеупомянутое сначала проверит, согласована ли схема паркета в каталоге, а затем объединится.

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

Источник

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

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

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

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

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

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

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

Блок HDFS (Блок): это самая маленькая единица копирования в HDFS. HDFS будет хранить блок в локальном файле и поддерживать несколько копий, разбросанных по разным машинам. Обычно размер блока составляет 256 МБ. 512M и т. Д.
Файл HDFS (Файл). Файл HDFS, включая данные и метаданные, данные распределяются и хранятся в нескольких блоках.
Группа строк: данные физически разделены на несколько блоков в соответствии со строками. Каждая группа строк содержит определенное количество строк. По крайней мере одна группа строк хранится в файле HDFS, Parquet При чтении и записи вся группа строк кэшируется в памяти, поэтому, если размер каждой группы строк определяется размером памяти.
Блок столбцов: каждый столбец в группе строк хранится в блоке столбцов, а все столбцы в группе строк постоянно хранятся в этом файле группы строк. Различные блоки столбцов могут использовать разные алгоритмы сжатия.
Страница (Страница): каждый блок столбца разделен на несколько страниц, одна страница является наименьшей единицей кодирования, и разные методы кодирования могут использоваться на разных страницах одного и того же блока столбца.
При нормальных обстоятельствах при хранении данных Parquet размер группы строк будет установлен в соответствии с размером блока HDFS, поскольку в общем случае наименьшая единица данных, обрабатываемая каждой задачей Mapper, представляет собой блок, поэтому Каждая группа строк может быть обработана задачей Mapper для увеличения параллелизма выполнения задачи. Формат файла Parquet показан на рисунке ниже.

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

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

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

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

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

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

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

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

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

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

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

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

вывод

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

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

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

Другие форматы
Существуют и другие форматы: indexR / ya100

Цитируемая статья выглядит следующим образом:

Источник