If You Can't Read It Why Eat It

O que significa e por que você deveria se importar

Se você já tentou processar arquivos CSV gerados por sistemas diferentes e descobriu que um usa vírgula como separador enquanto outro usa ponto e vírgula porque o autor decidiu seguir uma convenção totalmente arbitrária, então você já encontrou esse problema na prática. O princípio é simples: antes de ingerir qualquer dado, certifique-se de que consegue analisá-lo corretamente. Se o formato não for previsível ou legível, consuma apenas o que der para ler com confiança. Muitas pessoas tratam esse conceito como algo opcional, algo que você aplica quando sobra tempo. Na minha experiência, Ignorar essa etapa é o que quebra pipelines inteiros de processamento em produção. Eu já vi um script rodar silenciosamente por três semanas gerando relatórios errados porque alguém assumiu que os campos numéricos viriam sempre formatados com ponto decimal, e na verdade estavam usando vírgula em uma das fontes de dados conectadas.

if you can't read it why eat it

Esse princípio aparece principalmente em contextos de ETL, integrações entre sistemas e ingestão de dados de APIs mal documentadas. A aplicação prática é direta: crie camadas de validação na fronteira da entrada, não no meio do processamento. Validações tardias propagam dados corrompidos por várias etapas antes de qualquer erro aparecer, e aí a depuração vira uma busca por uma agulha num palheiro. Vou mostrar como eu estruturo isso no dia a dia. Primeiro eu defino o esquema esperado. Não é um documento bonito, é algo funcional: tipo de dado, obrigatoriedade, formato aceitável e limites. Depois eu escrevo o parser correspondente antes de mais nada, e só então conecto a fonte de dados. Se o parser falhar em capturar algo que parece válido, eu corrijo o parser, não o dado. Essa inversão de prioridade resolve a maioria dos problemas de integridade sem precisar de workarounds. A parte mais importante é lidar com bordas. Dados reais quase nunca são limpos. Campos vazios que deveriam ser nulos, datas com formatos misturados, números com espaços ocultos, textos codificados de formas diferentes. Tudo isso acontece. Eu costumo usar uma camada de normalização após a validação, onde transformo variações aceitáveis para um formato padrão antes de seguir em frente. Isso reduz drasticamente a quantidade de registros descartados sem necessidade.

Uma ferramenta que funciona bem para validar e transformar dados antes do processamento principal é o Pandas, especialmente combinado com bibliotecas como pydantic para definição de esquemas. Se o seu pipeline é mais pesado em escala, Apache Spark com validações schema-on-read também é uma opção sólida, embora a configuração inicial demande mais tempo. Um problema específico que eu encontrei recentemente envolveu arquivos JSON enviados por um parceiro comercial onde os campos numéricos vinham como strings com casas decimais variáveis em alguns registros e como números inteiros em outros. O código anterior simplesmente convertia tudo para float, o que quebrava em registros com strings vazias ou nulas disfarçadas. Minha solução foi criar um validador com pydantic que aceita string ou número, converte para Decimal com precisão fixa, e rejeita valores vazios antes que cheguem ao processamento principal. Isso eliminou erros intermitentes que levaram dois dias para serem diagnosticados anteriormente.

Quando esse princípio não funciona

Existem situações em que validar tudo antes de processar é impossível ou contra produtivo. Dados semi estruturados gerados por usuários, como comentários ou descrições de produtos, geralmente não têm formato fixo suficiente para uma validação rígida. Nesses casos, a melhor abordagem é capturar o máximo de estrutura possível e delegar o resto para processamento posterior ou análise manual. A ideia aqui não é tentar ler tudo, mas ser honesto sobre o que realmente pode ser lido automaticamente. Também vale considerar que validações excessivas podem gerar falsos positivos que bloqueiam dados válidos. Eu já passei por isso com um sistema de validação de e-mails que rejeitava domínios novos porque a lista de TLDs conhecidos não tinha sido atualizada. O correto nesse cenário é usar validações flexíveis quando possível e manter logs detalhados dos rejeitados para revisão periódica. O balanço certo entre segurança e praticidade depende do contexto do seu projeto. Em pipelines de produção críticos, validação rigorosa paga o custo. Em protótipos ou testes internos, o overhead pode não justificar o esforço. A decisão sempre volta para a pergunta original: se você não consegue ler o dado com confiança, o melhor caminho é não tentá-lo como se fosse válido.

Resumo prático para aplicar hoje

• Defina o esquema antes de conectar qualquer fonte de dados
• Use pydantic ou biblioteca equivalente para validação estrutural
• Crie uma camada de normalização entre validação e processamento
• Teste com dados reais antes de colocar em produção, não com amostras sintéticas
• Mantenha logs de rejeições e revise-os semanalmente para ajustar regras

Isso reduz significativamente o tempo gasto depurando problemas de integridade de dados e evita surpresas desagradáveis em produção. A maioria dos erros de ingestão acontece porque alguém pulou a validação early. Não seja essa pessoa.