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

Обновлено: 04.05.2024

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

Формат Parquet поддерживается для следующих соединителей:

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

Использование локальной среды выполнения интеграции

Для копирования посредством локальной среды выполнения интеграции (IR), то есть между локальным и облачным хранилищами данных, если вы не копируете файлы Parquet как есть, на компьютере среды выполнения интеграции необходимо установить 64-разрядную JRE 8 (среду выполнения Java) или OpenJDK и Распространяемый пакет Microsoft Visual C++ 2010. Подробные сведения приведены в следующем абзаце.

Для копирования, запущенного в локальной среде IR с сериализацией/десериализацией файлов Parquet, служба определяет местонахождение среды выполнения Java, сначала проверяя реестр (SOFTWARE\JavaSoft\Java Runtime Environment\\JavaHome) на наличие JRE, если он не найден, после чего проверяя системную переменную JAVA_HOME для OpenJDK.

Пример: установите переменную _JAVA_OPTIONS со значением -Xms256m -Xmx16g . Флаг Xms указывает начальный пул выделения памяти для виртуальной машины Java (JVM), а Xmx указывает максимальный пул выделения памяти. Это означает, что JVM будет запущена с объемом памяти Xms и сможет использовать не более Xmx объема памяти. По умолчанию служба использует минимум 64 МБ и максимум 1 ГБ.

Свойства набора данных

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

Свойство	Описание	Обязательно
type	Для свойства type набора данных необходимо задать значение Parquet.	Да
location	Параметры расположения файлов. Каждый файловый соединитель имеет собственный тип расположения и поддерживает собственный набор свойств в разделе location . Подробные сведения см. в статье о соединителях —> раздел "Свойства набора данных".	Да
compressionCodec	Кодек сжатия, используемый при записи в файлы Parquet. При чтении из файлов Parquet Фабрика данных автоматически определяет кодек сжатия по метаданным файла. Поддерживаются следующие типы: "нет", "gzip", "закрепление" (по умолчанию) и "lzo". Примечание. В настоящее время действие копирования не поддерживает кодек LZO при чтении и записи файлов Parquet.	Нет

Пробелы в именах столбцов файлов Parquet не допустимы.

Свойства действия копирования

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

Parquet в качестве источника

В разделе источника *source* действия Copy поддерживаются указанные ниже свойства.

Свойство	Описание	Обязательно
type	Свойство type источника действия копирования должно иметь значение ParquetSource.	Да
storeSettings	Группа свойств, определяющих способ чтения данных из хранилища данных. Каждый файловый соединитель поддерживает собственный набор параметров чтения в разделе storeSettings . Подробные сведения см. в статье о соединителях —> раздел "Свойства действия Copy".	Нет

Parquet в качестве приемника

В разделе *sink* действия Copy поддерживаются следующие свойства.

Свойство	Описание	Обязательно
type	Свойство type для приемника действия копирования должно иметь значение ParquetSink.	Да
formatSettings	Группа свойств. См. таблицу Параметры записи Parquet ниже.	Нет
storeSettings	Группа свойств, определяющих способы записи данных в хранилище данных. Каждый файловый соединитель поддерживает собственный набор параметров записи в разделе storeSettings . Подробные сведения см. в статье о соединителях —> раздел "Свойства действия Copy".	Нет

Поддерживаемые Параметры записи Parquet в formatSettings

Свойство	Описание	Обязательно
type	Для параметра type свойства formatSettings необходимо задать значение ParquetWriteSettings.	Да
maxRowsPerFile	Можно выбрать режим записи данных в папку с разбиением на несколько файлов и указать максимальное число строк в одном таком файле.	Нет
fileNamePrefix	Это свойство применимо, если задано свойство maxRowsPerFile . Оно задает префикс, добавляемый к имени файла при записи данных с разбиением на несколько файлов. Имя присваивается по следующему шаблону: _00000. . Если это свойство не задано, то префикс имени файла будет создан автоматически. Это свойство не применяется, если источником является файловое хранилище или хранилище данных с поддержкой разделов.	Нет

Свойства потока данных для сопоставления

В потоках данных для сопоставления можно читать и записывать данные в формате parquet в следующих хранилищах данных: Хранилище BLOB-объектов Azure, Azure Data Lake Storage 1-го поколения, Azure Data Lake Storage 2-го поколения и SFTP, кроме того, чтение данных в формате parquet поддерживается в Amazon S3.

