O que é um registro de esquemas?

Definição de registro de esquemas

Um registro de esquemas é um serviço centralizado que armazena, gerencia e valida os esquemas usados para serializar e desserializar os dados trocados por meio do Apache Kafka. Em vez de deixar que cada aplicação produtora ou consumidora defina por conta própria os formatos de mensagem, esse serviço oferece uma “fonte da verdade” compartilhada sobre a estrutura dos dados de eventos.

No Kafka, os eventos costumam ser serializados em formatos como Apache Avro, JSON Schema ou Protocol Buffers, formato muitas vezes abreviado para protobuf. O registro de esquemas armazena as definições desses formatos e atribui a cada esquema um identificador exclusivo. Esse identificador é chamado de ID do esquema.

Ao gravar uma mensagem em um tópico do Kafka, o produtor normalmente inclui o ID do esquema junto com os dados serializados, em vez de embutir o esquema completo em cada mensagem. Depois, os consumidores das mensagens buscam no registro o esquema correspondente e o usam para desserializar e interpretar os dados corretamente.

Por que um registro de esquemas é importante?

Um registro de esquemas é importante em um sistema baseado em eventos porque ajuda a garantir que produtores e consumidores estejam de acordo quanto à estrutura dos dados trocados. Esse alinhamento contribui para a qualidade e a integridade dos dados.

Sem um registro centralizado, as aplicações precisariam gerenciar os esquemas de mensagem de forma independente. Esse cenário aumenta o risco de alterações incompatíveis, que poderiam levar os consumidores de eventos a falhar ou a interpretar os dados incorretamente.

O registro de esquemas também permite a chamada evolução de esquemas. Com ela, os desenvolvedores podem modificar as estruturas de eventos ao longo do tempo sem perder a compatibilidade com as aplicações existentes.

Por exemplo, muitas vezes é possível adicionar um novo campo opcional sem quebrar o formato esperado pelos consumidores atuais do Kafka. As regras de compatibilidade ajudam a garantir que as alterações de esquema sejam seguras antes de serem implementadas.

Registros de esquemas e governança de dados

Outro benefício importante é a melhoria da governança de dados. Os esquemas ficam armazenados em um repositório central, o que permite que as organizações documentem, revisem, versionem e auditem a estrutura dos dados de eventos.

Com essa abordagem, fica mais fácil para as equipes de desenvolvimento:

  • descobrir os tipos de evento disponíveis;
  • entender os formatos de dados;
  • revisar as versões dos esquemas;
  • manter a consistência entre sistemas distribuídos.

Nas plataformas de dados modernas, o registro de esquemas também pode viabilizar contratos de dados entre produtores e consumidores do Kafka. Esses contratos definem não só a estrutura dos dados, mas também as expectativas sobre como eles devem evoluir com o tempo.

Ao validar as alterações de esquema antes da publicação, o registro de esquemas ajuda a impedir que alterações incompatíveis cheguem à produção e aumenta a confiabilidade das arquiteturas orientadas a eventos.

O que um registro de esquemas pode gerenciar?

Um registro de esquemas oferece um mecanismo centralizado para gerenciar esquemas de eventos, garantir a compatibilidade entre eles e permitir que sejam alterados.

Com o registro, os desenvolvedores também podem padronizar os nomes de eventos com uma estratégia de nomes de assunto e criar novos esquemas a partir de outros mais antigos, o que dá aos esquemas uma composição estruturada.

Esses métodos ajudam as aplicações a trocar dados à medida que os sistemas e os requisitos mudam.

Como funciona um registro de esquemas

Um registro de esquemas armazena e gerencia os esquemas que definem a estrutura dos dados de eventos trocados entre produtores e consumidores. Quando um produtor envia dados para um tópico do Kafka, ele serializa a mensagem de acordo com um esquema registrado e inclui informações que permitem identificar o esquema correspondente. O consumidor pode então usar esse esquema para desserializar e interpretar corretamente o que recebe. À medida que os esquemas mudam com o tempo, o registro também pode verificar a compatibilidade das novas versões do esquema antes que sejam registradas, o que ajuda produtores e consumidores a continuar trabalhando com estruturas de dados em evolução.

Exemplo: registro de esquemas na prática

