Parquet vs ORC vs Avro для Data Engineer: гайд

Зачем спрашивают про форматы

Любой DWH/Lakehouse — это файлы на S3/HDFS в одном из форматов. Spark читает Parquet, Kafka работает с Avro в schema registry, Hive читает ORC. Системный аналитик в облачной команде в 2026 обязан понимать, в чём разница.

Главная боль без понимания форматов — DE сваливает гигабайты CSV на S3, аналитик жалуется, что Athena сжигает $10 за один запрос. После перехода на Parquet — те же запросы $0.30. На собесе спрашивают «почему Parquet быстрее CSV?» — нужно ответить через columnar storage и predicate pushdown.

Эта статья — базовая матрица выбора и понимание, как форматы влияют на стоимость и скорость пайплайнов.

Columnar vs row storage

Row format (CSV, JSON, Avro):

record1: id=1, name=Anna, age=30, salary=100k
record2: id=2, name=Boris, age=25, salary=80k

На диске: 1,Anna,30,100k\n2,Boris,25,80k. Один record — одна строка байтов.

Columnar format (Parquet, ORC):

column id:     [1, 2, 3, ...]
column name:   [Anna, Boris, Catherine, ...]
column age:    [30, 25, 35, ...]
column salary: [100k, 80k, 120k, ...]

На диске: каждая колонка — отдельный блок.

Преимущества columnar для аналитики:

• Selective read: SELECT name, age читает только 2 колонки, не все 50
• Compression: значения одной колонки похожи (один тип, узкий диапазон) → жмутся лучше (10–30× меньше CSV)
• Vectorized execution: CPU может обрабатывать сотни значений за такт через SIMD
• Predicate pushdown: WHERE age > 30 фильтрует на уровне чтения файла

Преимущества row для OLTP:

• Запись/чтение одной полной записи быстрее
• Подходит для streaming (одна запись за раз)

Parquet

Apache Parquet — стандарт columnar для batch-аналитики. Используется в Spark, Athena, BigQuery, Trino, dbt по дефолту.

Структура:

• Файл = N row groups
• Row group = N column chunks (по одному на каждую колонку)
• Column chunk = N pages

В каждом row group хранится min/max/null_count по колонке — это и есть predicate pushdown.

Плюсы:

• Excellent compression (Snappy / GZIP / ZSTD)
• Хорошая интеграция со всем pyspark/pandas/Spark экосистемой
• Schema embedded в файл
• Schema evolution (add/drop column с правилами)
• Partition pruning через directory structure (year=2026/month=05/day=07/*.parquet)

Минусы:

• Тяжело писать по одной записи (нужна batch-запись)
• Schema evolution ограничена (rename и type changes — сложно)

df.write.mode('overwrite') \
    .partitionBy('event_date') \
    .parquet('s3://bucket/events/')

ORC

Apache ORC (Optimized Row Columnar) — конкурент Parquet, появился в Hive. Доминирует в Hadoop-стеке (Hive, Tez).

Особенности:

• Bloom filters в индексах — pushdown по equality предикатам
• ACID-поддержка в Hive
• Лучше Parquet на некоторых типах данных и сжатии

Когда выбирать: Hive-стек. В Spark/dbt-стеке стандарт — Parquet.

ORC и Parquet взаимозаменяемы для большинства задач. На собесе достаточно понимать, что оба columnar, оба с pushdown, выбор обычно по экосистеме.

Avro

Apache Avro — row-based binary, со schema. Стандарт в Kafka (Schema Registry).

Особенности:

• Schema хранится отдельно (Schema Registry) или встроена в файл
• Schema evolution: backward/forward/full compatibility
• Compact binary
• Code generation на Java/Python (опционально)

Когда выбирать: streaming через Kafka, событийный pipeline с эволюцией схем.

{
  "type": "record",
  "name": "OrderEvent",
  "fields": [
    {"name": "order_id", "type": "long"},
    {"name": "amount", "type": "double"},
    {"name": "status", "type": "string", "default": "new"}
  ]
}

Schema Registry хранит схему по ID. Сообщение в Kafka — [schema_id (4 bytes)][avro_payload]. Consumer достаёт схему по id, десериализует.

Avro для batch: уступает Parquet в большинстве кейсов, но хорош, если входные потоки уже Avro и нужен сквозной формат.

Когда что

Сжатие: Snappy — быстрое, среднее сжатие. ZSTD — лучше сжатие, чуть медленнее. GZIP — старый, slow + good compression. Дефолт для Parquet — Snappy.

Schema evolution в Parquet:

• ✅ Add column with default
• ✅ Rename column через mergeSchema=true в Spark с алиасами
• ⚠️ Drop column — поддерживается, но reader должен обработать отсутствие
• ❌ Type change — нужно read с явным cast

Частые ошибки

CSV в продакшене. CSV не имеет типов, экранирование плавает между диалектами, нет компрессии in-format. Использовать только для интеропа и ручных выгрузок.

JSON для миллиардов записей. Парсить JSON дорого, размер большой. Если данные пришли в JSON — конвертировать в Parquet после ingestion.

Маленькие файлы (< 100 МБ) в Parquet. Каждый файл = метаданные. 1 ТБ в 100k файлов работает медленнее 1 ТБ в 1k файлов. Compaction — must.

Без партиционирования директорий. s3://bucket/events/*.parquet без year=/month=/day= — full scan на каждый запрос. Партиционировать по дате почти всегда.

Парквет с одной row group. Один большой файл с одной row group — нет parallelism. Spark разделит на партиции, но pushdown не сработает на уровне групп.

Avro в DWH-аналитике. Avro — row-based, не оптимален для column-selective запросов. Конвертировать в Parquet при загрузке в DWH.

Не использовать mergeSchema=false в Spark. Дефолтный mergeSchema=true дорогой, сканирует все footers. На стабильной схеме — mergeSchema=false быстрее.

Связанные темы

• Партиционирование в ClickHouse
• Spark на собеседовании DE
• Подготовка к собесу Data Engineer
• Kafka на собеседовании DE
• Data Lake vs Data Warehouse

FAQ

Parquet или ORC — что лучше?

Близкая производительность, выбор по экосистеме. Spark/Trino/Athena/dbt — Parquet. Hive — ORC. На современных стеках Parquet чаще.

Какой compression выбрать для Parquet?

Snappy — дефолт, баланс скорости и сжатия. ZSTD — лучше сжатие на 20–30%, незначительно медленнее, поддерживается Spark 3+ и Athena.

Почему Parquet быстрее CSV в SELECT?

Columnar storage (читает только нужные колонки), сжатие, predicate pushdown по min/max. На запросе SELECT a, b WHERE c > 10 Parquet читает 3 колонки + skip row groups, CSV — весь файл целиком.

Avro vs Protobuf для Kafka?

Оба бинарные с schema. Avro — стандарт de-facto в Kafka-экосистеме (Schema Registry). Protobuf — мощнее в типизации, лучше performance, но хуже инструменты вокруг Kafka. Зависит от стека.

Что выбрать для Data Lake?

Parquet + Iceberg/Delta для управления метаданными. Iceberg/Delta дают ACID-операции (UPDATE/DELETE/MERGE) на S3-данных, схему как код, time travel.

Это официальная информация?

Нет. Статья основана на спецификациях Parquet (Apache), ORC, Avro и общей практике дата-инжиниринга.

Тренируйте Data Engineering — откройте тренажёр с 1500+ вопросами для собесов.