Колоночные форматы против строковых: почему Parquet почти всегда лучше CSV для аналитики.
Ключевые тезисы
- Колоночное хранение читает только нужные столбцы и сжимает их в разы лучше.
- Parquet хранит схему и статистики блоков — это позволяет пропускать целые куски файла.
- CSV остаётся только для обмена с внешними системами: у него нет типов и он не сжимается по столбцам.
Подробный разбор
2 подтем — раскройте любую, чтобы увидеть объяснение, формулы, примеры и интерактивные графики.
1Почему колоночный формат быстрее
Читаем только то, что нужно.
Аналитический запрос обычно берёт 3–5 столбцов из 200. Строковый формат вынуждает прочитать все данные целиком, колоночный — только нужные столбцы, и они лежат подряд, поэтому лучше сжимаются и векторизуются.
| Формат | Сжатие | Схема | Когда |
|---|---|---|---|
| CSV | плохое | нет | обмен с внешними системами |
| Parquet | отличное | есть | аналитика, ML, хранение |
| Avro | хорошее | есть | потоковые события, эволюция схемы |
| ORC | отличное | есть | экосистема Hive |
2Predicate pushdown
Как Parquet пропускает целые куски файла.
Parquet хранит min/max для каждой группы строк. Если запрос фильтрует date >= '2026-08-01', движок пропускает группы, чьи максимумы меньше — не читая их с диска вообще.
Отсюда практическое правило: сортируйте данные внутри партиции по колонке, по которой чаще всего фильтруете. Это может ускорить запросы в разы бесплатно.
Связанные темы
Платформа данных
Warehouse, Lake, Lakehouse80%
Хранилище, озеро, lakehouse · Инженерия данныхТри способа хранить аналитические данные: строгая схема, сырые файлы или гибрид с транзакциями поверх объектного хранилища.
Partitioning80%
Партиционирование · Инженерия данныхРазделение данных по ключу (обычно по дате), чтобы запрос читал минимум файлов.
Analytical SQL80%
Аналитический SQL · Инженерия данныхОконные функции, агрегации и CTE — основной инструмент подготовки признаков на больших данных.
ETL vs ELT80%
ETL и ELT · Инженерия данныхПреобразовывать данные до загрузки или уже внутри хранилища — и почему индустрия сместилась ко второму.
Batch and Streaming80%
Батч и стриминг · Инженерия данныхОбработка по расписанию против непрерывной обработки событий. Разные задержки, разные гарантии, разная стоимость.
Orchestration80%
Оркестрация пайплайнов · Инженерия данныхПланировщик, который знает зависимости между задачами, повторяет упавшие и не даёт запускать одно и то же дважды.
Spark80%
Spark · Инженерия данныхРаспределённая обработка больших объёмов данных: тот случай, когда данные не помещаются на одну машину.
Kafka80%
Kafka · Инженерия данныхРаспределённый журнал событий: основа потоковой архитектуры и источник данных для онлайн-признаков.
ML Pipelines80%
ML-пайплайны · MLOpsОформление обучения как воспроизводимой последовательности шагов вместо разрозненных ноутбуков.
Data Versioning80%
Версионирование данных · MLOpsДанные меняются чаще кода — без их версий эксперимент не воспроизвести.