Parquet и ORC: почему колоночные форматы выигрывают в аналитике данных

Представьте, что вам нужно найти все заказы за прошлый месяц из таблицы с миллиардами строк. В обычном текстовом файле или CSV вы будете читать каждую строку целиком, даже если вас интересует только одна колонка со стоимостью. Это медленно и дорого. Именно здесь на сцену выходят колоночные форматы хранения, такие как Parquet и ORC. Они позволяют читать только нужные данные, игнорируя остальное, что резко ускоряет аналитические запросы.

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

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

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

• Снижение объема чтения. Вы читаете только те поля, которые нужны для запроса. Остальные байты остаются нетронутыми.
• Лучшее сжатие. Данные внутри одного столбца обычно однородны (например, все числа или все даты). Алгоритмы сжатия работают с однородными данными эффективнее, чем со смешанными.
• Параллелизм. Разные узлы кластера могут обрабатывать разные столбцы одновременно, используя все доступные ядра процессора.

Для аналитических нагрузок (OLAP), где важно просчитывать агрегаты по огромным массивам, это критично. Транзакционные системы (OLTP) чаще используют строковые форматы, так как там важнее скорость записи целых объектов.

Parquet: гибкость и экосистема

Apache Parquet является колоночным форматом хранения данных, поддерживающим сложную схему и глубокую интеграцию с инструментами анализа. Он изначально разрабатывался в Twitter (ныне X Corp.) для обработки больших объемов логов и событий. Сегодня Parquet стал де-факто стандартом в экосистеме Hadoop.

Что делает Parquet таким популярным?

1. Поддержка вложенных схем. Формат легко справляется со структурами типа JSON или Avro, где объекты вложены друг в друга. Это удобно, когда данные приходят из NoSQL баз или потоковых обработчиков.
2. Широкая поддержка инструментов. Parquet понимают Spark, Hive, Presto, Impala, Dask и многие другие движки. Если вы пишете код на Python с использованием Pandas или PyArrow, чтение Parquet происходит нативно и быстро.
3. Диапазон индексов (Row Group Statistics). Внутри файла данные делятся на группы строк (row groups). Для каждой группы хранятся минимальные и максимальные значения каждого столбца. Это позволяет движку пропускать целые блоки данных, если они не содержат нужных значений.

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

ORC: оптимизация для Hadoop и Hive

Optimized Row Columnar (ORC) является колоночным форматом, разработанным специально для Hadoop-экосистемы с упором на высокую степень сжатия. Этот формат появился позже Parquet и был создан командой Facebook (Meta) для улучшения производительности Hive.

ORC делает ставку на два аспекта:

• Более плотное сжатие. Благодаря использованию алгоритмов ZLIB и Snappy (по умолчанию) и внутренней структуре, ORC часто занимает меньше места на диске, чем Parquet, особенно для текстовых данных.
• Строгая типизация. Формат жестче относится к схемам данных. Это снижает вероятность ошибок при чтении, но усложняет работу с изменяющимися структурами.

Если ваша инфраструктура построена вокруг Hive и Cloudera Distribution (CDH), ORC может быть более естественным выбором. Он тесно интегрирован с метаданными Hive, что упрощает управление правами доступа и статистикой.

Сравнение Parquet и ORC: что выбрать?

Выбор между форматами зависит от вашей стека технологий и характера данных. Давайте посмотрим на ключевые параметры сравнения.

Обратите внимание на пункт «Экосистема». Если вы используете Apache Spark для большинства задач, Parquet будет быстрее благодаря нативной поддержке через библиотеку Arrow. Если же вы heavily полагаетесь на HiveQL и Impala, ORC покажет лучшие результаты за счет оптимизаций под эти движки.

Практические советы по выбору

Как принять решение, если оба формата подходят технически? Вот несколько эвристик, которые помогут сузить выбор:

• Проверьте поддержку в вашем SQL-движке. Узнайте, какой формат имеет приоритет в вашем кластере. Например, некоторые версии Presto оптимизированы под Parquet, тогда как старые версии Impala лучше работали с ORC.
• Оцените структуру данных. Если у вас много вложенных JSON-объектов или массивов, выбирайте Parquet. Он справится с этим без потери производительности. Для простых таблиц с фиксированными колонками ORC может предложить лучшее сжатие.
• Учитывайте размер файлов. Старайтесь создавать файлы размером от 128 МБ до 1 ГБ. Слишком мелкие файлы создают нагрузку на NameNode в HDFS, слишком крупные снижают параллелизм. Этот принцип работает для обоих форматов.
• Тестируйте на реальных данных. Запустите бенчмарк на выборке ваших данных. Сравните время выполнения типовых запросов и итоговый размер файлов. Часто разница составляет 5-15%, что может быть решающим фактором при масштабах петабайтов.

Не стоит забывать и о гибридных подходах. Современные lakehouse-архитектуры, такие как Delta Lake или Apache Iceberg, могут работать поверх любого из этих форматов, добавляя транзакционность и контроль версий. В таком случае выбор физического формата становится менее критичным, так как слой абстракции берет на себя часть оптимизаций.

Типичные ошибки при использовании

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

1. Хранение ID-колонк в начале файла. Иногда логически удобно ставить идентификаторы первыми, но для аналитики это бессмысленно. Лучше хранить высококардинальные колонки (те, где мало повторяющихся значений) ближе к началу, чтобы ускорить фильтрацию.
2. Отсутствие партиционирования. Если вы храните данные за несколько лет в одном файле, любой запрос будет сканировать весь объем. Используйте партиционирование по дате или региону, чтобы ограничивать область поиска.
3. Частая перезапись мелких файлов. Колоночные форматы хорошо работают с большими, неизменяемыми блоками. Если вы постоянно обновляете отдельные строки, рассмотрите использование ACID-совместимых слоёв (Delta/Iceberg) или переход к другим архитектурам.

Правильная настройка параметров записи (compression codec, row group size) также влияет на результат. По умолчанию большинство инструментов выбирают Snappy, который балансирует скорость сжатия и размер. Для архивных данных, где скорость чтения не важна, можно использовать ZSTD для экономии места.

Перспективы развития

Мир больших данных меняется. Появляются новые форматы, такие как Apache Arrow (который скорее является форматом обмена в памяти, но тесно связан с Parquet) и Delta Lake. Однако Parquet и ORC никуда не денутся. Они стали фундаментом, на котором строятся современные платформы аналитики.

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

Так что, если вы только начинаете строить data lake, не бойтесь экспериментировать. Начните с Parquet, если хотите максимальную совместимость с современными инструментами (Spark, Python). Выберите ORC, если ваша команда глубоко погружена в классический стек Hadoop/Hive. И помните: правильный формат - это лишь половина успеха. Вторая половина - правильная организация данных и понимание нагрузки.