Форматы колоночного хранения: Apache Parquet и Apache Arrow

В темах 1 и 2 мы убедились, что текстовые табличные форматы (CSV, TSV) и классические реляционные СУБД со строковым хранением (Row-Oriented DBMS) быстро достигают предела производительности при аналитической обработке сотен тысяч и миллионов записей. Для расчёта среднего расхода воды или поиска пикового давления в городской сети за полгода аналитический запрос обращается лишь к двум-трём числовым столбцам из десятка атрибутов, содержащихся в записи. Однако построчное хранилище вынуждено поднимать с диска каждую строку целиком, забивая шину памяти бесполезным вводом-выводом ¹.

Решением этой проблемы стал переход к колоночному представлению данных (Columnar Storage). В этой теме мы детально разберём два взаимодополняющих открытых стандарта индустрии:

1. Apache Parquet — бинарный колоночный формат хранения данных на диске и в объектных хранилищах;
2. Apache Arrow — стандарт непрерывного колоночного представления данных в оперативной памяти для высокоскоростной аналитики без сериализации.

Строковое против колоночного хранения

В строковом формате (Row-Oriented, традиционные СУБД вроде OLTP PostgreSQL или SQLite) байты кортежей следуют друг за другом:

\text{Строка 1: } [id_1, time_1, sensor_1, val_1, status_1], \quad \text{Строка 2: } [id_2, time_2, sensor_2, val_2, status_2] \dots

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

В колоночном формате (Column-Oriented) массив группируется по столбцам:

\text{Столбец } val: [val_1, val_2, val_3, val_4, \dots], \quad \text{Столбец } time: [time_1, time_2, time_3, time_4, \dots]

Ключевые преимущества колоночного подхода

1. Проекция без накладных расходов (Column Pruning): Если аналитический запрос агрегирует только столбец val (SELECT avg(val) FROM telemetry), с диска читаются страницы только этого столбца. Все остальные данные (текстовые комментарии, идентификаторы датчиков, координаты) физически не считываются с накопителя.
2. Экстремальное сжатие данных: Значения одного столбца имеют одинаковый тип данных и схожее распределение. Последовательные временные метки идут с шагом в одну секунду, а показания температуры колеблются около одного значения. Это позволяет применять специализированные алгоритмы кодирования (RLE, Delta-encoding, Dictionary), сжимая данные в 5–10 раз лучше универсальных архиваторов ².
3. Векторизованные вычисления (SIMD): Однородный массив чисел в памяти идеально ложится в векторные регистры процессора, позволяя выполнять инструкции AVX-512 над десятками значений за один такт процессора.

Внутреннее устройство формата Apache Parquet

Apache Parquet — открытый формат колоночного хранения, созданный совместными усилиями инженеров Twitter и Cloudera на основе идей исследовательской статьи Google Dremel ³.

Файл Parquet имеет иерархическую структуру:

Основные компоненты файла

1. Группа строк (Row Group): Логическое разбиение набора данных по горизонтали. Каждая группа строк содержит данные для фиксированного числа строк (обычно от 100 000 до 1 000 000 строк или 128–512 МБ несжатых данных). Наличие нескольких групп строк позволяет обрабатывать файл параллельно несколькими потоками.
2. Фрагмент столбца (Column Chunk): Данные одного конкретного столбца в рамках одной группы строк. Фрагмент сохраняется на диске непрерывным блоком.
3. Страницы (Pages): Минимальная единица сжатия и чтения внутри фрагмента столбца (обычно около 1 МБ). Бывают страницами данных (Data Page) и страницами словарей (Dictionary Page).
4. Подвал файла (File Footer / File MetaData): Ключевая особенность Parquet — метаданные хранятся в конце файла. Движок чтения сначала обращается к последним байтам файла, считывает длину метаданных, читает подвал через Apache Thrift, узнаёт точную схему таблицы, типы данных, смещения всех колонок и их статистику, и лишь затем точечно запрашивает нужные диапазоны байт.

Алгоритмы кодирования и сжатия

Перед тем как сжать страницу универсальным алгоритмом (Snappy, ZSTD, Gzip), Parquet применяет предварительное кодирование значений:

