[Документация Yandex Cloud](../../index.md) > [Yandex Managed Service for Apache Kafka®](../index.md) > [Концепции](index.md) > Управление схемами данных # Управление схемами данных Apache Kafka® использует бинарный формат для хранения и передачи сообщений. В сообщениях нет никакой информации об их структуре. Поэтому для интерпретации данных в бинарном формате потребителю нужно воспользоваться _схемой формата данных_ (format schema). Она описывает формат ввода или вывода данных. На основе схемы формата данных производитель формирует, а потребитель интерпретирует сообщения из топиков. Если схемы форматов данных [производителей и потребителей](producers-consumers.md) будут различаться, в работе приложения будут возникать ошибки из-за неправильной интерпретации сообщений. Разработчикам производителя и потребителя необходимо: * Своевременно обновлять схемы форматов данных. * Обеспечивать возможность работы производителя и потребителя сразу с несколькими версиями схем форматов данных, если это необходимо. Для автоматизации работы со схемами формата данных используется _реестр схем формата данных_. Он существенно упрощает работу с данными, особенно в случаях, когда схема меняется со временем. Реестр автоматически проверяет совместимость версий данных и обеспечивает обратную совместимость версий схем. ## Как работает реестр схем форматов данных {#how-sr-works} 1. Производитель передает схемы форматов данных в реестр. Поддерживаются следующие форматы схем данных: * [Avro](https://avro.apache.org/). * [JSON Schema](https://json-schema.org/). * [Protobuf](https://protobuf.dev/). При помещении схемы в реестр: * Ей присваивается уникальный номер версии. * Схема и ее версия сохраняются в служебном топике Apache Kafka®. 1. При отправке сообщения производитель указывает номер версии нужной схемы. 1. При получении сообщения потребитель извлекает из него номер версии схемы формата данных. 1. Если нужной схемы формата данных нет в локальном кеше, потребитель обращается за ней в реестр. Получив нужную схему, он корректно интерпретирует полученное сообщение. ## Managed Schema Registry {#msr} В кластер Managed Service for Apache Kafka® уже интегрирован реестр схем формата данных Managed Schema Registry. Реестр разворачивается на каждом хосте-брокере кластера и доступен по протоколу HTTPS на порте 443. В качестве реализации Managed Schema Registry используется приложение с открытым исходным кодом [Karapace](https://github.com/Aiven-Open/karapace). [API](../../glossary/rest-api.md) Karapace совместимо с [API Confluent Schema Registry](https://docs.confluent.io/platform/current/schema-registry/develop/api.html) за исключением небольших расхождений. Для выполнения запросов необходима [авторизация](#msr-auth). Karapace разворачивается на каждом хосте-брокере на отдельном порте, при этом ему доступен собственный эндпоинт для подключения. При удалении брокера соответствующий эндпоинт становится недоступен. Сведения о схемах помещаются в [служебный топик](topics.md#service-topics) `__schema_registry`. В этот топик нельзя писать данные стандартными средствами. Чтобы воспользоваться этим реестром, включите соответствующую опцию при [создании](../operations/cluster-create.md) или [обновлении](../operations/cluster-update.md#change-additional-settings) кластера. Для работы с Managed Schema Registry требуется дополнительная [настройка групп безопасности](../operations/connect/index.md#configuring-security-groups). ### Субъекты в Managed Schema Registry {#subjects} Для схем используются _субъекты_ ([subjects](https://docs.confluent.io/platform/current/schema-registry/develop/api.html#subjects)) — названия, под которыми регистрируются схемы. Для записи и чтения схем Apache Kafka® использует субъекты `<название_топика>-key` или `<название_топика>-value` в зависимости от того, регистрируется ли схема для ключа или значения. В субъекте указывается топик, в который публикуются сообщения. Доступ к субъектам зависит от прав, [выданных](../operations/cluster-accounts.md#grant-permission) пользователю Apache Kafka®: * Если пользователю назначена роль `ACCESS_ROLE_SCHEMA_READER` или `ACCESS_ROLE_SCHEMA_WRITER` на конкретные субъекты, он может управлять только этими субъектами. * Если пользователю назначена роль `ACCESS_ROLE_CONSUMER` или `ACCESS_ROLE_PRODUCER` на конкретный топик, пользователь может управлять субъектами `<название_топика>-key`, `<название_топика>-value` и `<название_топика>`. * Если пользователю назначена роль `ACCESS_ROLE_CONSUMER` или `ACCESS_ROLE_PRODUCER` на топик вида `<префикс>*`, пользователь может управлять субъектами такого же вида `<префикс>*`. Названия топиков и субъектов начинаются с одинакового префикса. * Если пользователю назначена роль `ACCESS_ROLE_TOPIC_ADMIN` на топик вида `<префикс>*`, пользователь может управлять субъектами такого же вида `<префикс>*`. Названия топиков и субъектов начинаются с одинакового префикса. * Если пользователю назначена роль `ACCESS_ROLE_ADMIN`, он может управлять всеми субъектами в кластере Managed Service for Apache Kafka®. [Подробнее](account-roles.md) о правах, которые предоставляет каждая роль. ### Авторизация в Managed Schema Registry {#msr-auth} При работе с API Managed Schema Registry через SSL-соединение необходимо настроить тот же клиентский [SSL-сертификат](../operations/connect/index.md#get-ssl-cert), что и для подключения к хостам-брокерам. Также необходимо авторизовывать запросы к API-серверам с помощью [HTTP-заголовка](https://en.wikipedia.org/wiki/Basic_access_authentication) `Authorization`. В заголовке нужно указать [логин и пароль пользователя Apache Kafka®](../operations/cluster-accounts.md#create-account). Возможность работы со схемами зависит от выбранного [способа управления топиками](topics.md#management) и настроенных ролей пользователя: 1. При использовании управляемых топиков: * Пользователю с ролью `ACCESS_ROLE_PRODUCER` для топика доступны любые операции над субъектами, связанными с этим топиком. * Пользователю с ролью `ACCESS_ROLE_CONSUMER` для топика доступны операции чтения над субъектами, связанными с этим топиком. Подробнее о том, какие субъекты доступны, в разделе [Субъекты в Managed Schema Registry](#subjects). 1. При использовании неуправляемых топиков: * Верно то же, что и для кластера с управляемыми топиками. * В дополнение к этому пользователю с ролью `ACCESS_ROLE_ADMIN` для топика доступны любые операции над субъектами, связанными с этим топиком. Для такого пользователя можно разрешить доступ к любым топикам. Подробнее о ролях в разделе [Управление пользователями](../operations/cluster-accounts.md). ### Примеры использования {#examples-msr} * [Управление схемами данных в Managed Service for Apache Kafka®](../tutorials/schema-registry-overview.md) * [Работа с управляемым реестром схем формата данных](../tutorials/managed-schema-registry.md) * [Работа с управляемым реестром схем формата данных с помощью REST API](../tutorials/managed-schema-registry-rest.md) ## Confluent Schema Registry {#confluent-sr} [Confluent Schema Registry](https://docs.confluent.io/platform/current/schema-registry/index.html) — один из вариантов программного обеспечения, решающий проблему синхронизации схем форматов данных между производителями и потребителями. Confluent Schema Registry помещает схемы форматов данных на хранение в служебный топик Apache Kafka® с именем `_schemas`. Подробнее о работе реестра в [документации Confluent](https://docs.confluent.io/platform/current/schema-registry/index.html). ### Примеры использования {#examples-confluent} * [Управление схемами данных в Managed Service for Apache Kafka®](../tutorials/schema-registry-overview.md) * [Использование Confluent Schema Registry с Managed Service for Apache Kafka®](../tutorials/confluent-schema-registry.md)