Свойства источника

В таблице, приведенной ниже, указаны свойства, поддерживаемые источником данных parquet. Эти свойства можно изменить на вкладке Параметры источника.

Имя	Описание	Обязательно	Допустимые значения	Свойство скрипта для потока данных
Формат	Формат должен быть parquet	Да	parquet	format
Пути с подстановочными знаками	Будут обработаны все файлы, соответствующие пути с подстановочными знаками. Переопределяет папку и путь к файлу, заданные в наборе данных.	Нет	String[]	wildcardPaths
Корневой путь раздела	Для секционированных файловых данных можно ввести корневой путь к секции, чтобы считывать секционированные папки как столбцы	Нет	Строка	partitionRootPath
List of files (Список файлов)	Сообщает о том, указывает ли источник на текстовый файл, в котором перечислены файлы для обработки.	Нет	true или false	fileList
Столбец для хранения имени файла	Предписывает создать столбец с именем и путем исходного файла.	Нет	Строка	rowUrlColumn
After completion (После завершения)	Инструкции в отношении удаления или перемещения файлов после обработки. Путь к файлу начинается с корня контейнера.	Нет	Удаление: true или false Перемещение: [, ]	purgeFiles moveFiles
Filter by last modified (Фильтр по последнему изменению)	Задает фильтр для файлов по времени последнего изменения	Нет	Отметка времени	modifiedAfter modifiedBefore
Allow no files found (Разрешить ненайденные файлы)	Когда задано значение true, ошибка не возникает, если файлы не найдены	Нет	true или false	ignoreNoFilesFound

Пример источника данных

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

Соответствующий сценарий потока данных:

Свойства приемника

В таблице, приведенной ниже, указаны свойства, поддерживаемые приемником данных parquet. Изменить эти свойства можно на вкладке Параметры.

Пример приемника

На приведенном ниже рисунке показан пример конфигурации приемника parquet в потоках данных для сопоставления.

Соответствующий сценарий потока данных:

Поддержка типов данных

Сложные типы данных Parquet (например, MAP, LIST и STRUCT) в настоящее время поддерживаются только в потоках данных, а не в действии копирования. Чтобы использовать сложные типы в потоках данных, не импортируйте схему файла в набор данных, в результате чего в наборе данных остается пустая схема. Затем в преобразовании "источник" импортируйте проекцию.

Зачем нужны разные форматы файлов

Серьезное узкое место в производительности приложений с поддержкой HDFS, таких как MapReduce и Spark — время поиска, чтения, а также записи данных. Эти проблемы усугубляются трудностями в управлении большими наборами данных, если у нас не фиксированная, а эволюционирующая схема, или присутствуют некие ограничения на хранение.

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

Различные форматы файлов в Hadoop придуманы для решения именно этих проблем. Выбор подходящего формата файла может дать некоторые существенные преимущества:

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

Формат файлов Avro

Для сериализации данных широко используют Avro — это основанный на строках, то есть строковый, формат хранения данных в Hadoop. Он хранит схему в формате JSON, облегчая ее чтение и интерпретацию любой программой. Сами данные лежат в двоичном формате, компактно и эффективно.

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

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

Этот формат идеально подходит для записи в посадочную (переходную) зону озера данных (озеро данных, или data lake — коллекция инстансов для хранения различных типов данных в дополнение непосредственно к источникам данных).

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

Данные из этой зоны обычно считываются целиком для дальнейшей обработки нижестоящими системами — и формат на основе строк в этом случае более эффективен.
Нижестоящие системы могут легко извлекать таблицы схем из файлов — не нужно хранить схемы отдельно во внешнем мета-хранилище.
Любое изменение исходной схемы легко обрабатывается (эволюция схемы).

Формат файлов Parquet

Parquet — опенсорсный формат файлов для Hadoop, который хранит вложенные структуры данных в плоском столбчатом формате.

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

Это особенно полезно для запросов, которые считывают определенные столбцы из широкой (со многими столбцами) таблицы. Благодаря формату файлов читаются только необходимые столбцы, так что ввод-вывод сводится к минимуму.

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

