Какие форматы используются для оптимизации трафика при передаче данных в Kafka кроме JSON?
Что проверяют
Понимаете ли вы, что трафик в Kafka сокращают двумя независимыми рычагами: бинарной сериализацией и сжатием батчей. Второй вопрос почти обязателен: как вы меняете схему сообщения, не ломая уже работающих консьюмеров.
Как отвечать
Начните с форматов, которые реально живут рядом с Kafka в Java-проектах:
- Avro: бинарный формат, в сообщении нет имён полей, только значения. Схема описывается в JSON, классы генерирует плагин сборки. Эволюция схемы развита хорошо: новое поле со значением
defaultдобавляется без поломки читателей; - Protobuf: поля идентифицируются номерами тегов, их можно добавлять, но нельзя переиспользовать номер удалённого поля. Классы генерирует
protoc, формат удобен, если те же модели ходят по gRPC; - JSON Schema: по размеру остаётся JSON, но получает контракт и проверку совместимости;
- MessagePack, Thrift: встречаются, но с экосистемой Kafka интегрированы слабее.
Ключевой элемент здесь Schema Registry. Сериализатор (KafkaAvroSerializer, KafkaProtobufSerializer) регистрирует схему, а в сообщение кладёт только магический байт и четырёхбайтовый идентификатор схемы. Реестр проверяет режим совместимости (BACKWARD по умолчанию, FORWARD, FULL) и не даст зарегистрировать ломающую версию.
Второй рычаг это сжатие на продюсере: compression.type со значениями gzip, snappy, lz4, zstd. Сжимается весь батч, поэтому эффект зависит от batch.size и linger.ms: чем крупнее батч, тем лучше коэффициент. Для JSON с повторяющимися ключами zstd иногда даёт выигрыш не меньше, чем переход на другой формат, и стоит одну строку конфигурации.
Где спотыкаются
Называют форматы, но молчат про сжатие батчей, хотя это самый дешёвый выигрыш и его стоит проверить первым.
Меняют тип поля или удаляют обязательное поле, считая, что бинарный формат «сам разберётся». Консьюмер на старой схеме падает на десериализации, и сообщения копятся в топике.
Используют Avro без реестра и без схемы у читателя. Сообщение без имён полей невозможно прочитать, не зная точной схемы, которой пользовался писатель.