Introdução ao data wrangling: o que é e por que importa

Fase 2 — Wrangling avançado | Pré-requisitos: Aulas 0 a 7 | Duração estimada: 60 minutos

Introdução

A Fase 1 ensinou o processo analítico, as ferramentas fundamentais e como fazer análises com dados razoavelmente limpos. A Fase 2 enfrenta a realidade: dados do mundo real raramente chegam limpos. Eles chegam incompletos, inconsistentes, mal formatados, espalhados em múltiplas fontes e cheios de surpresas desagradáveis.

Data wrangling é o conjunto de processos que transforma dados brutos e sujos em dados limpos e estruturados prontos para análise. O termo vem do inglês e significa algo como "domar" ou "arrebanhar" — uma metáfora adequada para o trabalho de reunir dados dispersos e colocá-los em ordem.

Esta aula é conceitual. Ela estabelece o vocabulário, a filosofia e o mapa do território que as aulas 9 a 12 vão explorar em detalhe. Entender bem o que é wrangling, por que ele consome tanto tempo e quais são os tipos de problema que você vai encontrar é tão importante quanto saber as funções pandas para resolvê-los.

O que é data wrangling

Data wrangling é composto de três fases que se repetem ciclicamente: coleta, avaliação e limpeza.

Coleta é o processo de obter os dados das fontes onde estão — arquivos, bancos de dados, APIs, páginas web — e trazê-los para o ambiente de análise num formato que o Python consegue manipular.

Avaliação é o processo de inspecionar os dados para identificar problemas de qualidade e estrutura. Você está procurando respostas para perguntas como: há valores ausentes? Os tipos estão corretos? Há duplicatas? Os valores fazem sentido? As tabelas podem ser combinadas corretamente?

Limpeza é o processo de corrigir os problemas identificados na avaliação. Isso inclui corrigir tipos, tratar ausentes, remover duplicatas, padronizar categorias, corrigir valores impossíveis e reestruturar o dataset quando necessário.

As três fases não são lineares. Você coleta, avalia, limpa, e então descobre que precisa de mais dados de outra fonte, volta à coleta, avalia o novo dataset, encontra novos problemas, limpa de novo. É um ciclo iterativo que termina quando os dados estão bons o suficiente para responder as perguntas que você formulou.

Por que wrangling consome tanto tempo

Estudos publicados por empresas como CrowdFlower, IBM e Anaconda ao longo dos anos consistentemente encontram que analistas e cientistas de dados gastam entre 60% e 80% do seu tempo em coleta e limpeza de dados, contra 20% a 40% em análise e modelagem. Isso não é uma disfunção do mercado que será resolvida com ferramentas melhores. É uma característica estrutural de trabalhar com dados do mundo real.

Os dados existem porque sistemas foram construídos para registrar transações, não para facilitar análises. Um sistema de CRM foi construído para gerenciar relacionamentos com clientes. Um sistema de ERP foi construído para controlar estoque e finanças. Um formulário de pesquisa foi construído para coletar respostas. Nenhum deles foi construído pensando em você, analista, que vai tentar combinar três sistemas diferentes numa análise coerente.

O resultado são dados com problemas de qualidade que variam de triviais a fundamentais: campos obrigatórios que na prática são ignorados, convenções de nomenclatura que mudaram ao longo dos anos sem retroatividade, sistemas legados que usam codificações diferentes dos sistemas modernos, campos de texto livre que contêm informações estruturadas que precisam ser extraídas, datas em formatos impossíveis de parsear automaticamente.

Além dos problemas técnicos, há problemas conceituais: o que conta como um cliente único quando o mesmo CPF aparece com três endereços de e-mail diferentes? Uma venda que foi cancelada e refeita conta como uma ou duas? Um produto que mudou de categoria no meio do período analisado deve ser contabilizado na categoria antiga, na nova, ou nas duas?

Essas perguntas não têm resposta técnica. Precisam de resposta analítica e, frequentemente, de consulta com quem conhece o negócio. O tempo de wrangling inclui esse trabalho de entendimento.

Tipos de problemas de qualidade

É útil ter um vocabulário para classificar os problemas que você vai encontrar. A literatura de qualidade de dados distingue dois tipos principais: problemas de qualidade e problemas de estrutura.

Problemas de qualidade

Problemas de qualidade são problemas com os valores dos dados — o quê está registrado está incorreto, incompleto ou inconsistente.

Completude: valores ausentes. Campos em branco, NaN, None, valores codificados como sentinela (-1, 999, "N/A", "desconhecido"). A ausência pode ser aleatória ou sistemática. Ausência sistemática — por exemplo, um campo que nunca foi preenchido para clientes de uma região específica — é muito mais problemática do que ausência aleatória.