Imagine um grande varejista online com vários sistemas que geram e consomem dados: um site de e-commerce, um aplicativo móvel, um mecanismo de recomendação, um sistema de gestão de estoque, uma plataforma de logística e uma plataforma de análise de clientes. Cada um desses sistemas se comunica publicando e consumindo eventos em clusters do Apache Kafka no Confluent Cloud e, no pipeline de dados, transmite esses eventos a um data warehouse por meio do Kafka Connect.

Toda ação no site gera vários eventos nos sistemas do varejista. Sempre que um cliente faz um pedido, o site publica um evento OrderCreated em um tópico do Kafka.

Várias aplicações consomem esse mesmo evento. O sistema de estoque reserva os itens comprados, o sistema de pagamento confirma a transação e o armazém inicia a separação e o envio do pedido. O mecanismo de recomendação atualiza as preferências do comprador, a plataforma de análise contabiliza a venda e o serviço de notificação ao cliente envia uma confirmação por e-mail.

De início, o evento OrderCreated contém campos como order_id , customer_id , product_id , quantity e total_price . Todas as aplicações consumidoras foram desenvolvidas para trabalhar com essa estrutura.

Agora imagine que, meses depois, a empresa decide começar a vender para o exterior. Os desenvolvedores atualizam o site para que cada pedido passe a incluir dois campos novos: currency e exchange_rate .

Sem um registro de esquemas, não há um mecanismo centralizado para coordenar essa alteração. Alguns consumidores de dados de eventos esperam os campos novos, e outros não. Se um desenvolvedor renomear por engano o campo total_price para order_total ou mudar o tipo de dado desse campo de decimal para string, os serviços que dependem do evento podem começar a falhar de forma inesperada. O armazém pode deixar de receber pedidos, os dashboards de análise podem gerar relatórios incorretos ou as notificações aos clientes podem falhar por não conseguirem interpretar o evento.

Como ficaria, então, esse mesmo cenário com o Confluent Schema Registry para ajudar no gerenciamento de esquemas?

Antes de implementar o produtor atualizado, a equipe de desenvolvimento registra uma nova versão do esquema OrderCreated . Essa etapa gera um novo ID do esquema, associado a essa versão. O registro de esquemas compara as alterações propostas com as configurações de compatibilidade da organização.

Se as mudanças atenderem a essas regras de compatibilidade, a nova versão do esquema pode ser registrada. Se uma alteração violar a política de compatibilidade configurada, o registro pode recusar essa mudança antes que as aplicações comecem a usar o esquema incompatível.

Isso significa que os desenvolvedores podem identificar uma alteração de esquema incompatível durante o desenvolvimento, e não depois da implementação. Os consumidores atuais podem continuar funcionando com as alterações compatíveis, enquanto as equipes de desenvolvimento atualizam aos poucos as aplicações para usar os campos novos quando estiverem prontas.

Gerenciamento de esquemas em escala

Os benefícios de um registro de esquemas ganham importância à medida que a empresa cresce. Centenas de aplicações desenvolvidas por dezenas de equipes de engenharia podem trocar dados por meio de milhares de tipos de evento diferentes.

Na ausência de um registro de esquemas, cada equipe precisaria coordenar as alterações de esquema sem automação, com documentação manual, reuniões ou tentativa e erro. Esse processo manual pode atrasar o desenvolvimento e aumentar a probabilidade de que alterações incompatíveis cheguem à produção.

Com um registro de esquemas em funcionamento, os esquemas de eventos passam a ser ativos gerenciados de forma centralizada. Os produtores podem publicar dados de acordo com os esquemas registrados, os consumidores podem usar essas definições de esquema para interpretar os eventos recebidos e as verificações de compatibilidade conseguem identificar alterações de esquema incompatíveis.

Equipes recém-chegadas também podem encontrar as definições de eventos já existentes em vez de fazer engenharia reversa dos formatos de mensagem, o que facilita criar aplicações e integrar sistemas novos.

Conforme o varejista escala, o registro de esquemas oferece uma forma centralizada de gerenciar esquemas de eventos em evolução entre produtores e consumidores.

Modos de compatibilidade de esquemas

