Уровень 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	Лучшее	Медленно	Высокий	Rarely used
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 (нет эффекта)

Типичные ошибки

1. gzip для high-throughput:

   Высокий CPU overhead → bottleneck
   → Задержка обработки
   

2. Без компрессии:

   Большие сообщения → больше network usage
   → Выше cost, медленнее передача
   

3. Компрессия уже сжатых данных:

   gzip на gzipped файлах → нет эффекта
   → Wasted CPU
   

---

Уровень Senior

Internal Implementation

Compression Flow:

1. Продюсер накапливает сообщения в батч
2. Батч сериализуется
3. Применяется алгоритм компрессии
4. Сжатый батч отправляется брокеру
5. Брокер хранит сжатым
6. Консьюмер получает сжатым, распаковывает

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

Архитектурные решения

1. lz4 — баланс — лучший выбор для большинства случаев
2. zstd — экономия — когда disk/bandwidth критичны
3. Compression на батче — лучший ratio
4. 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. Что такое топик (topic) в Kafka]]
• [[3. Как данные распределяются по партициям]]