Uma pesquisa recente da Gartner descobriu que a baixa qualidade de dados custa às organizações uma média de US$ 12,9 milhões anualmente e pode aumentar a complexidade dos ecossistemas de dados. "Dados ruins" são definidos como dados corrompidos ou malformados que não estão de acordo com as expectativas dos desenvolvedores. Eles podem criar interrupções e outros efeitos corruptores para cientistas de dados, analistas, aprendizado de máquina, IA e outros profissionais de dados.
Os tópicos do Apache Kafka são imutáveis. Uma vez que um evento é escrito em um fluxo de eventos, ele não pode ser editado ou excluído. Essa compensação de design garante que cada consumidor dos dados acabará com exatamente a mesma cópia e que nenhum dado será editado ou alterado após ter sido lido. No entanto, como dados ruins não podem ser editados depois de escritos no fluxo, é essencial evitar que dados ruins entrem no fluxo em primeiro lugar. No entanto, se dados ruins entrarem no fluxo, há algumas coisas que você pode fazer, mesmo que não possa editá-los no local.
Aqui estão quatro dicas para ajudar você a prevenir e corrigir efetivamente dados incorretos em fluxos de eventos.
1. Use esquemas para evitar a entrada de dados incorretos
Os esquemas definem explicitamente quais dados devem ou não estar no evento, incluindo nomes de campos, tipos, padrões, intervalos de valores aceitáveis e documentação legível por humanos. Tecnologias de esquema populares para fluxos de eventos incluem Avro, Protobuf e JSON Schema.
Os esquemas reduzem significativamente os erros de dados ao impedir que o produtor grave dados ruins. Se os dados não aderirem ao esquema, o aplicativo lançará uma exceção e informará o esquema. Os esquemas permitem que os consumidores se concentrem em usar os dados em vez de fazer tentativas de melhor esforço para analisar o significado real do produtor.
Esquemas explícitos fortemente definidos são importantes para garantir significado claro. É comum em um sistema orientado a eventos ter diferentes consumidores independentes lendo o mesmo tópico. Quanto mais consumidores e tópicos você tiver, maior a chance de eles interpretarem mal os dados em comparação com seus pares, a menos que você use esquemas explícitos claramente definidos.
O risco é que seus consumidores interpretem mal os dados de forma ligeiramente diferente uns dos outros, levando a cálculos e resultados que se desviam uns dos outros. Isso pode levar a esforços significativos para reconciliar qual sistema está interpretando mal os dados. Em vez disso, elimine essa possibilidade usando esquemas.
2. Teste seus esquemas com seus aplicativos
O teste é essencial para evitar que dados ruins entrem em seus fluxos. Embora uma exceção de tempo de execução do serviço de produção possa evitar que dados ruins entrem no fluxo, isso provavelmente degradará a experiência para outros aplicativos e usuários que dependem desse serviço.
Os esquemas fornecem tudo o que você precisa para simular dados de teste para testar seu código. Seus testes de serviço de produtor podem exercitar todos os seus caminhos de código para garantir que eles criem apenas eventos formatados corretamente. Enquanto isso, seus aplicativos de consumidor podem escrever toda a sua lógica de negócios e testes no mesmo esquema para que eles não gerem nenhuma exceção ou calculem incorretamente os resultados quando recebem e processam os eventos.
O teste integra-se ao seu pipeline de CI/CD para que você possa verificar se seu código e esquemas operam corretamente juntos antes de implantar seus aplicativos e serviços. Você também pode integrar seu pipeline de CI/CD para validar seus esquemas com os esquemas mais recentes no registro de esquemas para garantir que seu aplicativo seja compatível com todos os seus esquemas dependentes, caso você tenha perdido uma evolução ou atualização.
3. Priorize o design do evento
Apesar dos esforços para evitar que dados ruins entrem em um fluxo, às vezes um erro de digitação é tudo o que é preciso para corromper uma entrada. O design de eventos desempenha outro papel fundamental na prevenção de dados ruins em seus fluxos de eventos. Um design de eventos bem pensado pode permitir correções, como sobrescrever dados ruins anteriores publicando novos registros com os dados corretos. Priorizar o design de eventos cuidadoso e deliberado durante a fase de desenvolvimento do aplicativo pode aliviar significativamente os problemas relacionados à correção de dados ruins.
Eventos de estado (também conhecidos como transferências de estado carregadas por eventos) fornecem uma imagem completa da entidade em um dado ponto no tempo. Eventos delta fornecem apenas a mudança do evento delta anterior. A imagem a seguir mostra eventos delta como análogos aos movimentos em um jogo de xadrez, enquanto o evento de estado mostra o estado atual completo do tabuleiro. Eventos de estado podem simplificar o processo de correção de dados ruins publicados anteriormente. Você simplesmente publica um novo evento de estado com o estado correto atualizado. Então, você pode usar a compactação para excluir (de forma assíncrona) os dados antigos e incorretos. Cada consumidor receberá uma cópia do estado correto e poderá processar e inferir suas alterações comparando-as a qualquer estado anterior que eles possam ter armazenado em seu limite de domínio.
Embora os deltas forneçam um tamanho de evento menor, você não pode compactá-los. O melhor que você pode fazer é emitir um delta que desfaça um delta anterior, mas o problema é que todos os seus consumidores devem ser capazes de lidar com os eventos de reversão. O desafio é que há muitas maneiras de produzir deltas ruins (por exemplo, movimentos ilegais, um jogador movendo vários turnos seguidos), e cada evento de desfazer deve ser uma correção precisa. A realidade é que isso é muito difícil de fazer em qualquer escala significativa, e você ainda acaba com todos os dados ruins anteriores em seu fluxo de eventos; você simplesmente não pode limpá-los se escolher usar deltas.
O design de eventos permite retificar erros sem ter que apagar tudo e começar do zero. No entanto, apenas eventos de estado fornecem os meios para emitir uma correção (um novo evento com o estado fixo total) e apagar os dados ruins antigos (compactação).
4. Quando tudo mais falhar, rebobine, reconstrua e tente novamente
No mundo do streaming de dados, a prevenção é sempre melhor do que consertar. Como último recurso, esteja preparado para investigar o fluxo de eventos. Embora o processo possa ser aplicado a qualquer tópico com dados ruins — seja estadual, delta ou híbrido — ele é trabalhoso e fácil de bagunçar. Prossiga com cautela.
Reconstruir dados de uma fonte externa requer procurar os dados ruins e produzir um novo fluxo com os dados corrigidos. Você tem que voltar ao início do processo e pausar consumidores e produtores. Depois disso, você pode corrigir e reescrever os dados em outro fluxo para onde você eventualmente migrará todas as partes.
Embora essa solução cara e complexa deva ser o último recurso, é uma estratégia essencial para ter em seu arsenal.
Mitigar o impacto de dados ruins
Lidar com dados ruins em fluxos de eventos não precisa ser uma tarefa assustadora. Ao entender a natureza dos dados ruins, impedindo que eles entrem no seu fluxo de eventos, utilizando o design de eventos para sobrescrever dados ruins e estando preparado para retroceder, reconstruir e tentar novamente quando necessário, você pode efetivamente mitigar o impacto dos dados ruins. Boas práticas de dados não apenas economizam tempo e esforço, mas também permitem que você faça o trabalho.
