O que dados sujos ensinam sobre sistemas reais: garbage in, garbage out não é metáfora
A limpeza dos dados de pesquisa levou mais tempo que a análise. Duplicatas, valores ausentes, encoding quebrado, datas em três formatos diferentes. O que isso ensina sobre sistemas de produção.
O dataset tinha 47 mil registros. A análise que eu precisava fazer levaria uma tarde.
A limpeza dos dados levou três semanas.
Duplicatas. Valores ausentes sem padrão — às vezes vazio, às vezes "N/A", às vezes "não informado", às vezes zero. Datas em três formatos diferentes na mesma coluna. Encoding quebrado em algumas linhas (UTF-8 misturado com Latin-1). Registros com campos numéricos preenchidos com texto de erro de formulário.
Aprendi o que qualidade de dado significa antes de aprender o vocabulário formal.
"Garbage in, garbage out" é frase que todo mundo repete. Poucos entendem o que ela implica na prática.
Implica que dado de má qualidade não é problema de dados — é problema de sistema. O dado reflete como ele foi coletado. Formulário sem validação produz data em qualquer formato. Campo obrigatório que pode ser contornado produz valor vazio. Integração entre sistemas sem schema acordado produz inconsistência.
O dado sujo é sintoma. O sistema que o gerou é a causa.
O que a limpeza de dados de pesquisa ensinou sobre sistemas de software:
Validação na entrada, não na saída. Dado inválido que entra no sistema se propaga. Quanto mais tarde você detecta, mais caro fica corrigir. O lugar certo para validar é na fronteira do sistema — quando o dado entra, não quando você vai usar.
Schema é contrato. Se dois sistemas trocam dado sem schema explícito, a interpretação diverge com o tempo. Uma coluna que era int virou string em algum momento sem ninguém perceber. Isso só aparece quando análise falha de forma misteriosa.
Idempotência em limpeza. Qualquer operação de limpeza precisa ser idempotente — rodar duas vezes deve produzir o mesmo resultado que rodar uma. Se limpeza não é idempotente, você cria dado diferente dependendo de como e quando rodou. Isso é não-determinismo que você não quer.
Auditoria de transformação. Quando você transforma dado, você precisa ser capaz de rastrear o que mudou e por quê. Em pesquisa aprendi isso por necessidade — o professor queria entender cada decisão de limpeza. Em produção é o mesmo: se dado muda, você precisa saber quem mudou, quando, e como.
Anos depois, quando comecei a trabalhar com data pipelines em plataforma, reconheci imediatamente os mesmos problemas em escala industrial.
O pipeline que falha silenciosamente porque recebeu dado em formato inesperado. O schema que divergiu entre produtor e consumidor sem ninguém perceber. O campo que tem três representações diferentes de "nulo" dependendo de qual sistema enviou.
A escala muda. O problema é o mesmo.
Qualidade de dado não é responsabilidade do time de dados. É responsabilidade do sistema que produz o dado. Quem consome paga o custo de quem produz sem validação.
Essa semana: tem algum dado que seu sistema consome sem validar na entrada? O que acontece quando esse dado chegar malformado?