parquet формат

Parquet формат — это колоночный формат хранения данных с открытым исходным кодом, разработанный Twitter и Cloudera для экосистемы Hadoop и ставший стандартом для хранения аналитических данных в data lake и data warehouse. Parquet оптимизирован для эффективного сжатия и быстрого чтения подмножества колонок, что критично для аналитических запросов над большими датасетами.

Строковые vs колоночные форматы

CSV и JSON хранят данные построчно: все поля одной записи расположены рядом. При аналитическом запросе «вычисли среднюю цену продаж» СУБД вынуждена прочитать все поля каждой строки, хотя нужна только колонка price. Это расточительно при широких таблицах с сотнями колонок.

Parquet хранит данные поколоночно: все значения колонки price расположены рядом. Для расчёта среднего читается только эта колонка — экономия IO в десятки раз для широких таблиц. Это ключевое преимущество для OLAP-запросов.

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

Parquet-файл состоит из Row Groups — горизонтальных разделов данных (обычно 128 МБ). Каждый Row Group содержит Column Chunks — данные одной колонки. Column Chunk делится на Pages — минимальные единицы сжатия и кодирования.

Footer файла хранит метаданные: схему, статистику (min/max значения) для каждого Column Chunk. Это позволяет query engine пропускать целые Row Groups без чтения данных — предикатный pushdown.

Кодирование и сжатие

Parquet применяет несколько уровней оптимизации хранения. Кодирование: Dictionary Encoding (заменяет повторяющиеся значения индексом в словаре), Run-Length Encoding (RLE, для монотонных или повторяющихся значений), Delta Encoding (для числовых последовательностей). Сжатие: Snappy (быстрое, умеренное сжатие), ZSTD (лучшее сжатие, умеренная скорость), LZ4, Gzip.

На реальных датасетах Parquet с ZSTD-сжатием занимает в 5–20 раз меньше места, чем CSV с теми же данными.

Предикатный pushdown и column pruning

Query engine (Spark, DuckDB, Presto, BigQuery) использует статистику в footer для оптимизации: Column Pruning — читает только запрошенные колонки. Predicate Pushdown — пропускает Row Groups, где min/max не попадает в условие фильтра. Partition Pruning — при хранении данных по партициям (hive-style partitioning) пропускает нерелевантные директории.

Вложенные структуры

Parquet поддерживает сложные вложенные схемы: массивы, словари, вложенные структуры. Это реализовано через алгоритм Dremel (используется в Google BigQuery): поля разбиваются на листовые колонки с метаданными об уровнях определения и повторения.

Экосистема и совместимость

Parquet нативно поддерживается: Apache Spark, Flink, Hive, Presto, Trino, DuckDB, Pandas (через pyarrow), Polars, BigQuery, Redshift Spectrum, Athena, Azure Synapse. Это делает его lingua franca для обмена данными в big data экосистеме.

Apache Arrow — in-memory колоночный формат, идеально дополняющий Parquet: Arrow для вычислений в памяти, Parquet для долгосрочного хранения на диске. Конвертация между ними эффективна и быстра.

Parquet vs альтернативы

ORC (Optimized Row Columnar) — конкурент от Hive-экосистемы, чуть лучше сжимается, но менее распространён вне Hive. Avro — строковый бинарный формат с эволюцией схемы, лучше для streaming и Kafka. Delta Lake и Apache Iceberg — форматы таблиц поверх Parquet, добавляющие ACID-транзакции и time travel. CSV — только для совместимости и небольших объёмов данных.

Apache Arrow и Parquet в памяти

Apache Arrow — in-memory колоночный формат, созданный как дополнение к Parquet для вычислений. Arrow использует то же колоночное представление, что и Parquet, но оптимизирован для работы в оперативной памяти: выровненные блоки памяти, SIMD-совместимое расположение данных. Конвертация между Parquet и Arrow минимальна — данные десериализуются почти напрямую. Arrow Flight — gRPC-протокол для высокоскоростной передачи Arrow-данных по сети, позволяющий перемещать ГБ данных в секунды. Pandas 2.0 использует Arrow в качестве optional backend, что даёт значительный прирост производительности и снижение потребления памяти для типичных ETL-задач.

Частые вопросы

  • Можно ли редактировать Parquet-файлы на месте?

    Нет. Parquet — иммутабельный формат, данные нельзя обновлять на месте. Для поддержки UPDATE/DELETE поверх Parquet используют форматы таблиц Delta Lake, Apache Iceberg или Apache Hudi, которые реализуют ACID-транзакции через файловые операции.

  • Какой инструмент использовать для чтения Parquet в Python?

    PyArrow — основная библиотека. Pandas читает Parquet через pyarrow или fastparquet. DuckDB отлично работает с Parquet напрямую: SELECT * FROM 'data.parquet'. Polars — современная альтернатива pandas с нативной поддержкой Parquet.

  • Какой размер Row Group оптимален для Parquet?

    По умолчанию 128 МБ — хороший баланс. Более крупные Row Groups дают лучшее сжатие и эффективнее используют предикатный pushdown, но требуют больше памяти при чтении. Для streaming-генерации файлов уменьшите до 16–64 МБ.

Не хватает деталей?

Напишите, что уточнить по теме «parquet формат» — это помогает улучшать материал и подсказывает, какие термины добавить дальше. Email необязателен: укажите, если хотите ответ только для вас (мы не шлём рассылки).

Поделиться