Confluent Developer представив зміну у форматі повідомлень для Apache Kafka, яка має зробити роботу зі схемами чистішою та зручнішою для інтеграції з іншими системами: ідентифікатор схеми тепер може зберігатися в заголовках повідомлень, а не всередині самого payload.
Як було: схема «зашита» в payload
Традиційно Confluent‑серіалізатори працювали так:
- на початку кожного повідомлення додавався:
- 1 «магічний» байт,
- 4 байти з числовим ID схеми,
- далі — серіалізовані дані (JSON, Avro, Protobuf тощо).
Для екосистеми, де всі продюсери й консюмери використовують Confluent‑серіалізатори, це не створювало проблем. Але щойно до топіка підключалися інші системи, які очікують «чистий» JSON/Avro/Protobuf, починалися труднощі:
- перші байти payload виглядали як «зламані» або «пошкоджені» дані;
- сторонні інструменти бачили неочікуваний префікс і не могли коректно інтерпретувати повідомлення;
- інтеграція вимагала додаткових адаптерів або спеціальної логіки розбору.
Фактично, схема була жорстко прив’язана до формату самого payload, що ускладнювало взаємодію з будь‑якими системами поза Confluent‑стеком.
Новий підхід: схема переїжджає в заголовки
Нова опція у Confluent Serializers змінює лише одне, але принципове місце: ідентифікатор схеми більше не вбудовується в тіло повідомлення, а зберігається в Kafka headers.
Тепер структура виглядає так:
- payload — це «чисті» серіалізовані дані (JSON, Avro, Protobuf тощо) без жодних префіксів;
- headers — містять посилання на схему.
Консюмери, які працюють зі схемами, просто читають потрібний заголовок, визначають, яку схему застосувати, і десеріалізують дані. Ті, хто не знає про схеми, просто бачать звичайний payload і можуть працювати з ним як раніше.
Важливий нюанс: у заголовку використовується GUID, а не старий числовий schema ID. Цей GUID описує повне визначення схеми, включно з посиланнями та метаданими, і задуманий як більш портативний ідентифікатор, який легше переносити між різними реєстрами схем.
Чому це важливо: міграція без поломок і чисті інструменти
Ключові вигоди від перенесення схем у заголовки:
-
М’яка міграція до керування схемами
Якщо в Kafka вже є топіки з «чистими» payload‑ами, можна додати схеми, не змінюючи формат даних. Старі консюмери продовжують працювати, бо байти payload залишаються тими самими. -
Зворотна сумісність із legacy‑системами
Системи, які не знають про Confluent Schema Registry, більше не стикаються з «дивними» першими байтами. Для них це просто звичайний JSON/Avro/Protobuf. -
Краща інтеграція з інструментами
Конектори, стрім‑процесори, дебаг‑утиліти та будь‑які засоби інспекції Kafka‑даних бачать чистий payload без префікса. Це спрощує аналіз, налагодження та побудову конекторів до сторонніх систем. -
Портативність схем
GUID, який представляє повне визначення схеми, включно з референсами та метаданими, потенційно легше використовувати в різних реєстрах і середовищах, ніж локальний числовий ID.
Що змінюється насправді — і що ні
Попри значущі наслідки для інтеграції, сама зміна досить локальна:
-
Kafka як платформа не змінюється
Підтримка headers у Kafka вже існує. Новий підхід — це лише новий wire‑format у Confluent Serializers, а не зміна брокера чи протоколу Kafka. -
Потрібні оновлені бібліотеки
Новий формат працює на будь‑якому Kafka‑кластері, але тільки за умови, що продюсери й консюмери використовують оновлені бібліотеки Confluent Schema Registry, які вміють читати/писати схему в заголовках. -
Схеми та реєстр залишаються тими самими
Використовується той самий Schema Registry, ті ж самі схеми. Змінюється лише місце, де зберігається посилання на схему: headers замість payload.
У підсумку це невелике технічне коригування відкриває шлях до більш чистої моделі даних у Kafka, де payload залишається прозорим для будь‑яких інструментів, а керування схемами не нав’язує власний формат усім учасникам екосистеми.