Например, запись включает поля ID, Name и Department. В этом случае все значения столбца ID будут храниться вместе, как и значения столбца Name и так далее. Таблица получит примерно такой вид:

ID	Name	Department
1	emp1	d1
2	emp2	d2
3	emp3	d3

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

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

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

Одна из уникальных особенностей Parquet заключается в том, что в таком формате он может хранить данные с вложенными структурами. Это означает, что в файле Parquet даже вложенные поля можно читать по отдельности без необходимости читать все поля во вложенной структуре. Для хранения вложенных структур Parquet использует алгоритм измельчения и сборки (shredding and assembly).

Чтобы понять формат файла Parquet в Hadoop, необходимо знать следующие термины:

Здесь заголовок просто содержит волшебное число PAR1 (4 байта), которое идентифицирует файл как файл формата Parquet.

В футере записано следующее:

Метаданные файла, которые содержат стартовые координаты метаданных каждого столбца. При чтении нужно сначала прочитать метаданные файла, чтобы найти все интересующие фрагменты столбцов. Затем фрагменты столбцов следует читать последовательно. Еще метаданные включают версию формата, схему и любые дополнительные пары ключ-значение.
Длина метаданных (4 байта).
Волшебное число PAR1 (4 байта).

Формат файлов ORC

Оптимизированный строково-столбчатый формат файлов (Optimized Row Columnar, ORC) предлагает очень эффективный способ хранения данных и был разработан, чтобы преодолеть ограничения других форматов. Хранит данные в идеально компактном виде, позволяя пропускать ненужные детали — при этом не требует построения больших, сложных или обслуживаемых вручную индексов.

Преимущества формата ORC:

Один файл на выходе каждой задачи, что уменьшает нагрузку на NameNode (узел имен).
Поддержка типов данных Hive, включая DateTime, десятичные и сложные типы данных (struct, list, map и union).
Одновременное считывание одного и того же файла разными процессами RecordReader.
Возможность разделения файлов без сканирования на наличие маркеров.
Оценка максимально возможного выделения памяти кучи на процессы чтения/записи по информации в футере файла.
Метаданные сохраняются в бинарном формате сериализации Protocol Buffers, который позволяет добавлять и удалять поля.

ORC хранит коллекции строк в одном файле, а внутри коллекции строчные данные хранятся в столбчатом формате.

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

По умолчанию размер полосы составляет 250 МБ. За счет полос такого большого размера чтение из HDFS выполняется более эффективно: большими непрерывными блоками.

В футере файла записан список полос в файле, количество строк на полосу и тип данных каждого столбца. Там же записано результирующее значение count, min, max и sum по каждому столбцу.

Футер полосы содержит каталог местоположений потока.

Строчные данные используются при сканировании таблиц.

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

О хранении данных в 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,
а также довольно занимательная презентация о форматах хранения данных для аналитики.

Автор Анна Вичугова

Apache Parquet – это бинарный, колоночно-ориентированный формат хранения больших данных, изначально созданный для экосистемы Hadoop, позволяющий использовать преимущества сжатого и эффективного колоночно-ориентированного представления информации. Паркет позволяет задавать схемы сжатия на уровне столбцов и добавлять новые кодировки по мере их появления [1]. Вместе с Apache Avro, Parquet является очень популярным форматом хранения файлов Big Data и часто используется в Kafka, Spark и Hadoop.

Структура файла Apache Parquet

Из-за архитектурных особенностей структура представления информации в Parquet сложнее, чем, например, в JSON, который также часто используется для Big Data. В частности, уровни определения (definition levels) и уровни повторения (repetition levels) позволяют оптимально хранить пустые значения и эффективно кодировать данные, информацию о схеме в метаданные [2].

Уровни определения определяют количество необязательных полей в пути для столбца. Уровни повторения указывают, для какого повторяемого поля в пути, значение имеет повторение. Максимальные уровни определения и повторения могут быть вычислены из схемы. Эта степень вложенности определяет максимальное количество битов, необходимых для хранения уровней. В свою очередь, уровни определены для всех значений в столбце [1].

Благодаря многоуровневой системе разбиения файлов на части реализуется параллельное исполнение важных Big Data операций (MapReduce, ввод-вывод, кодирование и сжатие) [2]:

Типы и представления данных в формате Паркет

