Processando 1,5 Bilhão de Registros por Dia em Escala de Petabyte

O Desafio

Esta empresa opera uma das maiores plataformas independentes de publicidade do mundo, alimentando campanhas de retargeting, prospecção e e-mail marketing para milhares de empresas globalmente.

O Time de Dados era responsável pela infraestrutura que processava, transformava e servia os dados por trás de todas as decisões de otimização de publicidade. A escala era impressionante:

• 1,5 bilhão de registros ingeridos por dia provenientes de impressões de anúncios, cliques, conversões e eventos de atribuição
• Armazenamento de dados em nível de petabyte distribuído em múltiplos data stores e camadas de processamento
• Requisitos de tempo real — os modelos de otimização de publicidade precisavam de dados atualizados para tomar decisões de lance em milissegundos
• Sensibilidade a custo — nessa escala, até pequenas ineficiências no processamento se traduzem em gastos significativos em nuvem

O desafio principal não era apenas lidar com o volume. Era construir sistemas que pudessem processar dados nessa escala de forma confiável, com bom custo-benefício e rápido o suficiente para alimentar decisões de negócio em tempo real.

Minha Função & Abordagem

Entrei no Time de Dados como Engenheiro de Software de Dados, trabalhando principalmente com Scala, Java, JavaScript e Python em toda a stack de pipelines.

Arquitetura de Pipeline

Construí e mantive pipelines de dados ao longo de todo o ciclo de vida do dado — ingestão de eventos de ad exchange, transformação e enriquecimento, agregação para relatórios e entrega para consumidores downstream, incluindo os modelos de ML que alimentavam a otimização de publicidade.

A stack era majoritariamente baseada em AWS: EMR (Hadoop/Spark) para processamento em lote, S3 para armazenamento, DynamoDB para entrega de baixa latência, RDS para dados relacionais e Lambda e Batch para orquestração e processamento orientado a eventos.

Engenharia de Performance

Em escala de petabyte, engenharia de performance não é opcional — é sobrevivência. Trabalhei extensivamente em:

• Otimização de shuffle — dimensionamento de partições, estratégias de join e otimizações de broadcast para manter os jobs Spark saudáveis e com bom custo-benefício
• Gerenciamento de memória — diagnosticando e resolvendo erros de OOM, configurando comportamento de spill-to-disk e ajustando alocação de memória para grandes joins
• Otimização de custo — refatorando pipelines para reduzir o tempo de execução dos clusters EMR, otimizando padrões de armazenamento no S3 e dimensionando corretamente os recursos de computação

Confiabilidade em Escala

Quando seus pipelines processam 1,5 bilhão de registros diariamente, falhas têm impacto imediato no negócio — dados desatualizados significam lances de anúncio subótimos, o que significa receita perdida para milhares de clientes. Foquei em construir pipelines que não eram apenas rápidos, mas resilientes: processamento idempotente, recuperação automatizada, monitoramento abrangente e alertas que detectavam problemas antes que eles se propagassem.

Resultados

A infraestrutura de dados que ajudei a construir e manter foi a fundação de todo o motor de otimização de publicidade da plataforma — cada decisão de lance, cada cálculo de atribuição, cada relatório de campanha passava por esses pipelines.

Stack Técnica

Conclusão Principal

Trabalhar nessa escala me ensinou que engenharia de dados em nível de petabyte é fundamentalmente sobre economia e confiabilidade, não apenas tecnologia. Cada decisão arquitetural — estratégia de particionamento, formato de armazenamento, cadência de processamento — tem um impacto direto em custo e confiabilidade. O melhor pipeline não é o mais sofisticado; é aquele que roda previsivelmente, se recupera de forma elegante e custa o que você espera que custe.

Essa experiência é a fundação de como abordo cada projeto de arquitetura de dados hoje: começar pelas restrições (escala, latência, custo, confiabilidade) e então trabalhar de trás para frente até o design mais simples que as atenda.