Validade: valores que existem mas estão fora do domínio válido. Uma idade de 150 anos. Uma data de nascimento no futuro. Uma nota fiscal com valor negativo que não é uma devolução. Um CEP com 7 dígitos quando o padrão são 8. Esses valores precisam ser corrigidos ou removidos porque vão distorcer qualquer análise.

Consistência: valores que contradizem outros valores no mesmo dataset. Uma data de entrega anterior à data de compra. Um filho mais velho do que o pai. Um funcionário com data de demissão anterior à data de contratação. Inconsistências internas revelam erros de processo na coleta.

Uniformidade: o mesmo conceito representado de formas diferentes. "São Paulo", "Sao Paulo", "S. Paulo", "SP". "Masculino", "M", "masc", "1". "01/01/2024", "2024-01-01", "January 1, 2024". A uniformidade é especialmente crítica em campos usados para agrupamento ou junção.

Precisão: valores corretos em conceito mas imprecisos na magnitude. Coordenadas geográficas com três casas decimais quando você precisaria de seis para sua análise. Valores financeiros arredondados para o real mais próximo quando você precisa de centavos.

Unicidade: duplicatas. A mesma entidade registrada mais de uma vez. Duplicatas exatas são fáceis de detectar. Duplicatas parciais — o mesmo cliente com dois cadastros levemente diferentes — são muito mais difíceis.

Problemas de estrutura

Problemas de estrutura são problemas com como os dados estão organizados, independentemente dos valores individuais estarem corretos.

Dados não-tidy: os dados não seguem o princípio de que cada variável é uma coluna, cada observação é uma linha e cada tipo de unidade observacional forma uma tabela. Dados wide quando precisam ser long, múltiplas variáveis numa única coluna, valores nas colunas em vez de nas linhas.

Granularidade inadequada: os dados estão no nível errado de detalhe. Você tem dados mensais mas precisa de anuais. Você tem dados por produto mas precisa por categoria. Ou o contrário: você tem dados individuais mas precisa de agregados.

Mistura de tipos de entidade: uma tabela que mistura informações de pedidos com informações de clientes com informações de produtos, tudo em colunas diferentes. Isso complica joins e atualizações.

Codificações opacas: colunas com valores numéricos que são na verdade categorias codificadas (1 = masculino, 2 = feminino, 3 = não informado) sem documentação da codificação. Ou códigos internos de sistema que precisam ser traduzidos para ter significado analítico.

A diferença entre limpeza e distorção

Um risco real do wrangling é limpar demais — remover dados ou impor estrutura de forma que altera as conclusões que os dados deveriam sustentar. Isso não é sempre intencional, mas é sempre problemático.

Alguns exemplos de limpeza que se torna distorção.

Remover outliers sem critério. Você está analisando reclamações de clientes e remove os 1% de casos mais extremos por "serem outliers". Mas esses 1% são exatamente os clientes que sofreram fraude — o fenômeno mais importante para o negócio. Você limpou o sinal que estava procurando.

Preencher ausentes com a média de forma indiscriminada. Uma coluna de renda tem 30% de ausentes. Você preenche tudo com a média. Mas os ausentes são sistematicamente de clientes de baixa renda que não informaram — preencher com a média superestima a renda desse grupo e pode levar a conclusões completamente erradas sobre o perfil de clientes.

Normalizar texto de forma que colapsa distinções reais. Você padroniza a coluna de cidade para minúsculas e percebe que "São Paulo" e "Santo André" têm a mesma inicial normalizada mas são municípios diferentes. Uma função de limpeza mal escrita pode mesclar categorias que deveriam ser distintas.

A regra de ouro do wrangling é documentar cada decisão e seu impacto. Para cada transformação, você deve ser capaz de responder: quantos registros foram afetados? A distribuição das variáveis de interesse mudou significativamente? A análise final seria diferente se eu não tivesse feito essa limpeza?

O princípio dos dados tidy

Hadley Wickham, criador do tidyverse no R e uma das figuras mais influentes na área de ciência de dados, formalizou em 2014 o conceito de dados tidy num artigo seminal. Embora o artigo use R, os princípios são universais e se aplicam diretamente ao trabalho com pandas.

Dados tidy têm três propriedades:

Cada variável forma uma coluna. Uma variável é uma propriedade de cada observação — idade, salário, data de compra, categoria. Se você tem colunas como "jan", "fev", "mar" representando a mesma variável em meses diferentes, os dados não são tidy.

