Формат данных Parquet: что это такое, структура, Row Group, Column Chunk, Page и использование в Apache Spark

Parquet — один из ключевых форматов хранения данных в современной инфраструктуре Big Data. Он применяется в Data Lake, аналитических платформах, ETL/ELT-конвейерах и системах машинного обучения, где необходимо эффективно хранить и обрабатывать большие объёмы структурированной и полуструктурированной информации.

Главное отличие Parquet от привычных CSV или Excel заключается в том, что это колоночный бинарный формат для структурированной и полуструктурированной информации

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

Для CIO и ИТ-руководителя Parquet важен не столько как ещё одно расширение файла, сколько как элемент архитектуры Data Lake и аналитического контура. Выбор формата влияет на объём хранения, сетевой трафик, время выполнения запросов, стоимость инфраструктуры и возможности масштабирования вычислений.

Что такое и как выглядит

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

Главное преимущество Parquet — читать только то, что действительно нужно запросу, а не последовательно разбирать весь файл целиком.

Если CSV условно хранит таблицу как последовательность строк, то Parquet организует информацию по столбцам. Для запроса, которому необходимы только customer_id, date и revenue из таблицы со 100 столбцами, движок может не читать остальные 97 столбцов.

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

Предыстория: как появился

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

В 2013 году Twitter и Cloudera представили Parquet как open-source формат колонночного хранения для Hadoop. При проектировании использовались идеи из работы Google Dremel, посвящённой интерактивному анализу данных веб-масштаба и эффективной работе с вложенными структурами.

Изначально задача была связана прежде всего с Hadoop-экосистемой, однако архитектура оказалась значительно шире конкретного вычислительного движка. Со временем Parquet стал использоваться различными аналитическими системами, языками программирования и инструментами обработки данных. Сам проект сегодня развивается как отдельная спецификация формата, а экосистема включает реализации для Java, C++, Python, Rust и других платформ.

Название

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

В техническом смысле название не является аббревиатурой. Это именно имя формата, который сегодня развивается в рамках Apache Software Foundation.

Что значит бинарный

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

Например, в CSV число 1250000 хранится как последовательность символов 1, 2, 5 и так далее. В Parquet числовое значение хранится в бинарном представлении, подходящем для дальнейшего декодирования вычислительным движком.

Это не означает, что Parquet «нечитаем» или является закрытым форматом. Напротив, спецификация открыта, а многочисленные библиотеки умеют читать и записывать такие файлы. Просто для человека это не текстовый документ, а структурированный машинный формат хранения.

Как выглядит

Parquet-файл имеет характерную структуру. В упрощённом виде его можно представить следующим образом:

+----------------------------------+
| Magic number: PAR1               |
+----------------------------------+
| Row Group 1                      |
|   Column Chunk: id               |
|   Column Chunk: customer         |
|   Column Chunk: revenue          |
|   Column Chunk: date             |
+----------------------------------+
| Row Group 2                      |
|   Column Chunk: id               |
|   Column Chunk: customer         |
|   Column Chunk: revenue          |
|   Column Chunk: date             |
+----------------------------------+
| ...                              |
+----------------------------------+
| File Metadata / Footer           |
+----------------------------------+
| Metadata length                  |
+----------------------------------+
| Magic number: PAR1               |
+----------------------------------+

Это не означает, что все реализации будут физически организовывать данные абсолютно одинаково на уровне всех внутренних деталей, но базовая модель именно такая: row groups → column chunks → pages. Официальная спецификация описывает расположение column chunks, метаданных и footer.

Структура

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

Такое устройство позволяет разделить задачу хранения на несколько уровней. Row Group является крупной единицей горизонтального разбиения, Column Chunk — единицей хранения конкретного столбца внутри Row Group, а Page — более мелкой единицей кодирования и сжатия.

Архитектура Parquet позволяет оптимизировать сразу три уровня: объём данных, чтение столбцов и пропуск ненужных страниц.

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

