Evolução de esquemas com Avro e Parquet: esquemas de leitor e de escritor, arquivos mesclados e modos de compatibilidade

O que é

Os leitores precisam lidar com registros gravados sob outra versão do esquema. A especificação do Avro (citada) resolve o esquema do escritor, que viaja junto com os dados, contra o esquema do leitor, aquele que a aplicação espera. Os campos de um registro são associados pelo nome, e a ordem não importa; um campo do escritor que não existe no leitor é ignorado; um campo do leitor que não existe no escritor recebe o valor padrão do leitor, e, se não houver valor padrão, é sinalizado um erro. As promoções de tipo valem em um só sentido (int para long, float ou double; long para float ou double; float para double); string e bytes são intercambiáveis. O Parquet não tem etapa de resolução: cada arquivo carrega o próprio esquema, e a documentação do Spark (citada) descreve a mesclagem dos esquemas de arquivos que diferem entre si, mas são mutuamente compatíveis; ela vem desativada por padrão, por ser uma operação relativamente cara, e é ativada em cada leitura com mergeSchema. A documentação do Confluent Schema Registry (citada) nomeia os modos de compatibilidade que um registry pode impor: backward (consumidores que usam o novo esquema conseguem ler dados produzidos com o último esquema), forward (consumidores antigos leem dados novos), full (ambos) e as variantes transitivas, verificadas contra todas as versões anteriores; backward é o padrão porque permite que os consumidores voltem ao início de um tópico.

Por que importa

Um campo renomeado no produtor é, para um leitor cujo esquema não traz alias para o nome antigo, um campo excluído e outro adicionado (o Avro tem aliases de campo, mas a especificação torna o uso deles opcional); um campo adicionado sem valor padrão quebra todos os consumidores de dados antigos; um tipo alterado de int para string quebra a resolução. Essas falhas aparecem no momento da leitura, em consumidores que o autor do esquema talvez nem conheça.

Como aplicar

• Adicione campos como opcionais, com valor padrão (no Avro, uma union com null, com padrão null); nunca remova um campo que os consumidores ainda leem.
• Trate uma renomeação como adicionar e depois remover, ao longo de duas versões, gravando os dois campos nesse intervalo, a menos que todos os leitores respeitem aliases.
• Mantenha estáveis os nomes das colunas do Parquet e confie em nomes, não em posições; ative a mesclagem de esquemas apenas nas leituras que precisam dela e registre o esquema atual no catálogo de tabelas.
• Escolha o modo de compatibilidade conforme a ordem de implantação: backward quando os consumidores são implantados primeiro, forward quando são os produtores, full para qualquer uma das ordens.
• Para uma mudança incompatível, crie um novo subject, tópico ou versão de tabela e grave nos dois enquanto existirem leitores antigos.

Armadilhas

Um valor padrão do Avro deve ser um valor permitido pelo esquema do campo; no caso de uma union, deve corresponder a um dos ramos da union. Um símbolo de enum desconhecido pelo leitor é um erro, a menos que o enum do leitor tenha um valor padrão. Arquivos Parquet de ferramentas diferentes podem divergir quanto aos tipos lógicos (timestamps, decimais), mesmo quando os tipos físicos coincidem.

Qual modo de compatibilidade impõe qual regra

Um registry impõe apenas a direção que o nome do modo indica. BACKWARD (o padrão do Confluent) verifica se um novo esquema de consumidor lê dados antigos; ele permite excluir campos e adicionar campos com valor padrão, portanto registrará um esquema de produtor que remove um campo que consumidores antigos ainda leem. FORWARD verifica se consumidores antigos leem dados novos; ele permite adicionar campos e excluir apenas os opcionais. FULL verifica as duas direções, e as variantes transitivas verificam contra todas as versões anteriores, em vez de apenas a última. Escolha o modo conforme quem é implantado primeiro: consumidores primeiro, BACKWARD; produtores primeiro, FORWARD; consumidores desconhecidos ou numerosos, FULL. A regra "nunca remover um campo que os consumidores ainda leem" só é imposta pelo registry sob FORWARD ou FULL.