Почему формат хранения важен
Формат — это архитектурное решение
Когда data engineer проектирует pipeline, он принимает десятки решений: какой оркестратор, какой движок, какое хранилище. Но одно решение влияет на всё остальное больше, чем кажется — формат хранения данных.
Формат определяет:
- Сколько стоит хранить 1 TB данных (разница 5–20x между форматами)
- Как быстро движок может прочитать нужные колонки (разница 10–100x)
- Можно ли менять схему без перезаписи всех данных
- Какие движки могут читать ваши данные без конвертации
Реальные цифры
Рассмотрим типичный аналитический датасет — 1 миллиард строк, 50 колонок, mix текстовых и числовых данных:
| Формат | Размер на диске | Время scan (все колонки) | Время scan (3 колонки) |
|---|---|---|---|
| CSV | ~500 GB | ~45 мин | ~45 мин (читает всё) |
| JSON | ~800 GB | ~60 мин | ~60 мин (читает всё) |
| Parquet (Snappy) | ~50 GB | ~4 мин | ~15 сек |
| ORC (Zlib) | ~45 GB | ~4 мин | ~15 сек |
Это не синтетический бенчмарк — это порядок величин, который вы увидите в реальных data lake. CSV/JSON обходятся дороже на хранение И на вычисления одновременно.
Три измерения формата
Каждый формат данных можно оценить по трём осям. Идеального формата не существует — есть trade-offs.
Скорость чтения
Как быстро движок может прочитать нужные данные. Зависит от layout (row/columnar), метаданных, индексовColumnar форматы читают только нужные колонки. Row форматы читают всю строку целиком.
Эффективность хранения
Сколько места занимают данные на диске. Зависит от кодировок, компрессии, overhead метаданныхКодировки + компрессия могут уменьшить размер в 10–20x по сравнению с raw текстом.
Гибкость схемы
Можно ли добавить колонку, переименовать поле, изменить тип без перезаписи всех данныхФорматы со встроенной схемой поддерживают эволюцию. CSV/JSON — нет.
Категории форматов
Форматы хранения делятся на несколько категорий по назначению. В этом курсе мы рассмотрим каждую:
Когда формат становится проблемой
Типичный сценарий: команда начинает с JSON в S3, потому что “просто и работает”. Через год:
- Хранение стоит $50K/мес — JSON не сжимается эффективно
- Запросы идут 20 минут — Athena читает каждый байт каждого файла
- Схема дрейфит — разные producers пишут разные поля
- Миграция на Parquet — 2 недели работы + перезапись всех данных
Правило: выбирайте формат в начале проекта, не в середине. Миграция формата на 100 TB данных — это не рефакторинг, это проект.
Как формат влияет на стоимость
В облаке вы платите за три вещи:
- Хранение — $/GB/месяц (S3, GCS, ADLS)
- Сканирование — $/TB просканированных данных (Athena, BigQuery)
- Compute — $/час работы кластера (Spark, Trino)
Columnar формат с хорошей компрессией уменьшает все три:
Raw данные (CSV/JSON) — 500 GB
Исходные данные в текстовом формате — максимальный размер, максимальная стоимостьParquet + Snappy — 50 GB (10x меньше)
Кодировки (dictionary, RLE) + компрессия (Snappy) уменьшают размер в 10xСканируется: 3 GB (из 50 GB) — 166x меньше чем CSV
Columnar layout позволяет читать только нужные колонки — ещё 16x экономия на scanЧто дальше
В следующих уроках этого модуля мы разберём фундаментальные концепции, на которых построены все форматы:
- Row vs Columnar — как данные физически раскладываются на диске
- Кодировки — как уменьшить размер данных до компрессии
- Компрессия — алгоритмы сжатия и их trade-offs
- Метаданные и схема — как форматы хранят информацию о себе
Эти четыре концепции — строительные блоки для понимания любого формата. Parquet, ORC, Arrow, Delta Lake — все они комбинируют эти блоки по-разному.