Row Group

Row Group — логическая горизонтальная группа строк. Если представить исходную таблицу как миллиарды строк, то Parquet разбивает их на крупные логические блоки. Каждая Row Group содержит данные всех столбцов для соответствующего набора строк.

Например, таблица из 500 млн строк может быть записана не одним монолитным блоком, а множеством Row Group. При этом каждая группа будет содержать Column Chunk для каждого столбца.

Размер Row Group влияет на баланс между последовательным чтением, параллелизмом и требованиями к памяти при записи. В документации Parquet в качестве ориентиров для некоторых Hadoop-сценариев приводятся крупные Row Group порядка 512 МБ–1 ГБ, но оптимальное значение зависит от движка, инфраструктуры и конкретной нагрузки.

Слишком маленькие Row Group увеличивают накладные расходы и могут ухудшить последовательное чтение. Слишком крупные усложняют работу с отдельными фрагментами данных и могут снижать эффективность выборочного доступа.

Column Chunk

Column Chunk — часть данных конкретного столбца внутри определённой Row Group. Если Row Group содержит 20 столбцов, то в ней будет соответствующий Column Chunk для каждого из этих столбцов.

Именно на этом уровне особенно хорошо проявляется преимущество колоночного хранения. Значения одного столбца находятся рядом, поэтому их можно эффективно кодировать и сжимать. Например, столбец country с миллионами повторяющихся значений хорошо подходит для словарного кодирования.

Column Chunk состоит из страниц, записанных последовательно. Внутри него может использоваться dictionary encoding, а данные могут дополнительно сжиматься. Спецификация также допускает структуры, позволяющие читателю эффективнее пропускать ненужные страницы.

Page

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

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

В современных реализациях также могут использоваться Page Index и статистика страниц. Например, если запрос ищет записи по диапазону значений, движок может определить, что конкретная страница не содержит подходящих данных, и не читать её.

Операции

С точки зрения пользователя Parquet выглядит просто: файл можно читать, фильтровать, преобразовывать и записывать с помощью Spark, Python, SQL-движков и других инструментов. Но внутри эти операции опираются на архитектуру Row Group, Column Chunk и Page.

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

Уровень	Что хранится	Зачем нужен
File	Row Groups и метаданные	Физический файл Parquet
Row Group	Набор строк	Крупное горизонтальное разбиение
Column Chunk	Данные одного столбца в Row Group	Колоночное чтение и сжатие
Page	Закодированный фрагмент Column Chunk	Сжатие, кодирование и выборочное чтение
Footer	Метаданные файла	Навигация по данным

В результате аналитический движок может сначала прочитать метаданные, определить необходимые Column Chunk, затем использовать статистику и индексы для дополнительного сокращения объёма чтения. Официальная спецификация прямо описывает такую модель доступа: сначала читаются метаданные файла, после чего reader определяет интересующие его Column Chunk.

Особенности

Parquet оптимизирован прежде всего под аналитическое хранение и массовое чтение. Это определяет как его сильные стороны, так и ограничения. Формат прекрасно подходит для Data Lake, ETL/ELT и аналитических запросов, но не должен автоматически рассматриваться как универсальная замена базе данных или журналу событий.

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

Поэтому при выборе Parquet необходимо разделять три уровня архитектуры: сам формат файлов, систему хранения и механизм управления таблицами. Например, Parquet может лежать в объектном хранилище, а транзакционность и управление версиями поверх него может обеспечиваться Delta Lake, Apache Iceberg или Apache Hudi.

Сложно настроить стриминг

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

При этом утверждение, что «Parquet вообще не поддерживает streaming», было бы слишком категоричным. Например, Apache Spark Structured Streaming умеет работать с Parquet как с файловым источником или приёмником. Однако такая схема принципиально отличается от работы специализированного event streaming-брокера: события материализуются в файлы, а управление обновлениями, согласованностью и жизненным циклом данных требует дополнительной архитектуры.

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