A compatibilidade de esquemas determina se aplicações que usam versões diferentes de um esquema podem continuar a trocar e interpretar dados corretamente à medida que os esquemas evoluem. Os principais modos de compatibilidade são a compatibilidade com versões anteriores (backward), a compatibilidade com versões futuras (forward) e a compatibilidade total (full).

  • A compatibilidade com versões anteriores significa que um consumidor mais novo consegue ler dados gravados com um esquema mais antigo. Esse modo é útil quando os consumidores são atualizados depois dos produtores ou quando as aplicações precisam continuar processando dados históricos gravados com versões anteriores do esquema.
  • A compatibilidade com versões futuras significa que um consumidor mais antigo consegue ler dados gravados com um esquema mais novo. Esse modo pode ser importante quando os produtores são atualizados antes de todos os consumidores e as aplicações mais antigas precisam continuar processando os eventos recém-produzidos.
  • A compatibilidade total reúne a compatibilidade com versões anteriores e a compatibilidade com versões futuras; por isso, as alterações de esquema precisam continuar compatíveis nos dois sentidos.

Alguns registros de esquemas também oferecem versões transitivas desses modos de compatibilidade. Em vez de confrontar uma nova versão do esquema apenas com a versão imediatamente anterior, as verificações de compatibilidade transitiva a comparam com todas as versões precedentes relevantes. As regras exatas de compatibilidade e as alterações de esquema permitidas dependem do formato do esquema e das configurações de compatibilidade do registro.

Exemplo: compatibilidade com versões futuras na prática

A compatibilidade com versões futuras é útil quando produtores mais antigos precisam continuar em operação enquanto consumidores mais novos têm de processar, sem interrupção, os dados vindos desses produtores. Nessa situação, a prioridade é garantir que as aplicações recém-implementadas continuem compatíveis com as mensagens ainda geradas por versões mais antigas do software produtor.

Imagine uma concessionária de energia de abrangência nacional que opera uma rede elétrica inteligente. Essa rede é formada por milhões de medidores inteligentes instalados em residências e empresas. Cada medidor publica eventos de consumo de energia elétrica no Apache Kafka. Esses equipamentos permanecem em uso por anos e só podem receber atualizações de firmware em janelas de manutenção programadas. Isso significa que muitos medidores continuam produzindo eventos com um esquema mais antigo bem depois do lançamento de versões mais novas do software.

Enquanto isso, a concessionária atualiza com regularidade as aplicações centrais de monitoramento e análise. Uma nova versão da plataforma de análise passa a aceitar informações adicionais, como métricas de qualidade de energia e geração de energia renovável. Esses novos campos são úteis quando disponíveis, mas a plataforma precisa continuar processando os dados dos medidores mais antigos que não os enviam.

Nesse cenário, a compatibilidade com versões futuras é mais importante do que a compatibilidade com uma versão anterior, porque os consumidores são atualizados primeiro, enquanto muitos produtores permanecem em versões mais antigas do esquema. O novo software consumidor precisa ler corretamente os eventos gravados com esquemas mais antigos, mesmo que esses eventos não tragam os campos recém-introduzidos. A aplicação pode tratar os campos ausentes como opcionais ou atribuir valores padrão a eles, enquanto continua a cumprir suas funções principais.

Se, em vez disso, a principal preocupação fosse a compatibilidade com versões anteriores, os desenvolvedores se concentrariam em garantir que consumidores mais novos conseguissem ler dados gravados com esquemas de produtores mais antigos. No entanto, o desafio imediato da organização é manter em operação um parque de dispositivos antigos de longa vida útil enquanto moderniza os sistemas centrais de processamento.

Com um registro de esquemas e regras de compatibilidade adequadas, a concessionária consegue fazer seus esquemas de eventos evoluírem sem exigir atualizações simultâneas de firmware em milhões de medidores instalados. Essa abordagem viabiliza uma implementação gradual, em que produtores e consumidores podem ser atualizados em momentos diferentes sem deixar de atender aos requisitos de compatibilidade definidos pela organização.

Registros de esquemas e governança

Um registro de esquemas pode apoiar os esforços de conformidade com regulamentações de privacidade de dados, como o Regulamento Geral de Proteção de Dados (GDPR) e a Lei de Privacidade do Consumidor da Califórnia (CCPA).

Embora um registro de esquemas não garanta, por si só, a conformidade, ele pode ajudar as organizações a adotar práticas de governança de dados, de consistência e de auditoria usadas para cumprir requisitos regulatórios.

