Репортаж от Wedoany,Компания Confluent официально представила обновление для Apache Kafka, которое переносит хранение идентификатора схемы (schema ID) из тела сообщения в его заголовки, чтобы упростить процессы управления данными.
В традиционных развертываниях Kafka идентификатор схемы встраивается непосредственно в тело сообщения. Хотя это гарантирует правильную десериализацию событий потребителями, такой подход приводит к тесной связи метаданных схемы с самими данными. В среде, где несколько команд потребляют один и тот же поток событий, это увеличивает сложность эволюции схемы и накладные расходы на координацию.
Новое решение помещает идентификатор схемы в заголовки записей Kafka, оставляя тело сообщения неизменным. Во время выполнения потребитель использует идентификатор из заголовка для получения соответствующей схемы из Confluent Schema Registry (реестра схем). Этот метод совместим с различными форматами, такими как Avro, Protobuf и JSON Schema, одновременно снижая зависимость от тесно связанных линейных форматов, делая потоки событий более гибкими и упрощая их интеграцию в нижестоящие системы.

Патрик Нефф (Patrick Neff), руководитель команды CSTA компании Confluent (регион CEMEA), в своей публикации в LinkedIn отметил, что управление схемами играет ключевую роль в содействии повторному использованию данных между потоковыми и аналитическими системами и является важным фактором для раскрытия всей ценности данных.
Подход, основанный на заголовках, поддерживает поэтапное внедрение. Команды могут внедрить управление схемами без необходимости масштабной переработки или координации всех производителей и потребителей. Идентификатор схемы может быть добавлен к существующим потокам событий, что позволяет командам постепенно внедрять более строгие практики управления схемами, сохраняя при этом обратную совместимость.
Гуннар Морлинг (Gunnar Morling), технический эксперт Confluent, отмечает, что после переноса идентификатора схемы в заголовки сообщений тело становится независимым и самодостаточным, что значительно улучшает совместимость с системами хранения и нижестоящими фреймворками обработки, улучшая пользовательский опыт.
Отделение метаданных схемы от тела сообщения позволяет производителям и потребителям развиваться независимо друг от друга, а проверка сосредотачивается в Schema Registry, что снижает накладные расходы на координацию и упрощает эволюцию схемы в крупномасштабных средах. Этот шаг также способствует единообразному повторному использованию структурированных данных событий в различных конвейерах, повышая совместимость с такими инструментами, как Apache Flink, а также с аналитическими системами или системами машинного обучения.
Дэвид Араужо (David Araujo), директор по управлению продуктами Confluent, объясняет, что эта функция позволяет прикреплять схему к существующим данным в Kafka без изменения формата тела сообщения, обеспечивая модель внедрения с нулевым временем простоя и независимостью от клиента.
В некоторых сценариях миграции может потребоваться обновление коннекторов Kafka и нижестоящих инструментов, которые предполагают, что метаданные схемы встроены в тело сообщения, поэтому оба метода могут сосуществовать в течение некоторого времени. В настоящее время эта функция доступна в Confluent Cloud и, как ожидается, будет предоставлена в Confluent Platform (с поддержкой Schema Registry в рамках существующей модели лицензирования).
Данный материал скомпилирован платформой Wedoany. При цитировании материалов, созданных с помощью искусственного интеллекта (ИИ), необходимо обязательно указывать источник — «Wedoany». В случае выявления нарушения прав или иных проблем просим своевременно информировать нас. Сайт оперативно внесёт изменения или удалит материал.Электронная почта: news@wedoany.com









