Como gerenciar a mudança de esquema com o Apache Pulsar

Os esquemas são uma parte essencial de qualquer plataforma de dados. Eles são metadados que definem a forma dos dados e os nomes e tipos de dados das propriedades. Os esquemas são úteis de duas maneiras. Primeiro, eles fornecem um esquema fixo para o formato de dados, o que pode impedir que dados mal formados sejam usados no contexto do esquema. Em segundo lugar, os esquemas permitem que os usuários entendam como analisar os dados e o que esperar de suas propriedades.

O Apache Pulsar é um sistema de mensagens distribuído de publicação-assinatura (pub-sub) de código aberto que permite o transporte de dados de servidor para servidor usando esquema . As mensagens são enviadas por meio de tópicos, com o produtor colocando mensagens nesses tópicos para serem lidas pelo consumidor. Um usuário pode definir um esquema para um tópico armazenado no registro de esquema do Pulsar. Quando as mensagens são adicionadas ao tópico, o intermediário Pulsar verifica se a mensagem está de acordo com o esquema e garante que apenas mensagens válidas sejam enviadas. O esquema atua como um contrato entre o produtor e os consumidores, permitindo que ambas as partes conheçam o formato exato dos dados.

Com o tempo, conforme os aplicativos evoluem, pode ser que os dados produzidos pelo aplicativo também mudem. No entanto, as alterações de esquema podem afetar os consumidores downstream dos dados que esperam dados em um formato específico. Sem uma maneira de gerenciar esquemas entre produtores e consumidores, é difícil fazer alterações nos dados gravados nas mensagens ou eventos sem correr o risco de interromper os aplicativos downstream. Para evitar esse tipo de problema, o esquema das mensagens também deve evoluir à medida que novas propriedades são adicionadas e permitir que os consumidores entendam os dados nos formatos antigo e novo. Este conceito é conhecido como evolução do esquema e o Pulsar o suporta.

Este artigo discute por que os esquemas evoluem antes de mergulhar em como o Pulsar implementa e suporta a evolução do esquema.

Por que os esquemas evoluem

Os esquemas fornecem contexto sobre os dados brutos. Freqüentemente, eles descrevem uma entidade específica em um sistema, abrangendo todas as propriedades dessa entidade. Por exemplo, você pode ter um aplicativo que inscreve usuários. Ele armazena detalhes do usuário, como nomes, endereços de e-mail e idades. Haveria um esquema de usuário que descreve os dados subjacentes e fornece contexto, como o nome do campo e o tipo de dados nele. O esquema pode ter a seguinte aparência:

Agora, digamos que você queira expandir os dados capturados para incluir dados de endereço e oferecer suporte a mala direta para os usuários. Você precisaria expandir o esquema para incluir os novos campos para capturar endereços, como a primeira linha do endereço, cidade e CEP. Depois de incluir esses novos campos, o esquema ficará assim:

Esta é uma forma simples de evolução do esquema, pois os campos originais não foram alterados e apenas novos campos foram adicionados. Na maioria dos casos, isso não deve ser uma mudança significativa para os consumidores downstream, pois os consumidores podem continuar como se os novos campos estivessem ausentes. Os consumidores precisariam apenas estar atualizados para consumir e usar as novas propriedades.

No entanto, às vezes, os campos existentes precisam ser corrigidos para oferecer suporte a novas funcionalidades. Por exemplo, diga que os usuários se sentiram desconfortáveis em fornecer uma idade exata e, em vez disso, você altera o aplicativo para capturar faixas etárias como 18-24, 25-39,40-49 e 60+. A coluna de idade precisaria que seu tipo de dados fosse alterado de inteiro para string.

Essa é uma evolução de esquema mais complexa, pois pode interromper os consumidores downstream que estão processando a propriedade age e esperando que seja um número ou analisando o número usando uma linguagem estritamente tipada como Java. Eles também poderiam realizar cálculos numéricos na propriedade, que não funcionariam mais em seu novo formato.