Visibilidade das estruturas de dados

Um dos principais benefícios é a maior visibilidade dos dados em processamento.

Cada esquema de evento fica armazenado em um repositório centralizado, que documenta os campos que o compõem. Esse repositório funciona como fonte de informações sobre quais dados existem, o que cada campo representa e como as aplicações estruturam os dados que produzem ou consomem.

Essa visibilidade ajuda as organizações a identificar esquemas que contêm informações de identificação pessoal (PII), como nomes, endereços de e-mail ou números de conta.

Revisão de esquemas e minimização de dados

Um registro de esquemas também pode contribuir para a minimização de dados, um dos princípios do GDPR.

Antes da aprovação de um esquema, os desenvolvedores e as equipes de governança de dados podem avaliar se cada campo é necessário para a finalidade de negócio pretendida. Essa etapa de revisão ajuda a evitar que as aplicações coletem ou compartilhem informações pessoais desnecessárias.

A validação de esquemas também ajuda a evitar alterações não autorizadas ou acidentais que introduzam novos dados sensíveis nos sistemas de produção.

Por exemplo, se um desenvolvedor tentar adicionar o número do Seguro Social ou da carteira de motorista de um cliente a um evento do Kafka já existente, o esquema proposto pode ser revisado antes de ser implementado.

Essa abordagem cria um ponto de controle de governança adicional, que se soma aos testes habituais das aplicações.

Versionamento e auditoria de esquemas

O versionamento e o histórico de esquemas oferecem recursos de auditoria.

Cada evolução de esquema fica documentada, o que permite às organizações saber quando os campos foram adicionados, modificados ou removidos.

Durante uma auditoria de conformidade, esse histórico ajuda a comprovar que as estruturas de dados são gerenciadas de forma controlada e rastreável.

Consistência entre sistemas

Um registro de esquemas também pode melhorar a consistência entre vários sistemas.

Como produtores e consumidores se baseiam em definições de esquema compartilhadas, as aplicações conseguem interpretar os campos segundo uma estrutura comum.

Assim, é possível reduzir inconsistências no tratamento dos dados de uma aplicação para outra.

Contratos de dados e metadados

Muitas organizações usam um registro de esquemas ao implementar contratos de dados.

Esses contratos definem não só a estrutura de um evento, mas também metadados sobre os dados que ele contém.

  • Um contrato de dados pode identificar:
  • quais campos contêm PII;
  • se determinados campos têm requisitos de segurança;
  • quem tem autorização para consumir dados específicos;
  • por quanto tempo os dados devem ser retidos.

A validação automatizada pode então verificar se as novas versões do esquema continuam a atender aos requisitos definidos.

Registros de esquemas e ferramentas mais amplas de governança

Os registros de esquemas também podem se integrar a ferramentas mais amplas de governança de dados e de segurança.

Os metadados armazenados junto com os esquemas podem ser usados, por exemplo, por:

  • Catálogos de dados
  • sistemas de controle de acesso;
  • ferramentas de rastreamento de linhagem de dados;
  • plataformas de conformidade.

Portanto, um registro de esquemas pode ser um dos componentes de uma arquitetura de governança mais abrangente.

Aliado à criptografia, aos controles de acesso, às políticas de retenção de dados e aos logs de auditoria, o gerenciamento de esquemas pode ajudar as organizações a controlar como os dados pessoais são coletados, processados e compartilhados.

Serviços que oferecem registro de esquemas

Várias plataformas oferecem recursos de registro de esquemas para o Kafka e para sistemas de dados relacionados.

Confluent Schema Registry

O Confluent Schema Registry é um registro de esquemas amplamente usado, específico para o Kafka.

Ele faz parte do sistema da Confluent e está disponível tanto como componente autogerenciado da Confluent Platform quanto como serviço gerenciado no Confluent Cloud.

Esse registro é compatível com Avro, Protobuf e JSON Schema e oferece versionamento de esquemas, regras de compatibilidade, validação e integração com produtores e consumidores do Kafka.

AWS Glue Schema Registry

A Amazon Web Services disponibiliza o AWS Glue Schema Registry.

Trata-se de um registro de esquemas gerenciado que se integra ao Apache Kafka, ao Amazon Managed Streaming for Apache Kafka (MSK), ao Amazon Kinesis, ao Amazon Managed Service for Apache Flink e ao AWS Lambda.

