O que é e como funciona a atividade de pre no dia a dia
A atividade de pre é basicamente o processo de preparar dados antes de usá-los em qualquer pipeline. O nome soa mais complexo do que é na prática. Você pega uma fonte bruta — seja um CSV mal formatado, uma API que retorna JSON inconsistente, ou um banco legado com campos varchar onde deveria ter tipo definido — e aplica transformações para que o dado fique utilizável. Falo isso porque já perdi mais tempo do que gostaria entendendo por que um job parava todo dia às 3h da manhã por causa de um caractere nulo em uma coluna que ninguém documentou. Achei que era problema de timing. Era atividade de pre mal feita. Desde então, todo pipeline meu começa com uma camada de limpeza explícita antes de qualquer coisa.
O conceito em si não é novo. Dados brutos entram, passam por validação, normalização, enriquecimento opcional e saem estruturados para a próxima etapa. O que varia é a ferramenta e o volume. Mas o princípio permanece o mesmo em qualquer stack que eu já vi funcionar ou falhar.
Onde a maioria erra na atividade de pre
O erro mais comum que eu vejo — e já cometi, então não tenho moral pra julgá-los — é tratar a atividade de pre como algo que pode ser embutido junto com a lógica de negócio. Se você mistura validação de dados com regras de domínio, o código vira um monstro difícil de testar. Separe. Use um módulo específico, dê a ele uma interface clara, e trate entrada inválida como exceção desde o início, não como um case a mais no switch. Outra armadilha é achar que pré-processamento é só limpar. Enrichment é parte legítima da atividade de pre quando faz sentido. Lookup de tabela mestre, conversão de timezone, padronização de formato de data. Tudo isso é pré-processamento. O problema é quando o enrichment vira dependência oculta — seu job depende de uma API externa que não tem SLA e você não sabe até dar produção.
Dica prática: mantenha um arquivo de logs de transformação. Cada campo que você altera, cada regra que aplica, deve ficar registrado. Quando o dado chegar errado lá na frente, você precisa saber exatamente onde e por quê. Sem isso, você passa horas rastreando bug que na verdade é transformação perdida ou aplicada twice.
Um caso real que eu tive com atividade de pre
Eu trabalhei num projeto onde o dado vinha de três fontes diferentes: um ERP antigo exportando CSV com separador variável dependendo da regional, uma API REST com schema que mudava sem aviso, e um banco PostgreSQL com trigger que inseria registros em tabela temporária sem constraint. A atividade de pre precisava unificar tudo num lakehouse. O problema específico foi que a regional norte-nordeste do ERP usava vírgula como decimal e ponto como milhar, enquanto o resto do país fazia o inverso. Isso causava coluna numérica virando string em 12% dos registros. Minha primeira tentativa foi tratar isso no consumo. Erro. O correto foi tratar na origem, dentro da atividade de pre, com uma regola específica detectada pelo padrão de regional no código do cliente. A partir daí, o flag de anomalia passou a ser mapeável, e o percentual de erro caiu para 0,3%.
Não é perfeição. Ainda temos aquele 0,3%. Mas é aceitável quando o alternativo seria perder dois dias da semana caçando onde o dado quebrou. Priorize sempre onde o custo de detecção tardia é maior do que o custo de correção na origem.
Como estruturar a atividade de pre sem Surpreenda
Eu divido a atividade de pre em quatro etapas sequenciais: ingestão, validação, transformação e persistência. Cada uma com fronteira definida. A ingestão não precisa saber se o dado é válido. Ela só precisa colocar o dado na fila. A validação verifica regras. A transformação aplica regras de negócio. A persistência grava o resultado. Use um pipeline orientado a estágios. Cada estágio tem entrada e saída tipadas. Se um estágio falha, ele não mata o job. Ele registra, move para dead letter, e continua. Isso é especialmente importante em atividade de pre porque dados defeituosos não podem bloquear dados bons.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Para quem começa, eu recomendo algo simples: Python com Pandas ou Polars, Arrow para intercambio, e uma biblioteca de validação como Pydantic. Para escala maior, considere Apache Spark ou Flink. A escolha depende do volume, não da ambição. Pipeline pequeno bem feito vale mais do que pipeline complexo mal configurado.
O que a atividade de pre não resolve
Atividade de pre não corrige dados errados na origem. Ela só documenta e sinaliza. Se o ERP grava telefone como número inteiro sem DDD, nenhuma camada de pré-processamento vai inventar o DDD correto. Nesses casos, a atividade de pre deve registrar o problema, alertar, e encaminhar para governança. Tentar corrigir heuristicamente gera mais erro do que benefício. Também não substitui governança de dados. Você pode ter a melhor atividade de pre do mundo, mas se não há dono do dado, dicionário atualizado, e processo de mudança controlada, o esforço se dissolve em seis meses. Ferramenta não resolves problema humano.
Se seu volume é pequeno e suas fontes são confiáveis, talvez você nem precise de uma camada dedicada. Um script de limpeza pontual pode ser suficiente. Não adicione complexidade só porque template diz que é best practice. Avalie custo-benefício real.
Medindo o impacto da atividade de pre
Um número simples que eu uso: tempo médio de resolução de dados corruptos. Antes de formalizar a atividade de pre, esse número era de 4 horas em média. Depois de estruturado com validação explícita e logging, caiu para 35 minutos. A diferença não é mágica. É disciplina de separar responsabilidade e registrar transformação. Outro indicador útil: taxa de rejeição por estágio. Se seu estágio de validação rejeita mais de 5% dos registros, investigue. Pode ser regra muito apertada, pode ser dado da origem realmente defeituoso, ou pode ser que sua atividade de pre está aplicando regras que não deveriam estar ali. Revisão trimestral dessa métrica evita que camada de limpeza vire filtro arbitrário.
E ainda tem o custo de computação. Pré-processamento em escala gasta recursos. Um job mal escrito pode consumir 3x mais do que o necessário só por falta de particionamento inteligente ou por aplicar transformação em colunas que não serão usadas depois. Perfile seus jobs. Otimize depois de medir, não antes.
Alternativas quando a atividade de pre não cabe
Em alguns cenários, consuming the data lazily ou usando schema-on-read pode ser mais eficiente do que pré-processar tudo upfront. Se seu dado é exploratório, se a consulta varia muito, ou se o custo de manutenção da camada de pré-processamento supera o benefício, considere não criar essa camada. Arrow Native, Delta Lake, ou até materialização sob demanda são opções válidas. O ponto é: atividade de pre é uma decisão de engenharia, não um dogma. Ela existe para reduzir incerteza. Quando a incerteza é baixa, o custo da camada pode não valer. Quando a incerteza é alta — múltiplas fontes, regras de negócio complexas, compliance exigente — a atividade de pre se paga rápido.
O que eu garanto é que ignora-la completamente, sem avaliar, é erro. Avaliar, decidir, e revisar periodicamente não é. A atividade de pre que eu vejo funcionar bem é aquela que tem dono, métrica, e portabilidade de saída. Sem esses três pilares, vira depósito de gambiarra com nome sofisticado.