Cada observação forma uma linha. Uma observação é uma medição de um conjunto de variáveis para uma unidade específica no tempo. Se você tem dados de vendas e cada linha representa um produto-mês, então cada produto tem múltiplas linhas — uma por mês. Isso é tidy. Se cada linha representa um produto com colunas para cada mês, não é tidy.

Cada tipo de unidade observacional forma uma tabela separada. Informações sobre pedidos ficam numa tabela. Informações sobre clientes ficam em outra. Informações sobre produtos em outra. Você as combina via join quando precisa, mas não as mistura numa tabela só.

O formato tidy não é o único formato válido para dados. Formatos wide são melhores para apresentação visual e algumas operações matemáticas. Mas o formato tidy é o mais fácil de manipular programaticamente com pandas, e a maioria das funções de visualização e modelagem espera dados tidy como input.

Wrangling programático versus manual

Uma decisão importante é onde fazer o wrangling: no código Python ou manualmente numa planilha antes de carregar.

Wrangling manual numa planilha tem a vantagem de ser rápido para problemas simples e permite inspecionar visualmente os dados. Mas tem desvantagens sérias: não é reproduzível, não é auditável, escala mal para datasets grandes e é impossível de revisar sistematicamente.

Wrangling programático em Python tem a curva de aprendizado mais alta, mas é reproduzível, auditável, escalável e revisável. Se você descobrir um erro na limpeza semanas depois, pode corrigir o código e re-executar. Se a fonte de dados for atualizada, pode re-executar o pipeline inteiro. Se outra pessoa precisar reproduzir sua análise, o código documenta exatamente o que foi feito.

A regra prática para projetos de análise de dados é: todo wrangling deve estar no código. A única exceção são correções pontuais em arquivos de entrada que realmente não têm como ser feitas programaticamente — e mesmo nesse caso, elas devem ser documentadas num arquivo de changelog separado.

O ciclo documentado

Uma prática essencial no wrangling profissional é manter um registro das transformações aplicadas. Isso não precisa ser sofisticado. Uma célula markdown no notebook para cada decisão importante é suficiente.

O registro deve responder três perguntas para cada transformação: o que foi feito, por que foi feito e qual o impacto quantitativo.

### Decisão de limpeza #3
**O que:** Removidas 847 linhas onde `data_entrega` é anterior a `data_compra`.
**Por quê:** Inconsistência lógica impossível — data de entrega não pode
preceder data de compra. Provável erro de sistema na integração entre
o ERP e o sistema de logística.
**Impacto:** 0.8% do total de registros removidos. A distribuição de
`valor_pedido` nas linhas removidas não difere significativamente da
distribuição geral (média R$ 312 vs R$ 318 no dataset completo),
sugerindo que a remoção não introduz viés.

Esse nível de documentação parece excessivo quando você está fazendo a limpeza. Parece essencial quando você está tentando explicar seus resultados para alguém, revisando o trabalho seis meses depois, ou quando alguém questiona uma conclusão e você precisa rastrear como chegou aos dados finais.

Ferramentas do wrangling

As aulas seguintes cobrem as ferramentas em detalhe, mas aqui está o mapa do que vem pela frente.

Aula 9 cobre coleta: pd.read_csv() com todos os parâmetros avançados, leitura de Excel, conexão com bancos de dados via SQLAlchemy, consumo de APIs REST com requests, e extração básica de HTML com BeautifulSoup.

Aula 10 cobre avaliação: como identificar sistematicamente problemas de qualidade e estrutura usando pandas, como documentar descobertas e como priorizar o que limpar.

Aula 11 cobre limpeza: tratamento de ausentes com imputação adequada ao tipo de problema, detecção e remoção de duplicatas, correção de tipos, padronização de texto e categorias, tratamento de outliers e validação de que a limpeza funcionou.

Aula 12 cobre limitações e vieses: como reconhecer que mesmo dados limpos podem levar a conclusões incorretas se os dados em si têm problemas estruturais de representatividade.

Resumo

Data wrangling é o conjunto de processos que transforma dados brutos em dados analisáveis: coleta, avaliação e limpeza em ciclos iterativos. Ele consome 60% a 80% do tempo de um analista porque dados existem para operar sistemas, não para facilitar análises. Os problemas de qualidade incluem completude, validade, consistência, uniformidade, precisão e unicidade. Os problemas de estrutura incluem formatos não-tidy, granularidade inadequada e codificações opacas. Dados tidy têm cada variável numa coluna, cada observação numa linha e cada tipo de entidade numa tabela. Todo wrangling deve ser feito programaticamente e documentado com o quê, por quê e o impacto quantitativo de cada decisão.

Exercícios

