Histórias de Horror em Limpeza de Dados: Lições de 10 Anos de CSVs Bagunçados
Um único caractere Unicode invisível em um cabeçalho CSV causou um erro de faturamento de $340K em uma empresa de telecomunicações com a qual trabalhei em 2019. O arquivo parecia perfeito no Excel, Notepad++, VS Code, e até mesmo quando passado por `cat` no terminal. Cada inspeção visual mostrava nomes de colunas limpos e formatados corretamente. Mas o sistema de faturamento continuava rejeitando o campo "customer_id", alegando que não existia. Três semanas. Esse foi o tempo que levou para cinco engenheiros, dois analistas de dados e um gerente de projeto muito estressado encontrarem o problema. Reescrevemos scripts de importação, questionamos nossos esquemas de banco de dados e até suspeitamos de um bug em nosso pipeline de ETL. A resposta? Um caractere não juntador de largura zero (U+200C) invisivelmente posicionado entre "customer" e "_id". O cabeçalho não era "customer_id"—era "customer_id". Para cada olho humano, idêntico. Para cada sistema de computador, campos completamente diferentes. Esse incidente custou à empresa $340K em ciclos de faturamento atrasados, horas de contratados de emergência e créditos para clientes por faturas atrasadas. Também me ensinou a lição mais importante da minha carreira: arquivos CSV não são simples. Eles são campos minados disfarçados de planilhas, e todo engenheiro de dados precisa tratá-los com a paranoia que merecem. Passei a última década limpando conjuntos de dados para empresas da Fortune 500 em finanças, saúde, varejo e telecomunicações. Vi pesadelos de codificação que corromperam registros de pacientes, espaços em branco fantasmas que quebraram reconciliações financeiras e formatos de data tão criativos que só poderiam ter sido projetados por alguém que realmente odiava futuros engenheiros de dados. Este artigo é minha tentativa de salvar você da mesma dor.O Apocalipse da Codificação: Quando UTF-8 Não é UTF-8
O pior desastre de dados que já testemunhei aconteceu em uma cadeia de varejo multinacional em 2017. Eles estavam consolidando dados de clientes de 47 bancos de dados regionais em 12 países em um único data warehouse. Simples o suficiente, certo? Exporte para CSV, importe para o warehouse, execute alguma lógica de desduplicação, e você está feito. Exceto que os CSVs da divisão francesa continuavam corrompendo nomes. "François" se tornava "François". "Chloé" se tornava "Chloé". A divisão alemã teve problemas semelhantes com os diacríticos. Os dados da divisão japonesa estavam completamente ilegíveis—apenas linhas de pontos de interrogação e caracteres de substituição. A causa raiz? Cada equipe regional havia exportado seus CSVs usando diferentes codificações. A França usou ISO-8859-1 (Latin-1). A Alemanha usou Windows-1252. O Japão usou Shift-JIS. As equipes do Reino Unido e dos EUA usaram UTF-8, mas algumas tinham UTF-8 com BOM (Byte Order Mark) e outras sem. Uma equipe na Espanha havia, de alguma forma, exportado seus dados em UTF-16LE. O projeto de consolidação, originalmente previsto para três meses, levou onze meses. Tivemos que construir um pipeline de detecção de codificação personalizado que realizasse: 1. Tentar detectar a codificação usando várias bibliotecas (chardet, charset-normalizer e uma heurística personalizada) 2. Validar a detecção verificando padrões de caracteres comuns em cada língua 3. Converter tudo para UTF-8 sem BOM 4. Registrar cada conversão com pontuações de confiança para revisão manual Mesmo com esse pipeline, tivemos uma taxa de erro de 3% que exigiu correção manual. Isso representa 3% de 47 milhões de registros de clientes—1,4 milhão de nomes que precisavam de revisão humana. A lição? Nunca confie na codificação de um CSV. Nunca. Mesmo que alguém lhe diga "é definitivamente UTF-8", verifique isso. Já vi arquivos que alegavam ser UTF-8 em seus metadados, mas eram na verdade Windows-1252 com caracteres de alta ASCII. Já vi arquivos UTF-8 com pedaços aleatórios de ISO-8859-1 onde alguém copiou e colou de um sistema antigo. Já vi até mesmo um arquivo que trocou de codificação no meio do caminho porque o script de exportação travou e reiniciou com configurações de local diferentes. Agora, todo CSV que passa pela minha mesa é submetido a um script de validação de codificação antes de eu olhar os dados. Isso me economizou incontáveis horas e evitou pelo menos uma dúzia de incidentes graves.O Espaço em Branco que Não Estava Lá (Exceto Estava)
Em 2018, fui chamado para consertar um sistema de reconciliação financeira que estava falhando havia seis meses. A empresa era um processador de pagamentos lidando com bilhões de dólares em transações. O processo de reconciliação deles comparava registros de transações de seu banco de dados com relatórios CSV de parceiros bancários. O sistema estava reportando milhares de inconsistências todos os dias—transações que apareciam nos relatórios bancários, mas não em seu banco de dados, ou vice-versa. A equipe financeira estava reconciliando manualmente essas inconsistências, trabalhando 60 horas por semana para acompanhar. Eles verificavam cada transação sinalizada e descobriam que ela realmente existia em ambos os sistemas. Os IDs das transações combinavam perfeitamente. Mas o sistema automatizado continuava sinalizando-as como inconsistências. Gastei dois dias analisando o código, as consultas de banco de dados e a lógica de parsing de CSV. Tudo parecia correto. Então fiz algo que deveria ter sido óbvio desde o início: abri o CSV em um editor hexadecimal. Lá estava. Cada ID de transação nos arquivos CSV do banco tinha um espaço final. Não visível no Excel. Não visível na maioria dos editores de texto. Mas lá, no despejo hexadecimal: `54 52 41 4E 53 31 32 33 34 35 20` em vez de `54 52 41 4E 53 31 32 33 34 35`. O final `20` era um caractere de espaço. O banco de dados armazenava IDs de transação sem espaços finais. A lógica de comparação estava fazendo correspondência exata de strings. "TRANS12345" ≠ "TRANS12345 ". Milhares de falsas inconsistências, centenas de horas desperdiçadas, tudo por causa de um único caractere de espaço final. Mas aqui é onde a situação piora: os espaços finais não eram consistentes. Alguns IDs de transação os tinham, outros não. Alguns tinham espaços finais, outros tinham espaços iniciais, e alguns tinham ambos. Alguns tinham tabs em vez de espaços. Um arquivo memorável tinha uma mistura de espaços, tabs e espaços não separáveis (U+00A0). A correção foi simples—remover todos os espaços em branco durante a importação. Mas a lição foi profunda: espaços em branco em CSVs nunca são acidentais, sempre problemáticos e frequentemente invisíveis. Agora tenho uma regra: todos os campos de string são removidos durante a importação, sem exceções. Não me importa se a lógica de negócio diz que o campo deve preservar espaços em branco. Não me importa se alguém insiste que os dados estão limpos. Remova tudo. Também aprendi a ficar atento a outros caracteres invisíveis: espaços em branco de largura zero (U+200B), não-juntadores de largura zero (U+200C), juntadores de largura zero (U+200D) e o temido marcador de ordem de bytes (U+FEFF) que às vezes aparece no meio dos arquivos. Esses caracteres são os fantasmas na máquina, invisíveis para humanos, mas muito reais para computadores.O Formato de Data que Quebrou o Comércio Internacional
Deixe-me contar sobre a vez em que encontrei um formato de data tão maldito, tão fundamentalmente quebrado, que ainda assombra meus sonhos. Isso aconteceu em uma empresa de logística que coordenava embarques entre fabricantes na Ásia e vendedores na América do Norte e Europa. O sistema funcionava assim: os fabricantes enviavam arquivos CSV com detalhes de embarque, incluindo datas de coleta, datas estimadas de entrega e datas de liberação alfandegária. O sistema fazia o parsing dessas datas, calculava tempos de trânsito e coordenava com empresas de transporte e despachantes aduaneiros. Tudo funcionou bem por anos. Então, em março de 2016, o sistema começou a agendar embarques para datas no passado. Containers que deveriam ter sido coletados em 15 de março de 2016 estavam sendo agendados para 15 de março de 1916. Documentação alfandegária estava sendo arquivada para datas que precediam a invenção do transporte de contêineres. A causa raiz? A formatação automática de data do Excel combinada com diferenças nos formatos de data regionais e um mal-entendido verdadeiramente espetacular de como as datas funcionam. Aqui está o que estava acontecendo: 1. Um fabricante na China inseria uma data como "3/15/2016" (15 de março de 2016 no formato MM/DD/YYYY) 2. O Excel interpretava isso como uma data e armazenava internamente como um número serial (42444 para 15 de março de 2016) 3. Quando exportado para CSV, o Excel formatava de acordo com a localidade do sistema 4. A localidade do sistema chinês usava o formato YYYY-MM-DD, então exportava como "2016-03-15" 5. Nosso sistema de importação, configurado para o formato MM/DD/YYYY, interpretaria "2016-03-15" como "2016/03/15" (o 2016º mês, 3º dia, ano 15) 6. Como o mês 2016 é inválido, o parser recuaria para interpretá-lo como "20/16/03/15" 7. Através de uma série de tentativas de análise cada vez mais desesperadas, acabaria se fixando em "03/15/1916" Mas espere, piora. Alguns fabricantes estavam usando o formato DD/MM/YYYY. Alguns estavam usando YYYY-MM-DD. Alguns estavam usando MM/DD/YY (anos com dois dígitos). E um fabricante em Taiwan estava usando o calendário Minguo, onde o ano 105 corresponde a 2016 d.C. (1912 + 105). Acabamos com datas variando de 1916 a 2116, com um cluster particularmente denso em torno de 1970 (a época Unix) porque alguns sistemas exportavam datas como timestamps Unix e nosso parser as interpretava como formato YYYYMMDD. A solução exigiu: - Implementar um parser de data de múltiplas estratégias que tentaria detectar o formato - Adicionar regras de validação (rejeitar datas antes de 2000 ou depois de 2050) - Exigir que os fabricantes usassem exclusivamente o formato ISO 8601 (YYYY-MM-DD) - Construir uma interface web para uploads de CSV que exibiria as datas analisadas antes da importação - Criar um conjunto de testes abrangente com datas em todos os formatos concebíveis Mesmo com todas essas salvaguardas, ainda recebemos ocasionalmente erros de parsing de data. Só no mês passado, encontrei um CSV onde alguém havia inserido "2/29/2023" (29 de fevereiro de 2023—uma data que não existe porque 2023 não é um ano bissexto). O Excel aceitou isso, armazenou como o número serial 45000, e exportou como "2023-02-29". Nosso sistema o importou, validou que estava no formato correto e agendou um embarque para uma data que não existe."O problema com as datas é que todo mundo acha que as entende, mas na verdade ninguém entende. As datas são construtos culturais, não matemáticos. Elas têm fusos horários, horário de verão, anos bissextos, segundos bissextos e reformas de calendário. Elas têm diferentes formatos em diferentes países, diferentes pontos de partida em diferentes eras, e significados diferentes em diferentes contextos. E arquivos CSV, com sua completa falta de metadados, não dão nenhuma maneira de saber quais interpretações estão corretas."Esta citação de um colega captura perfeitamente o problema da data. CSVs não têm tipos de dados. Eles não têm esquemas. Eles são apenas texto. Quando você vê "01/02/03" em um CSV, isso significa 2 de janeiro de 2003? 1 de fevereiro de 2003? 2 de março de 2001? 3 de fevereiro de 2001? Não há como saber sem contexto, e contexto é exatamente o que os CSVs não fornecem.
Os Números que Não Eram Números
Aqui está uma tabela com os problemas de dados numéricos mais comuns que encontrei, juntamente com sua frequência e impacto típico:| Tipo de Problema | Frequência | Impacto Típico | Exemplo |
|---|---|---|---|
| Separadores de milhar | Muito Alto (60%) | Falhas de importação, erros de tipo | "1,234.56" analisado como string |
| Símbolos de moeda | Alto (45%) | Falhas de importação, erros de cálculo | "$1,234.56" ou "€1.234,56" |
| Diferentes separadores decimais | Alto (40%) | Erros de cálculo catastróficos | "1.234,56" (Europeu) vs "1,234.56" (EUA) |
| Notação científica | Média (25%) | Perda de precisão, má interpretação | "1.23E+05" ou "1.23456789E-10" |
| Zeros à esquerda | Média (30%) | Perda de dados, corrupção de IDs | "00123" vira "123" |
| Símbolos de porcentagem | Média (20%) | Erros de cálculo 100x | "15%" armazenado como 15 em vez de 0.15 |
| Formatos de números negativos | Baixo (15%) | Perda de sinal, cálculos incorretos | "(123" |