Learning Platform
Глоссарий Troubleshooting
Урок 02.04 · 20 мин
Средний
CompressionSnappyZstdLZ4GZIPBlock Compression

Основы компрессии

Компрессия — финальная стадия

В предыдущем уроке мы разобрали кодировки — они используют знание о типе данных (dictionary для строк, delta для timestamps). Компрессия — следующий шаг: она берёт уже закодированные данные и сжимает их общим алгоритмом, не зная, что внутри.

Два главных trade-off:

  • Степень сжатия (compression ratio) — во сколько раз уменьшается размер
  • Скорость — как быстро данные сжимаются и разжимаются

Эти два параметра всегда в конфликте. Чем сильнее сжатие, тем дольше compress/decompress.

Четыре главных алгоритма

В мире data engineering доминируют четыре алгоритма компрессии:

Сравнение алгоритмов компрессии
SnappyРазработан Google. Приоритет — скорость декомпрессии. Сжимает хуже, но распаковывает быстрее всех.
LZ4Похож на Snappy по философии. Чуть лучше сжатие, сопоставимая скорость. Популярен в Kafka и ClickHouse.
ZstdРазработан Facebook. Баланс между скоростью и сжатием. Настраиваемый уровень (1–22). Новый стандарт индустрии.
GZIPКлассический алгоритм (1992). Хорошее сжатие, но медленная распаковка. Стандарт де-факто для HTTP, но уступает Zstd в data engineering.

Бенчмарки: что выбрать

Типичные цифры на аналитических данных (1 GB колоночных данных после encoding):

АлгоритмCompression RatioCompress SpeedDecompress SpeedТипичное применение
Snappy2–3x~500 MB/s~1.5 GB/sSpark default, Parquet default
LZ42.5–3.5x~500 MB/s~2 GB/sKafka, ClickHouse
Zstd (level 3)3.5–5x~300 MB/s~1 GB/sНовый default для многих систем
GZIP3–4.5x~50 MB/s~300 MB/sLegacy, HTTP, текстовые форматы
WARNING

Бенчмарки зависят от данных. На числовых данных с хорошим encoding разница между алгоритмами минимальна — encoding уже сделал основную работу. На текстовых данных без encoding разница может быть 5x.

Когда какой использовать

Дерево выбора алгоритма компрессии

Что критичнее?

Первый вопрос: что важнее — скорость запросов или экономия места на диске?
Скорость запросов

Горячие данные, частые reads

Горячие данные читаются часто — каждая миллисекунда декомпрессии умножается на тысячи запросов

Snappy / LZ4

Snappy или LZ4 — минимальный overhead на распаковку. Для Kafka-потоков LZ4, для Parquet-файлов Snappy.
Экономия хранения

Холодные данные, архив

Архивные данные читаются редко, но занимают терабайты. Сжатие на 30–50% больше = значительная экономия на S3.

Zstd (/ GZIP для legacy)

Zstd даёт лучший баланс. GZIP — только если совместимость с legacy системами обязательна.
TIP

Правило 2024+: если нет специальных требований — используйте Zstd level 3. Он сжимает лучше Snappy, а распаковывает почти так же быстро. Многие системы переходят на Zstd как default: Delta Lake, Iceberg, новые версии Spark.

Блочная vs страничная компрессия

Компрессия применяется не к файлу целиком, а к блокам (или страницам):

Блочная компрессия в Parquet

Колонка salary (10M значений)

Колонка разбита на страницы (pages) по ~1 MB. Каждая страница — независимая единица компрессии.
Разбиение на страницы
Page 1Первые ~100K значений. Сжимается и разжимается независимо от остальных страниц.
Page 2Следующие ~100K значений. Если нужны только эти строки, остальные страницы не распаковываются.
Page NКаждая страница — независимый блок. Это позволяет random access внутри колонки.
Predicate pushdown

Распаковываются только нужные страницы

Если WHERE salary > 100000, движок проверяет min/max статистики каждой страницы и распаковывает только релевантные

Блочная компрессия даёт два преимущества:

  1. Параллелизм — разные блоки распаковываются разными потоками
  2. Selective decompression — если нужны только строки 100K–199K, распаковывается только один блок

Цена компрессии: CPU vs Storage

Компрессия экономит storage и network, но тратит CPU. В облаке нужно считать оба:

СценарийЛучший выборПочему
S3 + Athena (pay per scan)ZstdМеньше данных = меньше $/TB scanned
Kafka (высокий throughput)LZ4Минимальный CPU overhead на producer/consumer
Spark (batch processing)Snappy или ZstdSnappy — legacy default, Zstd — лучше при тех же ресурсах
Архив в GlacierGZIP или Zstd-19Максимальное сжатие, скорость не важна
Real-time servingLZ4 или без компрессииКаждая микросекунда decompress = P99 latency
NOTE

Современные CPU сжимают данные быстрее, чем диск может их записать. Для Snappy/LZ4 компрессия бесплатна — bottleneck на I/O, не на CPU. Zstd на высоких уровнях (10+) — единственный случай, когда CPU становится bottleneck.

Ключевые выводы

  1. Компрессия работает после кодирования. Кодирование знает тип данных, компрессия — нет.
  2. Snappy/LZ4 — максимальная скорость, умеренное сжатие. Для hot data и streaming.
  3. Zstd — лучший баланс. Новый стандарт индустрии. Настраиваемый уровень (1–22).
  4. GZIP — legacy. Используйте, только если требуется совместимость.
  5. Блочная компрессия позволяет распаковывать только нужные части файла — критично для predicate pushdown.
  6. На уже хорошо закодированных данных разница между алгоритмами меньше, чем кажется — основную работу делает encoding.

Проверьте понимание

Результат: 0 из 0
Прикладной
Вопрос 1 из 4. Данные на S3, запросы через Athena (pay-per-scan). Нужно минимизировать стоимость запросов. Какой алгоритм компрессии оптимален?

Закончили урок?

Отметьте его как пройденный, чтобы отслеживать свой прогресс

Войдите чтобы оценить урок

Прогресс модуля
0 из 5