Не поддерживаются транзакции

Сам формат Parquet не предоставляет полноценной транзакционной модели таблицы: в нём нет механизма ACID-транзакций уровня базы данных, который позволял бы атомарно управлять изменениями набора файлов, откатами и конкурентными операциями над таблицей.

Это важное ограничение для архитекторов. Если поверх Data Lake требуется UPDATE, DELETE, MERGE, time travel, schema evolution и атомарные изменения таблицы, обычно применяют табличный формат или table layer поверх файлов. В такой архитектуре Parquet остаётся физическим форматом хранения данных, а транзакционная семантика обеспечивается другим уровнем.

Колоночное хранение

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

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

Эффективное сжатие

Значения одного столбца обычно обладают большей однородностью, чем значения нескольких разных столбцов, записанных вперемешку. Это создаёт хорошие условия для компрессии и encoding.

Parquet позволяет использовать разные схемы кодирования и компрессии, причём архитектура предусматривает применение механизмов на уровне отдельных колонок. Для повторяющихся значений может использоваться dictionary encoding, а для других типов данных — специализированные методы кодирования.

Поддержка вложенных данных

Parquet изначально проектировался не только для плоских таблиц. Формат способен эффективно представлять вложенные и повторяющиеся структуры, используя идеи Dremel и repetition/definition levels.

Это особенно важно для событийных данных, JSON-подобных структур и сложных объектов, где простое предварительное «распрямление» структуры привело бы к большому объёму избыточных данных.

Независимость от вычислительного движка

Parquet не привязан к Apache Spark. Его могут читать и записывать различные аналитические движки и библиотеки. В официальной документации перечисляются реализации и инструменты для Java, C++, Go, Rust, Python и других экосистем.

Для CIO это означает снижение зависимости от конкретного вычислительного движка. Данные могут оставаться в одном формате, даже если организация со временем меняет Spark на другой аналитический инструмент.

Не является базой данных

Parquet не следует воспринимать как замену PostgreSQL, Oracle, ClickHouse или другой СУБД во всех сценариях. Это формат хранения файлов, а не самостоятельная система управления данными.

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

Как использовать

На практике Parquet чаще всего становится физическим форматом хранения внутри Data Lake, Lakehouse или аналитического конвейера. Исходные CSV, JSON, Excel и события поступают в систему, после чего вычислительный движок преобразует их в Parquet для дальнейшего использования.

Пример простого конвейера выглядит так:

Excel / CSV / JSON / API
          |
          v
   Spark / ETL / ELT
          |
          v
       Parquet
          |
    +-----+-----+
    |           |
    v           v
   BI         ML / AI

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

Apache Spark

Apache Spark — один из наиболее естественных вариантов использования Parquet. Spark умеет читать и записывать Parquet непосредственно через DataFrame API и Spark SQL.

from pyspark.sql import SparkSession

spark = SparkSession.builder \
    .appName("ParquetExample") \
    .getOrCreate()

df = spark.read.parquet("/data/sales")

result = df \
    .filter("revenue > 1000000") \
    .select("customer_id", "region", "revenue")

result.write \
    .mode("overwrite") \
    .parquet("/data/mart/high_value_sales")

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

Это особенно удобно для Data Lake, где вычислительные кластеры могут создаваться и масштабироваться независимо от слоя хранения.

Хранение обогащённых событийных данных

Для событийной архитектуры Parquet полезен как конечный или промежуточный формат после обогащения событий. Например, Kafka может принимать поток событий приложений, Spark Structured Streaming — читать его, присоединять справочники, нормализовать структуру и записывать результат в Parquet.

Получается двухуровневая архитектура: event streaming отвечает за доставку событий, а Parquet — за долговременное аналитическое хранение.

Например:

Приложения
    |
    v
  Kafka
    |
    v
Spark Structured Streaming
    |
    +-- обогащение
    +-- нормализация
    +-- фильтрация
    |
    v
