Формат Apache Parquet - практическое введение
Apache Parquet - это бинарный формат хранения данных, ориентированный на аналитические сценарии работы с большими объёмами информации. Чаще всего с ним сталкиваются в системах аналитики, хранилищах данных и Data Lake-подходе, где данные хранятся в виде файлов, а не в классических реляционных базах данных.
Цель этой статьи - объяснить, зачем нужен Parquet, в каких задачах он используется, почему он стал стандартом аналитики, и показать практический пример: путь от CSV-файла к аналитическим запросам.
Статья рассчитана на читателя, который впервые знакомится с форматом.
Зачем вообще понадобился Parquet
Исторически данные часто хранили в текстовых форматах: CSV, TSV, JSON. Эти форматы просты, удобны для обмена и легко читаются человеком. Но по мере роста объёмов данных стали проявляться их фундаментальные ограничения:
- данные занимают много места;
- отсутствует строгая схема;
- для выполнения запроса приходится читать файл целиком;
- аналитические операции работают медленно.
Parquet появился как ответ на эти проблемы. Он создавался специально под аналитические нагрузки, где:
- данных много (миллионы и миллиарды строк);
- чаще читают, чем пишут;
- запросы затрагивают не все поля, а только часть колонок;
- важна стоимость хранения и скорость выполнения запросов.
Колоночное хранение как ключевая идея
Главное отличие Parquet от CSV и JSON - колоночная организация данных.
В строко-ориентированных форматах данные хранятся так:
[id, date, user_id, amount]
[id, date, user_id, amount]
В Parquet каждая колонка хранится отдельно:
id: 1, 2, 3, ...
date: 2025-01-01, 2025-01-01, ...
user_id: 42, 17, ...
amount: 100.5, 20.0, ...
Это даёт несколько практических преимуществ:
- можно читать только нужные колонки;
- данные одного типа лучше сжимаются;
- уменьшается объём операций ввода-вывода.
Для аналитических запросов это критично.
Где Parquet используется на практике
Parquet широко применяется в open source-экосистеме аналитики:
- распределённые системы обработки данных (Apache Spark, Apache Flink);
- SQL-движки для аналитики (Apache Hive, Trino, Presto, DuckDB);
- хранилища данных и Data Lake-подходы;
- задачи машинного обучения и Data Science;
- экспорт и импорт данных в аналитических СУБД, например использование Parquet как обменного формата при работе с ClickHouse.
Типичные примеры данных:
- логи и события приложений;
- транзакции и финансовые операции;
- телеметрия и метрики;
- агрегированные бизнес-показатели.
Общий паттерн выглядит так:
данные собираются в простом формате → обрабатываются → сохраняются в Parquet → анализируются SQL-запросами
Почему Parquet лучше CSV и JSON для аналитики
Parquet и CSV
CSV не хранит информацию о типах данных и не оптимизирован для выборочного чтения. Даже если запросу нужна одна колонка, файл приходится читать полностью.
Parquet, напротив:
- хранит строгую схему;
- позволяет читать только нужные поля;
- обычно занимает в несколько раз меньше места.
На практике CSV-файл размером 100 ГБ легко превращается в 10-20 Гб Parquet.
Parquet и JSON
JSON удобен для API и обмена данными между сервисами, но крайне неэффективен как формат хранения:
- высокая избыточность;
- сложный парсинг;
- отсутствие оптимизаций для аналитики.
JSON - транспортный формат. Parquet - формат хранения.
Как Parquet ускоряет запросы
Parquet хранит метаданные и статистики по данным:
- минимальные и максимальные значения;
- количество NULL;
- типы данных.
Благодаря этому аналитические движки могут:
- не читать блоки данных, которые точно не подходят под фильтр;
- выполнять predicate pushdown;
- значительно сокращать объём обрабатываемых данных.
Просмотр Parquet и аналитические запросы
Важно разделять два разных сценария работы с Parquet:
- Просмотр и инспекция данных
- Выполнение аналитических запросов
Просмотр Parquet-файлов
Для быстрого знакомства с содержимым Parquet-файла (схема, первые строки, типы данных) используются Parquet Viewer и подобные инструменты.
Они подходят для:
- проверки, что файл корректно сформирован;
- просмотра структуры данных;
- ручной инспекции небольших выборок.
При этом такие инструменты не предназначены для аналитики и, как правило, не поддерживают GROUP BY, агрегации и сложные SQL-запросы.
Аналитические запросы
Для выполнения запросов вида SELECT ... GROUP BY ... необходим аналитический SQL-движок, который умеет читать Parquet. Типичный пример - DuckDB.
DuckDB выполняет SQL-запросы поверх Parquet-файлов напрямую, без предварительной загрузки данных в базу.
Практический пример: CSV → Parquet → запросы
Шаг 1. Исходные данные в CSV
order_id,order_date,user_id,amount
1,2025-01-01,42,100.5
2,2025-01-01,17,20.0
3,2025-01-02,42,15.0
Шаг 2. Преобразование в Parquet
import pandas as pd
df = pd.read_csv("sales.csv")
df.to_parquet("sales.parquet", engine="pyarrow")
Шаг 3. Аналитический запрос
SELECT
order_date,
SUM(amount) AS total_amount
FROM 'sales.parquet'
GROUP BY order_date
ORDER BY order_date;
Ограничения формата
Parquet не предназначен для:
- частых обновлений и удалений строк;
- транзакционных (OLTP) нагрузок;
- построчного доступа к отдельным записям.
Это формат для сценариев «записали → много читаем».
Заключение
Parquet стал стандартом аналитического хранения данных не случайно. Он решает практические проблемы:
- уменьшает размер данных;
- ускоряет аналитические запросы;
- хорошо интегрируется с open source-инструментами аналитики.
Важно помнить:
- Parquet - это формат хранения, а не язык запросов;
- для просмотра подходят Parquet Viewer;
- для аналитических SQL-запросов используются движки вроде DuckDB.