Иерархически файл Parquet состоит из одной или нескольких групп строк. Группа строк содержит ровно один фрагмент столбца на столбец. Фрагменты столбцов содержат одну или несколько страниц.

Группы строк используются HDFS (распределенной файловой системой Apache Hadoop) для реализации концепции локальности данных, когда каждый узел кластера считывает лишь ту информацию, которая хранится непосредственно на его жестком диске.

В Apache Spark группа строк является единицей работы для каждой задачи MapReduce. При этом группа строк помещается в память, что следует учитывать при настройке размера группы – каков минимальный объём памяти, выделяемый на задачу на самом слабом узле кластера. Чтобы разбить входные данные на несколько row groups и эффективно распределить MapReduce-задачи по ресурсам кластера, можно использовать операцию разделения RDD-таблиц (Resilient Distributed Datasets) [2], которые являются объектами всех манипуляций с данными в Apache Spark – об этом мы рассказывали здесь.

Поскольку типы данных влияют на объем занимаемого пространства, их стремятся минимизировать при проектировании форматов файла. Например, 16-разрядные числа явно не поддерживаются в формате хранения, поскольку они покрыты 32-разрядными числами с эффективным кодированием. Благодаря такой стратегии снижается сложность реализации чтения и записи формата. Parquet поддерживает следующие типы данных [1]:

Метаданные файла Apache Parquet

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

При повреждении метаданных сам файл теряется – данное правило актуально также в случае столбцов и страниц [2]:

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

Сжатие, кодирование и отображение файлов Big Data в формате Parquet

В формате Parquet сжатие больших данных выполняется столбец за столбцом, что позволяет использовать разные схемы кодирования для текстовых и целочисленных данных, в т.ч. вновь изобретенные. Также, благодаря колоночной структуре, формат Parquet существенно ускоряет процесс работы с данными, поскольку можно считывать не весь файл, а лишь необходимые столбцы, т.к. на практике для аналитических задач в конкретный момент нужны лишь несколько колонок. Кроме того, такое структурирование информации упрощает сжатие и кодирование данных за счёт их однородности и похожести [2]. В связи с этим, по сравнению с Avro и JSON, другими популярными форматами Big Data, Паркет быстрее сохраняет и сжимает данные, а также занимает меньше дискового пространства [3].

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

Мы уже упоминали формат Parquet в статье про Apache Avro, одну из наиболее распространенных схем данных Big Data, часто используемую в Kafka, Spark и Hadoop. Сегодня рассмотрим более подробно, чем именно хорошо Apache Parquet и как он отличается от других форматов Big Data.

Что такое Apache Parquet и как он работает: краткий ликбез

Напомним, что Apache Parquet — это бинарный, колоночно-ориентированный (столбцовый) формат хранения больших данных. Созданный специально для экосистемы Hadoop, он позволяет эффективно сжимать информацию и считывать файлы частично, по мере необходимых столбцов. Паркет предоставляет возможность задавать схемы сжатия на уровне столбцов и добавлять новые кодировки по мере их изобретения и реализации [1]. Наряду с Apache Avro, Parquet – это весьма популярный формат хранения файлов Big Data, который на практике очень часто используется в Kafka, Spark и Hadoop.

Паркет поддерживает наиболее распространенные типы данных (boolean, int32, int64, int96, float, double, byte_array) и реализует многоуровневую систему разбиения файлов на части (группы строк, блок данных столбца и разбиение столбцов по страницам), благодаря чему обеспечивается высокая скорость работы с данными [2].

Достоинства и недостатки Паркет

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

экономия места для хранения данных за счет эффективного сжатия информации по столбцам – в частности, по сравнению с Apache Avro, другим популярным форматом Big Data, Паркет сжимает данные примерно в 3,5 раза лучше [3];
высокая скорость чтения данных и отработки запросов, извлекающих определенные значения столбцов вместо считывания всего большого файла, что значительно ускоряет работу аналитика Big Data [1];
возможность реализации собственных схем данных и применения различных методов кодирования к различным столбцам [1];
поддержка нескольких языков программирования (C++, Java, Python, PHP и т.д.), а также популярных фреймворков, например, Apache Thrift, что повышает гибкость формата [1];
возможность хранения данных не только вHDFS, для которой Parquet и был создан изначально, но и в других файловых системах (GlusterFs, NFS и пр.) [1];
простота и удобство работы с файлами с помощью операций перемещения, резервного копирования и реплицирования [1];
поддержкаApacheSpark«по умолчанию» (из коробки) обеспечивает возможность сохранить файл Big Data в другое облачное или локальное хранилище данных [1].