Parquet / Data Lake
    |
    +-- BI
    +-- аналитика
    +-- ML

Такой подход позволяет не пытаться использовать Parquet в качестве замены брокеру сообщений. Формат становится аналитическим слоем после потоковой обработки.

Parquet или Avro

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

Критерий	Parquet	Avro
Основная модель	Колоночная	Записевая
Аналитические запросы	Очень хорошо подходит	Менее оптимален
Чтение отдельных столбцов	Да	Не основная цель
Потоковый обмен	Возможен, но не основная задача	Хорошо подходит
Data Lake	Типичный выбор	Тоже используется
Сериализация сообщений	Не основная задача	Типичный сценарий

Поэтому вопрос обычно не стоит как «выбрать Parquet или Avro для всей платформы». В зрелой архитектуре они могут использоваться одновременно: Avro — для передачи и сериализации событий, Parquet — для аналитического хранения.

Хранение данных

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

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

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

GlusterFS в режиме Distributed

GlusterFS может использоваться как распределённая файловая система, поверх которой хранятся Parquet-файлы. В режиме Distributed пространство хранения распределяется между узлами, позволяя объединить дисковые ресурсы нескольких серверов.

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

Для Data Lake на GlusterFS важно также учитывать характеристики конкретных рабочих нагрузок Spark: количество файлов, параллелизм чтения, сетевой трафик и поведение файловой системы под высокой конкурентной нагрузкой.

SSD по NFS

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

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

Поэтому перед промышленным внедрением необходимо измерять не только производительность SSD, но и реальную пропускную способность всей цепочки: Spark executor → сеть → NFS → контроллеры → SSD.

Hadoop с помощью YARN

Классический вариант для Big Data — связка HDFS + YARN + Spark. В такой архитектуре HDFS отвечает за распределённое хранение, YARN — за управление ресурсами и запуск вычислительных задач, а Spark — за обработку данных.

Parquet хорошо соответствует этой модели, поскольку формат изначально проектировался с учётом Hadoop-экосистемы. В частности, официальная документация Parquet описывает Row Group и настройки, связанные с HDFS-блоками.

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

Если есть GPU-вычисления

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

Например, экосистема RAPIDS/cuDF и GPU-ориентированные компоненты может использовать Parquet как источник данных для последующей обработки на GPU. В этом случае архитектура выглядит как Parquet → GPU DataFrame → ML/аналитика.

При проектировании такой системы важно учитывать баланс между дисковой подсистемой, CPU, сетью и GPU. Быстрый GPU не даст ожидаемого эффекта, если данные поступают из медленного сетевого хранилища и вычислительный ускоритель большую часть времени простаивает в ожидании I/O.

Объектное S3-хранилище

Для современных Data Lake одним из наиболее распространённых вариантов является размещение Parquet в S3-совместимом объектном хранилище. Такой подход позволяет отделить хранение от вычислительных кластеров: Spark-кластер можно запускать по требованию, тогда как данные продолжают находиться в объектном хранилище.

Это особенно удобно для облачных и гибридных архитектур. При этом необходимо учитывать особенности работы конкретного S3-совместимого хранилища, сетевую пропускную способность, стоимость операций, политику жизненного цикла и структуру каталогов Data Lake.

Какой вариант хранения выбрать

Универсального ответа нет: выбор зависит от масштаба данных, требований к производительности, существующей инфраструктуры и модели эксплуатации.

• HDFS + YARN — классический вариант для Hadoop-ориентированной платформы.
• S3-совместимое объектное хранилище — удобный вариант для современного Data Lake и разделения storage/compute.
• GlusterFS — вариант распределённой файловой инфраструктуры при соответствующей экспертизе.
• SSD/NFS — может подходить для локальных или средних инсталляций, если сеть и NAS выдерживают нагрузку.
• GPU-инфраструктура — используется как вычислительный слой поверх данных, а не как альтернатива Parquet.

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