Um dos blocos da Plenária Tecnologia & Inovação trouxe um case denso de engenharia de dados aplicada à logística de e-commerce — tema que interessa diretamente a quem lida com pipelines, data lakes e decisões orientadas a dado em escala.
O ponto de partida do palestrante foi um diagnóstico comum a muitas empresas que cresceram rápido: uma arquitetura pensada quando a companhia era "10 vezes menor" e que foi remendada ao longo de 8 anos sem nunca ser revisada de ponta a ponta. O resultado: informações fragmentadas, times com bases de verdade divergentes e um retrabalho gigantesco de reconciliação.
Da arquitetura legada ao Lakehouse
A stack antiga rodava sobre Redshift como warehouse, com ferramentas de ingestão legadas e mais de 110 jobs/tags fazendo captura e transformação de dados — incluindo full scans diários direto nas tabelas de produção, gerando concorrência de I/O e degradação de aplicações críticas.
A migração, apoiada por um parceiro especializado indicado pelo provedor de cloud, levou a companhia para uma arquitetura em camadas (bronze, silver, gold) usando ferramentas como Datastream, Dataflow, BigQuery, Cloud Composer e Dataplex. A principal mudança técnica foi trocar cargas batch D-1 por Change Data Capture (CDC) contínuo, lendo o binlog dos bancos em vez de escanear tabelas inteiras.
"Eu deixo de ser uma latência diária, exceção D-1, eu começo a ter um CDC contínuo, trazendo dados em minutos para o que se faz necessário na companhia."
Os números do antes/depois chamam atenção: de 110 tags para 22, de cerca de 5 componentes de orquestração para 2, e um tempo médio de disponibilização de dado de 15 minutos via 13 streams ativos replicando 99 tabelas.
Nem tudo em real time — e isso é proposital
Um alerta útil para times de dados: nem toda informação precisa de latência mínima. O palestrante defendeu um modelo híbrido, decidindo caso a caso entre tempo real, algumas horas ou D-1/D-7/D-30, já que latência menor custa mais caro em ambientes de nuvem:
"Existe uma regra dentro de dados: quanto mais rápido você tem informação no Lakehouse, mais caro isso custa para a companhia."
Resultados e lições para quem for migrar
Entre os ganhos relatados: menor carga em produção, dados mais confiáveis para bots de atendimento (com nota superior à do atendimento humano), reprogramação de entregas em caso de imprevistos, e um ganho de 3 pontos percentuais no SLA de entrega — métrica acompanhada semanalmente pelo corpo executivo.
O processo não foi indolor: houve erros de arquitetura logo no início, curva de aprendizado do time em ferramentas novas e o desafio de manter dois mundos coexistindo — o legado e o novo — durante a transição gradual, começando pela área de logística antes de expandir para o resto da companhia.
Para times de engenharia de dados brasileiros enfrentando arquiteturas legadas e crescendo em complexidade, o case reforça uma lição prática: migração incremental, começando pela área de maior dor, tende a ser mais sustentável do que uma reescrita completa de uma vez.