Як працює компресія повідомлень

Рівень Junior

Визначення

Компресія — це стиснення батчів повідомлень для зменшення використання network і disk space.

Без компресії: 1MB батч
З lz4: 300KB батч (70% економії)

Доступні алгоритми

gzip   — найкраще стиснення, повільна швидкість
snappy — середнє стиснення, швидка швидкість
lz4    — хороше стиснення, дуже швидка швидкість
zstd   — відмінне стиснення, середня швидкість

Налаштування

props.put("compression.type", "lz4");
// Варіанти: none, gzip, snappy, lz4, zstd

Навіщо потрібна компресія?

✅ Менше network I/O
✅ Менше disk usage на брокері
✅ Швидша передача повідомлень
✅ Менше cost за network traffic

Рівень Middle

Порівняння алгоритмів

Алгоритм	Стиснення	Швидкість	CPU Usage	Рекомендація
gzip	Найкраще	Повільно	Високий	Рідко використовується
snappy	Середнє	Швидко	Низький	Low latency
lz4	Хороше	Дуже швидко	Низький	Default choice
zstd	Відмінне	Середньо	Середній	Max compression

Налаштування компресії

Producer:

props.put("compression.type", "lz4");
// Компресія застосовується до батча цілком

Broker:

# Глобальне налаштування (може бути перевизначене на топику)
compression.type=producer — брокер НЕ перекомпресує повідомлення, а приймає
формат продюсера. Значення uncompressed змусить брокер розпакувати.

Topic:

kafka-configs.sh --alter --topic orders \
  --add-config compression.type=lz4 \
  --bootstrap-server localhost:9092

Compression Ratio

Приклади compression ratio:
  JSON дані: 3:1 - 5:1
  Текст: 4:1 - 10:1
  Бінарні дані: 1.5:1 - 2:1
  Вже стиснуті дані: 1:1 (немає ефекту)

Типові помилки

gzip для high-throughput:

Високий CPU overhead → bottleneck
→ Затримка обробки

Без компресії:

Великі повідомлення → більше network usage
→ Вище cost, повільніша передача

Компресія вже стиснутих даних:

gzip на gzipped файлах → немає ефекту
→ Wasted CPU

Рівень Senior

Internal Implementation

Compression Flow:

Продюсер накопичує повідомлення в батч
Батч серіалізується
Застосовується алгоритм компресії
Стиснутий батч відправляється брокеру
Брокер зберігає стиснутим
Консьюмер отримує стиснутим, розпаковує

Decompression:

Розпаковка відбувається на консьюмері:
- CPU usage на консьюмері
- Прозоро для додатку
- Kafka client library handles automatically

Algorithm Selection

lz4 — default choice:

Переваги:
- Дуже швидка компресія/decompression
- Хороший compression ratio
- Низький CPU usage
- Ідеально для більшості випадків

Use cases:
- General purpose
- High throughput systems
- Low latency requirements

zstd — max compression:

Переваги:
- Найкращий compression ratio
- Налаштовуваний рівень стиснення
- Швидший за gzip

Use cases:
- Економія disk space
- Cross-DC replication (економія bandwidth)
- Довгострокове зберігання

snappy — legacy choice:

Переваги:
- Швидка компресія
- Підтримка в старих клієнтах

Use cases:
- Сумісність зі старими системами
- Low latency з помірним стисненням

Compression Level Tuning

// zstd підтримує налаштування рівня
// 1-22 (за замовчуванням 3)
props.put("compression.type", "zstd");
// В деяких клієнтах:
props.put("zstd.level", "9");  // вище = краще стиснення

Performance Impact

CPU overhead:
  none:  0%
  lz4:   ~5%
  snappy: ~10%
  zstd:  ~15-20%
  gzip:  ~30-40%

Network savings:
  none:  0%
  lz4:   ~50-70%
  snappy: ~40-60%
  zstd:  ~60-80%
  gzip:  ~70-85%

(орієнтовні значення для JSON/text даних; реальні цифри залежать від типу даних
і необхідно тестувати на production workload)

Monitoring

Ключові метрики:

kafka.producer:compression-rate-avg
kafka.producer:compression-time-avg
kafka.consumer:decompression-time-avg
kafka.server:bytes-in-per-sec
kafka.server:bytes-out-per-sec

Alerts:

- Compression rate < 1.2 → investigate
- Compression time > threshold → warning
- CPU usage on brokers > threshold → warning

Best Practices

✅ lz4 за замовчуванням для більшості випадків
✅ zstd для економії disk/bandwidth
✅ Моніторинг CPU usage на брокерах
✅ Compression на батчі (не на повідомленні)
✅ Тестування ratio на production даних

❌ Без компресії для production
❌ gzip для high-throughput систем
❌ Компресія вже стиснутих даних
❌ Без моніторингу compression rate
❌ Ігнорування CPU impact

Архітектурні рішення

lz4 — баланс — найкращий вибір для більшості випадків
zstd — економія — коли disk/bandwidth критичні
Compression на батчі — кращий ratio
Monitoring compression rate — індикатор ефективності

Резюме для Senior

lz4 — найкращий баланс для більшості випадків
zstd — коли потрібне максимальне стиснення
Compression застосовується до батча цілком
CPU overhead vs network savings trade-off
Monitoring compression rate критичний для efficiency

🎯 Шпаргалка для інтерв’ю

Обов’язково знати:

Компресія стискає батчі для зменшення network I/O і disk usage
Алгоритми: gzip (найкраще стиснення, повільний), snappy (швидкий), lz4 (баланс), zstd (відмінне стиснення)
lz4 — default choice: дуже швидкий, хороший ratio, низький CPU (~5%)
Компресія застосовується до батча цілком — більший батч = кращий ratio
JSON/text: 3:1 - 5:1 ratio; бінарні: 1.5:1 - 2:1; вже стиснуті: 1:1
Продюсер стискає, консьюмер розпаковує прозоро (client library handles)
Broker НЕ перекомпресує — приймає формат продюсера

Часті уточнюючі запитання:

Який алгоритм обрати? — lz4 для більшості випадків, zstd для економії disk/bandwidth.
Де відбувається розпаковка? — На консьюмері, прозоро для додатку.
Чи можна стискати вже стиснуті дані? — Можна, але ефекту немає (1:1), wasted CPU.
Який overhead у gzip? — ~30-40% CPU, рідко використовується в high-throughput системах.

Червоні прапорці (НЕ говорити):

«Брокер перекомпресує повідомлення» — приймає формат продюсера
«gzip — найкращий вибір для production» — високий CPU overhead, lz4 краще
«Компресія на кожному повідомленні» — на батчі цілком
«Компресія безкоштовна» — CPU overhead 5-40% залежно від алгоритму

Пов’язані теми:

[[21. Що таке batch в Kafka producer]]
[[1. Що таке топiк (topic) в Kafka]]
[[3. Як дані розподіляються по партиціях]]