Ele é compatível com Avro, JSON Schema e Protobuf.

Apicurio Registry

O Apicurio Registry, de código aberto, é um registro de esquemas e artefatos de API que pode ser usado com o Kafka.

Esse registro é compatível com formatos como Avro, JSON Schema e Protobuf e pode ser implementado em ambientes como o Kubernetes.

O Apicurio também é compatível com a API do Confluent Schema Registry, o que pode facilitar seu uso com aplicações do Kafka desenvolvidas para as interfaces de registro de esquemas da Confluent.

Redpanda Schema Registry

O Redpanda também inclui, como parte da sua plataforma de fluxo de dados compatível com o Kafka, um serviço compatível com o Schema Registry.

Essa abordagem pode ser útil quando a organização usa o Redpanda, e não o Apache Kafka diretamente, já que a própria plataforma de fluxo de dados pode oferecer o gerenciamento de esquemas.

O registro do Redpanda está mais estreitamente integrado a uma plataforma alternativa de fluxo de dados compatível com o Kafka.

Perguntas frequentes

O registro de esquemas faz parte do Apache Kafka?

Não, o registro de esquemas não faz parte do núcleo do Apache Kafka. O Kafka armazena e transporta mensagens. O registro de esquemas é um serviço à parte, que armazena e gerencia os esquemas dos dados contidos nessas mensagens. Os registros de esquemas costumam ser usados junto com o Kafka para ajudar produtores e consumidores a interpretar de forma consistente os dados de eventos estruturados.

Qual é a diferença entre ID do esquema e versão do esquema?

O ID do esquema é um identificador de uma definição de esquema específica. A versão do esquema indica a posição desse esquema na sequência de versões mantidas para determinado esquema ou assunto. A implementação exata varia conforme o registro. No Confluent Schema Registry, por exemplo, o ID do esquema identifica o esquema de forma exclusiva dentro do registro, enquanto a versão pertence a um assunto. Por isso, um mesmo esquema pode manter um único ID e, ainda assim, estar associado a versões diferentes em assuntos distintos.

Qual é a diferença entre registro de esquemas e catálogo de dados?

O registro de esquemas armazena e gerencia principalmente esquemas legíveis por máquina, que as aplicações usam para entender a estrutura dos dados. O registro também pode oferecer recursos como o versionamento de esquemas e as verificações de compatibilidade.

Já o catálogo de dados tem um foco mais amplo: ajudar pessoas e sistemas a descobrir, entender e governar os ativos de dados de toda a organização. Um catálogo pode conter descrições de negócio, informações sobre os responsáveis pelos dados, classificações e outros metadados sobre conjuntos e sistemas de dados. Desse modo, registros de esquemas e catálogos de dados podem se complementar. O registro gerencia os esquemas usados pelas aplicações, enquanto o catálogo oferece informações mais amplas sobre os ativos de dados da organização.

Qual é a diferença entre esquema e contrato de dados?

Um esquema define a estrutura dos dados, incluindo elementos como campos e tipos de dados. Um contrato de dados pode incluir o esquema, mas também definir expectativas mais amplas entre os produtores e os consumidores de dados. O esquema pode ser um dos componentes de um contrato de dados, ao lado de restrições de integridade, metadados e políticas.

Como as organizações escolhem um registro de esquemas?

O registro de esquemas mais adequado depende dos requisitos técnicos da organização e da arquitetura de dados que ela já tem. Entre os fatores a considerar estão os formatos de esquema aceitos pelo registro, suas regras de compatibilidade, a integração com o Apache Kafka e outros sistemas de dados, a compatibilidade com APIs e clientes, os recursos de segurança e autenticação e se o serviço é gerenciado ou autogerenciado.

As organizações também podem avaliar como o registro lida com a evolução de esquemas, a governança de dados, os metadados e os contratos de dados, bem como sua compatibilidade com os produtores, consumidores e pipelines de dados já existentes. Cada produto de registro de esquemas oferece uma combinação diferente desses recursos; por isso, a escolha geralmente depende dos sistemas e dos requisitos que o registro precisa atender.

Autores

Joshua Noble

Data Scientist

Amanda McGrath

Staff Writer

IBM Think