• Словарное кодирование (Dictionary Encoding): Строковые значения заменяются компактными целочисленными индексами. Например, названия районов города заменяются байтами 0, 1, 2, а словарь уникальных строк сохраняется отдельно в Dictionary Page.
• Кодирование длин серий (Run-Length Encoding, RLE) и упаковка бит (Bit-Packing): Последовательность повторяющихся значений [5, 5, 5, 5, 5] сохраняется как пара (5 раз, значение 5).
• Дельта-кодирование (Delta Encoding): Для монотонно возрастающих значений (например, временных меток с шагом в 1 секунду) сохраняется только базовое значение и разности между соседними элементами.

После кодирования блок сжимается:

• Snappy: промышленный стандарт по умолчанию — умеренное сжатие при колоссальной скорости распаковки (до 1 ГБ/с на ядро CPU).
• Zstandard (ZSTD): современный алгоритм от Meta, обеспечивающий превосходный баланс между высоким коэффициентом сжатия и высокой скоростью декомпрессии.

Статистика и предикатный пушдаун (Predicate Pushdown)

В подвале Parquet-файла для каждого фрагмента столбца в каждой группе строк сохраняются так называемые зонные карты (Zone Maps / Column Statistics):

• минимальное значение (min_value);
• максимальное значение (max_value);
• число значений NULL (null_count).

Рассмотрим аналитический запрос к телеметрии:

SELECT avg(temperature)
FROM telemetry
WHERE timestamp >= '2024-06-01' AND timestamp < '2024-07-01';

Движок выполнения запросов (например, DuckDB) читает метаданные подвала файла Parquet. Если для группы строк 1 зонная карта показывает min_value = '2024-01-01' и max_value = '2024-03-31', движок полностью пропускает чтение этой группы строк (Row Group Skipping). Ни один байт данных этой группы строк не считывается с диска.

Этот механизм называется предикатным пушдауном (Predicate Pushdown): фильтрация переносится с уровня вычислительного ядра на уровень подсистемы чтения формата данных ⁴.

Apache Arrow: колоночный стандарт в оперативной памяти

Если Apache Parquet оптимизирован для долгосрочного хранения на диске и эффективного сжатия, то Apache Arrow — это стандарт представления колоночных данных в оперативной памяти (In-Memory Columnar Format) ⁵.

До появления Arrow каждый фреймворк (Pandas, DuckDB, Spark, ClickHouse) использовал собственный внутренний формат памяти. При передаче данных между ними до 80 % времени уходило на сериализацию и десериализацию объектов.

Apache Arrow определяет стандартизированную структуру непрерывных буферов памяти:

• Bitmap валидности (Validity Bitmap): один бит на значение, где 1 означает присутствие данных, а 0 — NULL.
• Массив смещений (Offsets Buffer): для строк переменной длины.
• Буфер данных (Data Buffer): непрерывный массив байт.

Благодаря Arrow различные аналитические библиотеки могут обращаться к одной и той же области памяти с нулевым копированием (Zero-Copy Sharing): например, DuckDB может напрямую выполнять SQL-запрос по DataFrame библиотеки Polars или Pandas без копирования байт данных.

Итоги темы

Колоночные форматы произвели революцию в аналитике больших данных. Разделение данных по колонкам позволяет читать только запрошенные поля (Column Pruning), а зонные карты метаданных отсекают чтение ненужных диапазонов строк (Row Group Skipping). Формат Parquet гарантирует компактное и безопасное хранение на диске с алгоритмами кодирования RLE и словарями, а стандарт Apache Arrow обеспечивает молниеносный анализ в памяти без накладных расходов на сериализацию.

Литература

1. Kleppmann M. Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. — O'Reilly Media, 2017. — Chapter 3: Storage and Retrieval ¹.
2. Abadi D., Boncz P., Harizopoulos S. The Design and Implementation of Modern Column-Oriented Database Systems. — Foundations and Trends in Databases, 2013, Vol. 5, No. 3, С. 197–280 ².
3. Melnik S., Gubarev A., Long J. J., Romer G., Shivakumar S., Tolton M., Vassilakis T. Dremel: Interactive Analysis of Web-Scale Datasets. — Proceedings of the VLDB Endowment, 2010, Vol. 3, No. 1–2, С. 330–339 ³.
4. Apache Parquet Documentation. Parquet Format Specification. — The Apache Software Foundation, 2024. https://parquet.apache.org/docs/file-format/ ⁴.
5. Apache Arrow Documentation. Arrow Columnar Format. — The Apache Software Foundation, 2024. https://arrow.apache.org/docs/format/Columnar.html ⁵.