Поскольку недостатки являются продолжением достоинств, отметим следующие минусы формата Apache Parquet [2]:

строгая типизация данных – в связи с колоночной ориентацией файл формата Паркет ведёт себя как неизменяемая таблица или база данных, когда для столбца четко определён тип данных, при этом невозможно его изменить или скомбинировать, например, объединив вложенный json с простым строковым значением.
отсутствие встроенной (нативной) поддержки в других фреймворках Big Data, кроме Apache Spark;
отсутствие возможности отслеживать изменение данных и эволюцию схемы, в отличие от, например, Avro, другого популярного форматом Big Data, изменение схемы данных которого легко прослеживается через графический интерфейс Sсhema Registry в Apache Kafka Confluent (об этом мы писали здесь). Отметим, что Apache Spark позволяет объединять схемы данных при изменении их со временем, но для этого требуется указать специальную опцию при чтении. А, чтобы что-то изменить в уже существующим файле, его придется перезаписать или добавить новую колонку.
не поддерживаются транзакции, поскольку, несмотря на некоторую схожесть с базой данных (в части строгой типизации), файлы формата Паркет – это частично размеченная информация.
сложность частичной потоковой передачи данных – необходимо передавать всю «группу строк»;
сильная привязка к метаданным – при повреждении, потере метаданных или изменении контрольной суммы группы строк, блока данных столбца или страницы данных, вся смысловая информация будет утеряна. Отметим, что, отключив в файловой системе вычисления контрольных сумм на каждом из уровней разбиения, можно значительно повысить производительность;
Паркет не является человекочитаемым форматом, в отличие, например, от JSON или CSV.

Сравнение Parquet с другими форматами хранения больших данных

Проанализировав результаты сравнения формата Паркет с Авро, детально представленные в [3], можно сделать выводы, что Apache Parquet значительно быстрее Avro. Было проведено тестирование со следующими наборами данных:

широкий датасет в виде CSV-файла размером 194 ГБ, содержащего 103 столбца и 694 миллиона строк;
узкий датасет в виде CSV-файла размером 3,9 ГБ (3 столбца и 82,8 миллиона строк).

Сравнение выполнялось в рамках Apache Spark 1.6, который в своей базовой поставке поддерживает Parquet, а для Avro и CSV были установлены соответствующие плагины. Для тестирования использовался кластер на основе Cloudera Distribution Hadoop (CDH) 5.5.x, состоящий из более чем 100 узлов. Производительность каждого формата оценивалась путем выполнения операций записи набора данных в файл, обработок простых и сложных SQL-подобных запросов, подсчета количества строк, обработки полного набора данных и расхода дискового пространства [3].

В рамках этого тестирования были получены следующие результаты [3]:

запись данных в файл и подсчет количества строк в узком датасете занимают примерно одинаковое время в форматах Паркет и Авро, а в широком наборе данных Parquet работает значительно быстрее;
в случае сложных запросов к подмножеству столбцов, в частности, GROUP BY, а также при обработке полного набора данных с помощью функции MAP() информация в формате Паркет обрабатывается за гораздо меньшее время по сравнению с Apache Avro и CSV – это характерно как для узкого, так и для широкого датасета;
особенно впечатляют итоги тест на сжатие данных, когда Parquet сжал CSV-файл размером 194 ГБ до 4,7 ГБ, а Avro – до 16,9 ГБ, что соответствует высокой степени сжатия: 97,56% и 91,24% соответственно.

Таким образом, Apache Parquet в очередной раз подтвердил звание наиболее производительного формата хранения файлов Big Data и удобство работы с такими файлами с помощью фреймворка Apache Spark. О других популярных форматов больших данных, Apache AVRO, ORC, Sequence и RCFile читайте в нашей следующей статье.

Как работать с Apache Parquet и другими форматами больших данных, вы узнаете на наших практических курсах для руководителей, архитекторов, инженеров, администраторов, аналитиков Big Data и Data Scientist’ов в лицензированном учебном центре обучения и повышения квалификации ИТ-специалистов в Москве.

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