Выбор формата Parquet, Avro или ORC в 2026

Сравнение Parquet, Avro и ORC помогает инженерам DWH подобрать формат под конкретные нагрузки чтения и записи. Parquet и ORC оптимизированы для аналитических запросов за счёт колоночной организации, Avro лучше справляется с частыми изменениями схемы при потоковой записи. Apache Iceberg использует все три формата одновременно на разных этапах жизненного цикла данных, поэтому выбор уже не сводится к одному решению на весь контур. Это позволяет точнее балансировать скорость ingestion, размер хранения и производительность запросов. При оценке вариантов важно учитывать не только технические характеристики каждого формата, но и профиль нагрузки в конкретной системе: долю операций записи из внешних источников, частоту эволюции схемы и требования к скорости аналитических запросов. Инженеры DWH часто сталкиваются с необходимостью поддерживать несколько форматов в одном контуре, чтобы избежать компромиссов между скоростью поступления данных и эффективностью их последующего анализа.

Колоночная организация против строковой

Parquet и ORC хранят данные по колонкам, что даёт сильный выигрыш при селективных запросах и агрегациях. Сжатие работает эффективнее, поскольку однотипные значения попадают в один блок, а predicate pushdown отсекает ненужные данные ещё на уровне файловой системы. Avro же записывает строки целиком, поэтому при частых обновлениях схемы и потоковой записи из Kafka он требует меньше ресурсов на сериализацию. Колоночные форматы Parquet и ORC особенно полезны в сценариях, где преобладают запросы с фильтрацией по отдельным полям или вычислением агрегатов над большими объёмами исторических данных. В таких случаях они позволяют снизить объём считываемых данных и уменьшить нагрузку на кластер. Строковый формат Avro, напротив, упрощает обработку событий, где структура записи может меняться со временем, например при добавлении новых атрибутов в поток событий. На практике разница проявляется в соотношении write/read. Если поток данных из Kafka поступает непрерывно и требует частого добавления полей, Avro снижает накладные расходы на запись. Когда же данные оседают в Iceberg-таблице и используются для BI-отчётов, Parquet или ORC дают заметный прирост скорости сканирования. Выбор зависит от доли операций записи и чтения в конкретном пайплайне. Перед финальным решением рекомендуется оценить, насколько критична для проекта возможность быстрой адаптации к изменениям схемы и какова доля аналитических нагрузок в общей работе системы.

Как Iceberg сочетает три формата

Iceberg хранит метаданные отдельно и позволяет указывать формат для каждого snapshot или partition. Для staging-таблиц, куда сначала попадают сырые события из Kafka, часто используют Avro, чтобы быстро фиксировать изменения схемы. После compaction или оптимизации данные перекладывают в Parquet или ORC для ускорения аналитических запросов. Такой подход даёт гибкость без переписывания всего пайплайна. Apache Iceberg выступает в роли прослойки, которая абстрагирует работу с файлами и обеспечивает согласованность данных независимо от выбранного формата хранения. Это особенно важно в распределённых системах, где разные команды могут использовать одни и те же таблицы для разных задач. При этом Iceberg сохраняет ACID-свойства независимо от формата файлов. Инженер может менять формат на уровне таблицы, не ломая существующие запросы. Это особенно полезно в смешанных нагрузках, где часть процессов требует быстрой записи, а другая — быстрого чтения. Ограничение возникает при частой смене формата: требуется дополнительный compaction, который потребляет CPU и диск. При планировании миграции или внедрения важно учитывать, что частые преобразования между форматами увеличивают общие затраты на вычислительные ресурсы и могут влиять на доступность данных в периоды оптимизации.

Kafka, потоковая запись и последующая оптимизация

Kafka хорошо работает с Avro, потому что сериализация строковых сообщений происходит быстро и схема эволюционирует без остановки топиков. После потребления события обычно конвертируют в Parquet или ORC через Spark или Flink. Iceberg позволяет делать это инкрементально, добавляя новые файлы к существующей таблице без перезаписи истории. В российских контурах, где часто используют on-premise кластеры без доступа к managed-сервисам, такой подход снижает зависимость от конкретного облачного провайдера. Команды могут оставить Avro для ingestion и переключаться на Parquet для аналитики, используя те же Iceberg-каталоги. Главное ограничение — необходимость поддерживать несколько форматов в одном пайплайне и следить за совместимостью сериализаторов. При проектировании контура важно оценить, насколько часто происходят изменения в источниках данных и требуется ли сохранять историю версий схемы без остановки потоков. Также следует учитывать, что использование нескольких форматов увеличивает сложность мониторинга и отладки пайплайнов.

Практические ограничения при выборе

Parquet даёт хорошее сжатие и быстрые запросы, но хуже переносит частые изменения схемы по сравнению с Avro. ORC в некоторых реализациях показывает преимущество при сложных типах данных, однако поддержка в экосистеме Spark и Flink чуть уже. Avro, в свою очередь, проигрывает при сканировании больших объёмов из-за строковой организации. Перед внедрением стоит протестировать реальные запросы на типичных объёмах данных. Iceberg позволяет откатить неудачный выбор формата, но каждый compaction требует ресурсов. В итоге решение принимают на основе профиля нагрузки: доли записи из Kafka, частоты изменения схемы и требований к скорости аналитики. При этом необходимо учитывать не только текущие объёмы, но и перспективы роста данных, а также наличие экспертизы в команде по работе с каждым из форматов.

Источник

Это краткий разбор материала Dremio. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Выбор формата Parquet, Avro или ORC в 2026.

Курс по теме — Каталог курсов Школы Больших Данных