Por que dados de sistemas operacionais tendem a ter problemas de qualidade quando usados para análise? Dê um exemplo concreto de como um sistema construído para um propósito pode gerar dados inadequados para outro.

✓ Resposta:
Sistemas operacionais são construídos para suportar processos de negócio específicos — registrar uma venda, processar um pagamento, agendar uma consulta. A qualidade dos dados que eles geram é medida pela capacidade de completar esses processos, não pela utilidade analítica posterior.

Um exemplo concreto: um sistema de agendamento de consultas médicas tem um campo "motivo da consulta" como texto livre, porque no contexto operacional o importante é que o médico veja a queixa do paciente, não que ela seja categorizada de forma padronizada. Para análise epidemiológica, esse campo de texto livre é um pesadelo: "dor de cabeça", "cefaleia", "dor na cabeça", "cabeça doendo", "enxaqueca" e "dor craniana" podem ser o mesmo diagnóstico, diferentes diagnósticos ou termos usados inconsistentemente por diferentes recepcionistas ao longo dos anos. Para fazer qualquer análise de frequência de queixas, um analista precisaria limpar e categorizar esse campo manualmente ou com processamento de linguagem natural — um trabalho enorme que não foi necessário para nenhuma operação do sistema.
Classifique cada problema abaixo como um problema de qualidade (e de qual tipo) ou um problema de estrutura:

a) Uma tabela de vendas onde cada coluna representa um mês: "jan_2024", "fev_2024", etc. b) Uma coluna "telefone" com valores "11999887766", "(11) 99988-7766" e "11 9 9988-7766". c) Uma linha onde a data de nascimento do cliente é 15/03/2035. d) Uma coluna "status" com valores 1, 2 e 3 sem documentação do significado. e) O mesmo pedido aparecendo duas vezes com IDs diferentes mas todos os outros campos idênticos.

✓ Resposta:
a) Problema de estrutura — formato não-tidy. Cada mês é uma variável repetida em colunas separadas em vez de valores de uma coluna "mês". Deveria ser transformado com melt() para ter uma coluna "mes" e uma coluna "valor".

b) Problema de qualidade — uniformidade. O mesmo tipo de dado (número de telefone) está representado em três formatos diferentes. Para agrupamento ou busca, os três precisariam ser normalizados para um formato padrão.

c) Problema de qualidade — validade. Uma data de nascimento no futuro é um valor fora do domínio válido. É provavelmente um erro de digitação (talvez 2005 no lugar de 2035) ou um valor sentinela usado por algum sistema para indicar data desconhecida.

d) Problema de estrutura — codificação opaca. Os valores existem e são tecnicamente válidos, mas sem saber que 1 = "ativo", 2 = "inativo" e 3 = "suspenso", a coluna é inutilizável analiticamente. Tecnicamente também é um problema de documentação.

e) Problema de qualidade — unicidade. Duplicata com IDs diferentes é o tipo mais perigoso de duplicata porque não é detectada por uma simples busca de IDs duplicados. Requer comparação de múltiplas colunas para identificar.
Explique o princípio dos dados tidy com suas próprias palavras e dê um exemplo de um dataset não-tidy e como ele ficaria no formato tidy.
✓ Resposta:
Dados tidy são organizados de forma que cada variável ocupa uma coluna, cada observação ocupa uma linha e cada tipo de entidade tem sua própria tabela. É a forma de organização mais conveniente para manipulação programática porque as funções de análise, agrupamento e visualização esperam esse formato.

Exemplo de dataset não-tidy — notas de alunos em formato wide:
```
aluno     | matematica | portugues | ciencias
----------|------------|-----------|----------
Ana       | 8.5        | 7.0       | 9.0
Bruno     | 6.0        | 8.5       | 7.5
```
Aqui "matéria" é uma variável, mas está espalhada em três colunas. "Nota" é outra variável, mas os valores estão em colunas diferentes dependendo da matéria.

O mesmo dataset no formato tidy:
```
aluno     | materia    | nota
----------|------------|------
Ana       | matematica | 8.5
Ana       | portugues  | 7.0
Ana       | ciencias   | 9.0
Bruno     | matematica | 6.0
Bruno     | portugues  | 8.5
Bruno     | ciencias   | 7.5
```
No formato tidy, calcular a média por matéria é df.groupby('materia')['nota'].mean(). Filtrar apenas ciências é df[df['materia'] == 'ciencias']. Adicionar uma nova matéria é adicionar linhas, não colunas. Todas essas operações são mais simples do que no formato wide.
Por que o wrangling manual numa planilha é inadequado para projetos de análise de dados profissionais, mesmo sendo mais rápido para tarefas simples?

