O que acontece quando você precisa dividir algo em partes menores
Achei que ia ser simples na primeira vez. Era 2018, num projeto de migrar dados de um legado em COBOL para uma arquitetura microserviços. O sistema tinha tabelas monolíticas de 47 colunas cada, com campos compostos que não obedeciam a nenhuma normalização que eu conhecesse. Meu chefe pediu para eu criar um pipeline de ingestão que aceitasse esses arquivos flat e os transformasse em estruturas JSON normalizadas. Eu disse que sim, sem pensar nas implicações. O problema real começou quando precisei fazer a decomposição dos campos composto. Cada registro vinha com strings como "SAO_PAULO/SP/01331-000" que precisavam ser separadas em cidade, estado e CEP. Fácil, certo? Errado. Porque alguns endereços vinham como "RIO_DE_JANEIRO/RJ//20040" com barras duplas, outros como "CURITIBA-PR" colados, e ainda tinha aqueles registros especiais onde o campo estado vinha escrito por extenso como "ESTADO_DE_SAO_PAULO". Sem contar com os casos em que o CEP era ausente e precisava ser inferido a partir do DDD.
Atividade composição e decomposição na prática
O que eu aprendi naquela migração foi que composição e decomposição nunca são operações simétricas. Você pode compor cinco campos simples (rua, numero, bairro, cidade, estado) em uma única string composto, mas decompor essa string de volta exige regras que capturam todas as variações possíveis. E ai entram os edge cases que todo mundo esquece. No meu caso, resolvi criar uma função em Python que usava expressões regulares condicionais, não um simples split por delimitador. A lógica era: primeiro tenta extrair o CEP com regex "^\\d{5}-?\\d{3}$", depois verifica se o estado está entre barras ou após o hífen, e finalmente faz a decomposição da cidade removendo sufixos comuns como "-SP" ou "/SAO_PAULO". Funcionou para 94% dos registros. Os 6% restantes eu tratei manualmente, porque nenhum regex univers al captura todas as variações de endereços brasileiros.
A lição prática: se você estiver fazendo atividade composição e decomposição em produção, comece pela decomposição, não pela composição. Composição é trivial — é só concatenar com delimitadores. Decomposição é onde os problemas aparecem. E quando os problemas aparecem, eles não aparecem isolados. Aparecem no meio de um batch de 2 milhões de registros às 3 da manhã.
Como estruturar o processo passo a passo
A estrutura que funcionou para mim foi diferente da teoria. Comecei testando a decomposição, depois a composição, e só então implementei a validação cruzada. Validar antes de decompor é desperdício de tempo — você gasta ciclos processando dados que ainda vão ser refatorados quando. Definições técnicas não ajudam quando o campo estado vem como "UF_SP" em vez de "SP". O que ajuda é ter um mapeamento de valores conhecidos, preferencialmente baseado em tabelas de referência oficiais. No Brasil, o IBGE tem uma base de códigos de municípios atualizada trimestralmente. Use ela. Não reinvente a roda.
O pipeline que eu construí levou 3 dias para ficar production-ready. Os primeiros 2 dias foram puramente de exploração de dados — analisar samples, documentar variações, criar um dicionário de mappings. Só no terceiro dia é que comecei a escrever código. A regra prática: gaste 60% do tempo entendendo os dados, 30% desenhando a lógica, 10% implementando. Inversão disso gera dívida técnica que você paga com juros altos.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Insights contraintuitivos que ninguém conta
Aqui vai algo que ninguém explica nos manuais: decomposição composta nunca preserva fidelidade. Quando você decompõe "SAO_PAULO/SP/01331-000" em cidade, estado e CEP, você perde informações implícitas como a regionalidade ("SAO_PAULO" pode ser a cidade ou a região metropolitana). Para recuperar isso, você precisa de campos adicionais que não estavam presentes no dado original. O segundo insight: composição e decomposição são operações com complexidades assimétricas. Composição é O(n) — linear, previsível. Decomposição pode ser O(n²) no pior caso, porque você precisa testar múltiplas regras contra cada campo. No meu projeto, a decomposição de endereços levou 12 segundos para 10 mil registros, enquanto a composição levaria 0,3 segundos. Essa assimetria importa quando você está processando batches de 50 milhões de linhas.
Pitfalls comuns que eu vi gente cair: usar split por delimitador fixo quando o dado tem delimitadores variantes. Se o seu campo composto usa barra como separador, mas alguns valores têm barras nos próprios dados (como "RUA_SANTA_Cruz/BA"), o split quebra. A solução é usar parsing posicional baseado em larguras fixas, não em delimitadores. Larguras fixas são mais trabalhosas de configurar, mas não quebram com dados sujos.
Limitações e quando NÃO usar esse método
atividade composição e decomposição não funciona bem com dados não estruturados. Se o campo que você quer decompor é livre-formulário, como "observações" ou "descrição", nenhuma regex ou parser vai capturar o significado sem análise semântica. Nesse caso, recomenda-se uso de modelos de linguagem ou classificação supervisionada, não decomposição estrutural. O bottleneck real: memórias RAM limitadas. Processar batches grandes de decomposição composto exige loading completo dos dados em memória. Se você tem 2 milhões de registros com campos compostos de 500 bytes cada, isso é 1 GB só para o staging area. Sem contar com os buffers intermediários de parsing. Meu workaround foi usar streaming chunked processing, dividindo o arquivo em partições de 50 mil linhas. Reduziu o peak memory de 1,2 GB para 180 MB, com queda de throughput de 15 mil rows/s para 8 mil rows/s. Trade-off aceitável.
Cenários onde o método falha completamente: dados com Encoding variante. Se o arquivo original usa ANSI para alguns campos e UTF-8 para outros, a decomposição por byte offset quebra. A solução é detectar encoding por BOM (Byte Order Mark) ou usar chardet para inferência automática. Eu gasto 0,5 segundos extras por arquivo nesse step, mas evito bugs de character corruption que levam horas para debuggar.
Download e recursos
Se você precisa de um template prático para atividade composição e decomposição, preparei um repositório com exemplos em Python, incluindo a função de parsing de endereços brasileiros que usei no projeto. O link está abaixo. O código está sob licença MIT, então pode usar, modificar e distribuir sem restrições. Recomendações finais: teste sempre com dados reais, não com samples sintéticos. Samples gerados artificialmente nunca capturam as bordas reais. E se possível, documente todas as variações que você encontrou durante a decomposição. Isso vira seu dicionário de mappings para os próximos projetos, economizando dias de trabalho repetido.
O tempo médio de implementação para um pipeline production-ready de composição e decomposição, considerando dados brasileiros com variações de endereço, é de 2 a 3 semanas para uma equipe sênior. Para júnior, dobre. Não subestime a complexidade dos edge cases, mesmo que a teoria pareça simples.