Дополнительные материалы

Вопросы для самопроверки

1. Почему строковый формат хранения данных эффективен для OLTP-транзакций, но критически замедляет аналитические OLAP-запросы?
2. В чём заключается эффект отсечения столбцов (Column Pruning) при выполнении аналитической проекции?
3. Какова внутренняя иерархия файла Apache Parquet? Опишите назначение групп строк (Row Groups), фрагментов столбцов (Column Chunks) и страниц (Pages).
4. Почему метаданные файла Parquet (File MetaData) располагаются в самом конце файла, а не в начале?
5. Как работает словарное кодирование (Dictionary Encoding) и в каких случаях оно не даёт выигрыша в размере?
6. Как кодирование длин серий (RLE) и дельта-кодирование (Delta Encoding) уменьшают энтропию числовых последовательностей перед сжатием?
7. Что такое зонные карты (Zone Maps / Column Statistics) в Parquet и как они обеспечивают пропуск групп строк (Row Group Skipping)?
8. В чём различие между назначением форматов Apache Parquet и Apache Arrow?
9. Что такое разделение данных с нулевым копированием (Zero-Copy Data Sharing) в Apache Arrow?
10. Почему сжатие Snappy часто предпочитают алгоритму Gzip в аналитических хранилищах данных, несмотря на меньшую степень сжатия?

Глоссарий темы

Шпаргалка по работе с Parquet и DuckDB

-- Экспорт таблицы или запроса в файл Parquet со сжатием ZSTD:
COPY (
    SELECT * FROM readings
) TO 'readings.parquet' (FORMAT PARQUET, COMPRESSION ZSTD);

-- Чтение и фильтрация Parquet файла напрямую без загрузки в БД:
SELECT device_id, avg(consumption) AS avg_val
FROM read_parquet('readings.parquet')
WHERE timestamp >= '2024-01-01'
GROUP BY device_id;

-- Анализ метаданных файла Parquet через системную функцию DuckDB:
SELECT file_name, row_group_id, num_rows, total_byte_size
FROM parquet_metadata('readings.parquet');

-- Анализ зонных карт и статистики фрагментов столбцов:
SELECT column_id, path_in_schema, num_values, min_value, max_value, null_count
FROM parquet_schema('readings.parquet');

Типичные ошибки и подводные камни

1. Создание тысяч крошечных файлов Parquet («Small Files Problem»): Формат Parquet оптимизирован для файлов размером от 128 МБ до 1 ГБ. Создание миллионов файлов по 50 КБ приводит к катастрофическому росту накладных расходов на чтение метаданных подвала файлов и парализует работу планировщика запросов.
2. Слишком маленький или слишком большой размер Row Group: При размере группы строк в 1 000 строк предикатный пушдаун даёт мало выгоды из-за раздувания метаданных. При размере в 10 000 000 строк пропуск групп становится редким, а для декомпрессии требуется гигантский объём RAM. Оптимальный размер: от 100 000 до 1 000 000 строк.
3. Использование неэффективных типов данных: Сохранение дат в виде строк ('2024-03-01 12:00:00') вместо компактных бинарных типов TIMESTAMP или DATE в разы увеличивает размер Parquet-файла и замедляет фильтрацию.

Литература

1. Kleppmann M. Designing Data-Intensive Applications. — O'Reilly Media, 2017 ¹.
2. Abadi D. et al. The Design and Implementation of Modern Column-Oriented Database Systems. — Foundations and Trends in Databases, 2013 ².
3. Apache Parquet Project. Parquet Format Specification. — Apache Software Foundation, 2024 ³.

Лабораторная работа 3. Форматы колоночного хранения: Apache Parquet и предикатный пушдаун

• Раздел курса: тема 3 «Форматы колоночного хранения: Apache Parquet и Apache Arrow»

Введение

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

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

Цель работы

Исследовать архитектуру и преимущества колоночного формата Apache Parquet в сравнении с CSV по объёму хранения на диске, скорости декомпрессии и эффективности предикатного пушдауна при выполнении аналитических выборок в СУБД DuckDB.

После выполнения работы вы сможете:

• преобразовывать наборы данных между форматами CSV и Parquet с контролем алгоритмов сжатия и размера групп строк;
• извлекать и анализировать метаданные Parquet: схему, число групп строк, зонные карты и словари;
• количественно оценивать выигрыш отсечения колонок (Column Pruning) при агрегации широких таблиц;
• настраивать предикатный пушдаун (Predicate Pushdown) для исключения чтения ненужных диапазонов данных.

