Какие схемы сжатия данных вы применяли в DWH и Big Data?

Выбор схемы сжатия — это всегда компромисс между степенью сжатия, скоростью и вычислительными затратами. Вот мой опыт:

В колоночных форматах (Parquet, ORC), которые являются стандартом для DWH/Data Lakes:

• Snappy: Использую по умолчанию для "горячих" данных, с которыми часто работают интерактивные запросы. Очень высокая скорость распаковки при умеренной степени сжатия.
• Gzip/Zlib: Применяю для исторических или "холодных" данных, где приоритет — экономия на хранении, а не скорость чтения. Даёт лучшее сжатие, но нагружает CPU.
• Zstandard (Zstd): Мой фаворит для новых проектов. Обеспечивает степень сжатия, близкую к Gzip, при скорости, сравнимой со Snappy. Поддерживает настраиваемые уровни сжатия.

Настройка в Apache Spark:

# Запись с указанием компрессии для Parquet
(df.write
   .option("compression", "zstd")  # или "snappy", "gzip"
   .parquet("/data/events"))

# Для ORC
(df.write
   .option("compression", "snappy")
   .orc("/data/events_orc"))

Для строковых/текстовых форматов (логи, JSON в S3/Blob Storage):

• Brotli: Отлично подходит для сжатия текстовых данных перед загрузкой в облачное хранилище, даёт высокий коэффициент.
• LZ4: Использую в стриминговых конвейерах (например, при промежуточной записи в Kafka), где критически важна минимальная задержка.

В колонках реляционных СУБД (Oracle, PostgreSQL):

• Использую встроенное сжатие на уровне таблиц или партиций. Например, в Oracle — COMPRESS FOR OLTP или COMPRESS FOR QUERY, в PostgreSQL — pg_repack с включённым сжатием TOAST.

Критерии выбора в проекте:

1. Паттерн доступа: Частые чтения → Snappy/Zstd. Редкие чтения/архив → Gzip/Brotli.
2. Вычислительные ресурсы: Gzip требует больше CPU, что может стать узким местом при массовой загрузке.
3. Экономика: Для петабайтных хранилищ даже 10-15% экономии от выбора более агрессивного сжатия дают значительную финансовую выгоду.