Para superar esse desafio, as plataformas de dados podem oferecer suporte à evolução do esquema para lidar com cenários como esse. A Pulsar reconhece a importância do esquema para o processamento de dados; na verdade, ele o trata como um cidadão de primeira classe, incluindo suporte integrado à evolução do esquema. Vejamos como o Pulsar faz isso.

Como o Pulsar suporta a evolução do esquema

O Pulsar define esquemas em uma estrutura de dados chamada `SchemaInfo`. Esta é uma estrutura de dados específica do Pulsar, que é em si um esquema, que descreve o esquema de mensagens transportadas via Pulsar. Cada `SchemaInfo` pertence a um tópico (canal de mensagens) e descreve as mensagens a serem produzidas e consumidas usando esse tópico.

Cada `SchemaInfo` tem um tipo que detalha o tipo de esquema que está sendo usado. Isso pode ser qualquer coisa, desde um número inteiro, uma string ou um esquema complexo, como Avro ou Protobuf.

Suportar evolução do esquema , o Pulsar usa verificações de compatibilidade de esquema para comparar um esquema recebido com o(s) esquema(s) conhecido(s) de um tópico. As verificações de compatibilidade de esquema ocorrem quando um produtor ou consumidor tenta se conectar a um determinado tópico. A estratégia é escolhida durante a configuração do broker, com o valor `schemaCompatibilityStrategy`. O objetivo é verificar o `SchemaInfo` fornecido pelo cliente conectado com o `SchemaInfo` existente para ver se eles são compatíveis.

O Pulsar suporta oito tipos diferentes de estratégias de compatibilidade de esquema , que você pode definir com base nos requisitos da mudança. Essas estratégias também vêm com regras descrevendo quais mudanças podem ser feitas e indicadores sobre quais clientes devem ser atualizados primeiro. (Confira a documentação do link acima para uma explicação mais detalhada de cada estratégia de compatibilidade).

Voltando aos exemplos anteriores, vamos implementar as alterações de esquema usando a estratégia de compatibilidade do Pulsar. Primeiro, comece com o esquema de usuário inicial (sem o endereço).

Esta será a V1 do seu esquema. Portanto, quando você implementar um produtor ou consumidor Pulsar pela primeira vez, o `SchemaInfo` para esta versão será armazenado e o produtor e o consumidor funcionarão conforme o esperado.

Em seguida, você deseja adicionar os novos campos de endereço ao seu esquema de usuário. O primeiro passo é consultar as estratégias de compatibilidade de esquemas e determinar qual é a melhor para esta mudança. Usando a coluna “alterações permitidas” na documentação, você está procurando por qualquer estratégia que permita a adição de novos campos. Isso fornece BACKWARD, BACKWARD_TRANSITIVE, FORWARD e FORWARD_TRANSITIVE.

BACKWARD deve ser usado quando não há garantia de que os consumidores que usam uma versão mais antiga possam entender o novo esquema. FORWARD é usado quando os consumidores na versão mais recente do esquema podem não conseguir ler dados em versões mais antigas. Se você deseja atualizar todos os consumidores primeiro para usar o novo esquema, use uma estratégia BACKWARD. Caso contrário, FORWARD é melhor.

Olhando para o quadro maior, Pulsar refere-se a todo o ato de desenvolver o esquema de um tópico como verificação de esquema . É a combinação de um produtor ou consumidor fornecendo `SchemaInfo`, a estratégia de compatibilidade escolhida para o tópico e o corretor decidindo o que fazer.

Conclusão

É raro os esquemas permanecerem os mesmos para sempre. À medida que novos recursos são introduzidos nos aplicativos, os esquemas geralmente precisam evoluir para oferecer suporte a esses recursos. No entanto, manter os produtores e consumidores de dados sincronizados geralmente pode ser um desafio quando os esquemas são modificados.

Os conceitos de evolução de esquema integrados do Pulsar ajudam a lidar com essas mudanças. Usando estratégias de compatibilidade de esquema, ele pode definir as regras de quão diferentes são as versões compatíveis de um esquema. O Pulsar usa isso em conjunto com um processo de verificação de esquema que usa essas regras para determinar quais esquemas podem ser usados por um consumidor ao se conectar a um tópico específico.

Também publicado aqui.