Оборудование и учебная среда

Для выполнения работы потребуются:

• интерпретатор DuckDB (CLI или Python-модуль duckdb);
• консольная утилита ls -lh или du для оценки размера файлов на диске;
• учебный набор данных показаний приборов учёта readings.csv.

Порядок выполнения работы

Часть 1. Конвертация CSV в Parquet и исследование сжатия

1. Запустите сессию DuckDB и оцените размер и схему исходного набора данных:

   DESCRIBE SELECT * FROM read_csv_auto('readings.csv');
   

2. Экспортируйте исходный CSV в файл Parquet без сжатия:

   COPY (SELECT * FROM read_csv_auto('readings.csv'))
   TO 'readings_uncompressed.parquet' (FORMAT PARQUET, COMPRESSION UNCOMPRESSED);
   

3. Экспортируйте тот же набор с алгоритмом сжатия Snappy (по умолчанию):

   COPY (SELECT * FROM read_csv_auto('readings.csv'))
   TO 'readings_snappy.parquet' (FORMAT PARQUET, COMPRESSION SNAPPY);
   

4. Экспортируйте с современным алгоритмом Zstandard (уровень сжатия по умолчанию):

   COPY (SELECT * FROM read_csv_auto('readings.csv'))
   TO 'readings_zstd.parquet' (FORMAT PARQUET, COMPRESSION ZSTD);
   

5. Сравните размеры получившихся файлов на диске:

   ls -lh readings.csv readings_*.parquet
   

   Рассчитайте коэффициент сжатия (K = \frac{V_{\text{исходный}}}{V_{\text{сжатый}}}) для каждого варианта.

Часть 2. Анализ метаданных файла Parquet

1. Исследуйте структуру групп строк созданного файла с помощью встроенной функции DuckDB:

   SELECT file_name, row_group_id, row_group_num_rows, stats_min, stats_max
   FROM parquet_metadata('readings_zstd.parquet')
   WHERE path_in_schema = 'timestamp';
   

2. Обратите внимание на поля stats_min и stats_max. Это зонные карты (Zone Maps), по которым движок принимает решение о необходимости чтения группы строк.
3. Оцените размер словарей и данных для категориальных столбцов (например, код типа прибора или статус показания).

Часть 3. Эффект отсечения столбцов (Column Pruning)

1. Включите профилирование запросов в DuckDB:

   PRAGMA enable_profiling;
   PRAGMA profiling_output = 'terminal';
   

2. Выполните запрос агрегации по всем столбцам к CSV-файлу:

   SELECT avg(val) FROM read_csv_auto('readings.csv');
   

   Зафиксируйте время выполнения и объём прочитанных данных.
3. Выполните аналогичный запрос к файлу readings_zstd.parquet:

   SELECT avg(val) FROM read_parquet('readings_zstd.parquet');
   

   Сравните время выполнения. Обратите внимание, что DuckDB считал с диска только блок данных столбца val, полностью проигнорировав остальные столбцы.

Часть 4. Проверка предикатного пушдауна (Predicate Pushdown)

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

   EXPLAIN ANALYZE
   SELECT device_id, count(*), avg(val)
   FROM read_parquet('readings_zstd.parquet')
   WHERE timestamp BETWEEN '2024-03-01' AND '2024-03-05'
   GROUP BY device_id;
   

2. В дереве плана найдите узел PARQUET_SCAN. Изучите метрики:
   • Filters: timestamp>=... AND timestamp<=...
   • Количество прочитанных групп строк из общего числа (например, Read Row Groups: 1/10).
3. Объясните, почему 90 % файла не было прочитано с диска.

Журнал работы

Подготовьте отчет о выполнении лабораторной работы, содержащий:

1. Сравнительную таблицу форматов: CSV, Parquet Uncompressed, Parquet Snappy, Parquet ZSTD (размер на диске в МБ, коэффициент сжатия, время выполнения полного агрегирования).
2. Вывод метаданных зонных карт из parquet_metadata() для ключевых столбцов.
3. План выполнения запроса с предикатным пушдауном и подтверждением пропуска групп строк.
4. Выводы об условиях применимости алгоритмов Snappy и Zstandard в телеметрических системах.