Перейти к содержанию

Schema Registry, Avro, Protobuf и JSON Schema

Глубокие темы · Раздел03

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Версии в источниках: Kafka/Connect/Streams 4.1, Debezium 3.3, Flink 1.20.3, Spark 4.0.1 и Airflow 3.1 либо явно названная система. Непроверенные вопросы и ограничения runtime — в журнале (архив рабочего проекта).

Механизм

Registry управляет schema identities/subjects/compatibility; wire framing и subject naming — часть producer/consumer contract. Avro writer/reader schema resolution, Protobuf field numbers/wire types и JSON Schema validation имеют разные evolution rules. Structural compatibility не подтверждает currency/unit/business meaning.

flowchart TB
  Writer[Writer schema and subject] --> Registry[Registry compatibility and identity]
  Registry --> Bytes[Framed serialized record]
  Bytes --> Reader[Reader resolution]
  Reader --> Semantic[Units identity version validation]
  Semantic --> Effect[Business processing]

Пошаговое объяснение

Producer сериализует по writer schema/id → consumer разрешает schema/id → decoder восстанавливает record → business validation проверяет units, amount precision, event identity и version. Registry availability/cache влияет на старт и новый schema rollout; формат framing должен быть согласован.

Failure scenarios и recovery

BACKWARD/FORWARD/FULL и transitive режимы отвечают разным reader/writer rollout требованиям. Нельзя считать protobuf field rename эквивалентным повторному использованию field number; удалённые numbers/names резервируют. Avro default применяется при reader resolution отсутствующего поля, не универсально при любой writer записи.

Trade-offs и эксплуатация

JSON Schema optional/required/additionalProperties и numeric handling влияют на evolution. Decimal logical type/codecs, UTC/timezone и enum additions требуют compatibility matrix конкретной библиотеки/Registry version. Registry — отдельный продукт; здесь Confluent Schema Registry8.0 documentation reference, cloud service не предполагается.

У proto3 scalar с implicit presence unset amount может выглядеть как0: если отсутствие и ноль различаются по бизнес-смыслу, нужны optional/wrapper/oneof и явная validation policy. JSON number тоже не обещает одинаковую integer precision всех clients; lab ограничивает диапазон и отвергает money, декодированные Python как float. Avro logical decimal требует согласованных precision/scale и reader/writer resolution, а не преобразования в binary float.

Практический пример

В schemas example files есть JSON Schema/Avro/Protobuf contracts. JSON Schema и Avro round-trip доступны локально; реальная Registry API compatibility и Protobuf compilation имеют отдельный статус.

Типичные ошибки проектирования

Смешивать source/state/sink boundaries, скрывать failed records и неопределённый исход timeout; применять retry без identity/version и retention contract. Конкретные ограничения разобраны выше.

Вопросы на собеседовании

BACKWARD гарантирует правильную сумму после смены cents на euros? Нет, type может остаться тем же, semantics изменится.

Можно переиспользовать protobuf field number? Нельзя считать это безопасным evolution.

Практические упражнения

Спроектируйте v1→v2 поле currency с default, nullable amount и enum status addition. Для каждой схемы укажите rollout и semantic checks.

Дополнительные источники