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

Schema evolution и compatibility

Раздел 04 · Типы достоверности

Тип материала: инженерный разбор. Схемы и примеры иллюстративные. Рекомендации — INFERENCE; учебные параметры — HYPOTHETICAL.

Проверка источников: 2026-11-02. Версии и границы первоисточников перечислены в конце. Documented contracts не означают выполненный runtime test.

Принцип работы и границы

Сначала определите направление чтения: backward — новый reader читает старые данные; forward — старый reader читает новые; full объединяет направления в выбранном режиме. Transitive режим проверяет историю шире одной предыдущей версии. Конкретные правила зависят от Avro/Protobuf/JSON Schema; Schema Registry documentation.

INFERENCE: compatibility на уровне wire format — только первый gate. Consumer может декодировать новое значение enum, но неверно трактовать его. Replay старого архива новым кодом требует исторических schema IDs, defaults и business semantics. Default reader field не заполняет автоматически все старые записи во внешней БД.

Новая версия должна явно задавать money units, timezone, null semantics, identity и correction behavior. CDC DDL evolution дополнительно затрагивает source snapshots, log reader и downstream mapping; версия connector не гарантирует совместимости любого DDL.

Иллюстративная архитектура

flowchart LR
 P[Proposed schema and semantics] --> R[Compatibility registry]
 R --> H[Historical writer fixtures]
 H --> C[Consumer contract tests]
 C --> D[Reader-first rollout and monitored cutover]
 D --> A[Archive replay validation]

Failure scenarios

Удалённое поле нужно старому consumer. Переименование без alias выглядит как drop+add. Timestamp precision меняется и нарушает dedup key. Registry восстановлен без schema ID history: bytes в Kafka сохранились, но decoder не работает. Новый business status декодируется, но уходит в неправильную ветку.

Recovery protocol

  1. Остановить несовместимый producer/affected route; сохранять original bytes и schema ID.
  2. Восстановить registry history и reader с поддержкой обеих версий.
  3. Проверить old-writer/new-reader и new-writer/old-reader согласно выбранному режиму.
  4. Прогнать historical replay на отдельной generation и проверить semantic invariants.
  5. После consumer rollout включить producer, затем контролируемо снять dual-read compatibility.

Trade-offs и критерии выбора

Длительная поддержка версий усложняет код, но нужна для archive replay. Большая единая schema связывает независимые teams; слишком мелкие contracts увеличивают orchestration. Blind permissive parsing уменьшает failures ценой silent semantic corruption.

FinTech и iGaming

Изменение суммы major/minor или currency scale может привести к реальному списанию при корректной десериализации. Для iGaming смена settlement status требует тестов compensation, а не только schema acceptance.

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

В существующем guide используйте конкретные schema-файлы; воспроизведите old writer/new reader default resolution и отдельно проверьте money semantics. Точный runtime protocol см. guide. Registry integration остаётся NOT_RUN.

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

Считать non-transitive backward достаточным для многолетнего архива; reuse Protobuf field numbers; приравнивать nullable/default к business-valid; терять schema IDs при DR.

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

Backward означает старый reader читает новое? Нет, это направление forward.

Почему schema acceptance не доказательство безопасного deploy? Wire rules не знают бизнес-смысла новых значений и совместимости эффектов.

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