✓ Resposta:
O problema central do wrangling manual é que ele não é reproduzível nem auditável. Quando você abre um CSV no Excel e deleta linhas, corrige valores ou reformata colunas, essa sequência de ações não fica registrada em lugar nenhum. O arquivo resultante mostra o estado final mas não o caminho para chegar lá.

Isso cria quatro problemas concretos em contexto profissional.

Primeiro, não é reproduzível: se a fonte de dados for atualizada — novos meses de dados, correção de erros históricos — você precisa refazer tudo manualmente, sem garantia de consistência com o que foi feito antes.

Segundo, não é auditável: se alguém questionar um resultado, você não consegue mostrar exatamente o que foi feito nos dados. "Eu limpei algumas coisas no Excel" não é uma resposta aceitável em contexto profissional ou acadêmico.

Terceiro, escala mal: funciona para datasets de centenas de linhas, é impraticável para dezenas de milhares e impossível para milhões.

Quarto, é propenso a erros silenciosos: uma filtragem errada no Excel pode remover dados sem aviso, e sem um registro do que foi feito, o erro pode nunca ser descoberto.

Wrangling em código resolve todos esses problemas: é reproduzível, auditável, escalável e revisável. O custo é o tempo de aprender e escrever o código, que se paga rapidamente em qualquer projeto com mais de uma iteração.
Você recebe um dataset de pesquisa de satisfação de clientes onde 40% das respostas da pergunta "renda familiar" estão ausentes. Antes de decidir o que fazer com esses ausentes, quais perguntas você faria para entender o padrão de ausência?

✓ Resposta:
A decisão sobre como tratar ausentes deve ser precedida por uma investigação do mecanismo de ausência. As perguntas certas são as seguintes.

Os ausentes são aleatórios ou sistemáticos? Compare o perfil dos respondentes com ausente versus sem ausente em outras variáveis como idade, escolaridade, satisfação geral e região. Se os grupos forem semelhantes, a ausência é provavelmente aleatória. Se os grupos forem diferentes, há um padrão.

Há correlação entre ausência na renda e outras variáveis? Por exemplo, pessoas com renda muito alta ou muito baixa tendem a omitir renda por razões diferentes — as primeiras por privacidade, as segundas por constrangimento. Se for esse o caso, preencher com a média introduziria viés sistemático nos dois extremos.

A pergunta era obrigatória ou opcional no formulário? Se era opcional, a ausência pode ser uma resposta em si — as pessoas que preferiram não responder podem ter um perfil específico relevante para a análise.

Qual era a posição da pergunta no questionário? Perguntas no final de questionários longos têm mais ausentes porque as pessoas desistem antes de chegar. Se a renda era a última pergunta, a ausência pode estar correlacionada com paciência ou engajamento, não com a renda em si.

O dataset tem um identificador que permite buscar a renda em outra fonte? Se os clientes têm um ID que existe em outro sistema com dados cadastrais, talvez seja possível cruzar e preencher os ausentes com dados externos em vez de imputar.

Com essas respostas, a decisão sobre o tratamento — remover, imputar com a mediana, imputar com um modelo, criar uma categoria "não informado" — pode ser tomada com base em evidência, não em convenção.

Referências

Wickham, Hadley. "Tidy Data". Journal of Statistical Software, vol. 59, 2014. O artigo que formalizou os princípios de dados tidy. Disponível em jstatsoft.org/article/view/v059i10
Dasu, Tamraparni; Johnson, Theodore. Exploratory Data Mining and Data Cleaning. Wiley-Interscience, 2003. Referência técnica sobre tipos de problemas de qualidade de dados e métodos para detectá-los e corrigi-los.
Kandel, Sean et al. "Research Directions in Data Wrangling". VLDB Endowment, 2011. Artigo de pesquisa que mapeia o estado da arte em ferramentas e técnicas de wrangling, com boa caracterização dos tipos de problemas encontrados na prática.
Lohr, Steve. "For Big-Data Scientists, Janitor Work Is Key Hurdle to Insights". The New York Times, 2014. Artigo jornalístico acessível sobre por que limpeza de dados consome tanto tempo de analistas e cientistas de dados.
CrowdFlower Data Science Report, 2016. O relatório que popularizou a estatística de 80% do tempo gasto em preparação de dados. Disponível em searches por "CrowdFlower data science report 2016".
Peng, Roger; Matsui, Elizabeth. The Art of Data Science. Leanpub, 2015. Disponível gratuitamente em leanpub.com/artofdatascience Cobre o processo de análise com boas seções sobre o papel do wrangling no ciclo completo.