Cantu reduz em 15% o erro de previsão de demanda com Glue, S3 e Databricks na AWS

A Cantu, distribuidora de pneus e suprimentos automotivos fundada em 2006, atende mais de 15 mil clientes a partir de mais de 240 unidades nas Américas, com marcas próprias como Speedmax e Gripmaster e a loja online PNEUSTORE. Com esse volume, prever quanto estoque comprar de cada item em cada ponto de venda virou um problema de engenharia de dados antes de ser um problema de modelo. O caso foi publicado no blog da AWS Brasil, com a consultoria A3Data como parceira de implementação.

O ponto de partida não era bonito. A empresa operava mais de 5.000 SKUs em mais de 40 filiais e centros de distribuição, nas cinco regiões do Brasil, com itens nacionais e importados sujeitos a sazonalidade e a choques macroeconômicos. O WMAPE (Weighted Mean Absolute Percentage Error, a métrica de erro de previsão ponderada pelo volume de cada item) estava em 62%. O ciclo para gerar uma previsão útil levava até duas semanas, e as previsões só existiam no nível de grupos de SKU, não por item e por unidade.

Por que o problema não era só matemático

Paulo Laurentys, COO da A3Data e sócio responsável pela implementação, resume onde estava a dificuldade real do projeto.

A complexidade vai muito além de aplicar um modelo matemático tradicional; trata-se de cruzar variáveis altamente voláteis e interdependentes. Exige também um saneamento de dados hercúleo, onde qualquer distorção no histórico pode resultar em falta de produto na ponta ou em um estoque milionário.

Paulo Laurentys, COO da A3Data

Essa frase explica a ordem das peças na arquitetura: antes de qualquer modelo de forecasting, veio o saneamento de dados. Sem cadastro confiável, qualquer algoritmo, por mais sofisticado, propaga o erro de origem.

AWS Glue entra antes do modelo, não depois

O AWS Glue foi usado para rodar jobs de ETL (Extract, Transform, Load) sobre os dados cadastrais das operações nacional e internacional, corrigindo falhas crônicas que vinham se acumulando desde a expansão geográfica da empresa. O resultado desse trabalho foi catalogado de forma estruturada, criando a base sobre a qual os modelos preditivos puderam operar com confiança.

É um detalhe que costuma ser subestimado em projeto de forecasting: a tentação é ir direto para o modelo, mas aqui o saneamento de dado cadastral foi tratado como pré-requisito de arquitetura, não como item de backlog posterior.

Um data lake único no Amazon S3

Com os dados tratados, o Amazon S3 passou a funcionar como data lake centralizado para os históricos de vendas e cadastros. Esse foi o componente que eliminou os silos entre operação doméstica e importação, fragmentação que antes impedia qualquer visão unificada do negócio.

Em resumo: antes do Glue e do S3, a Cantu simplesmente não tinha uma fonte única de verdade sobre o próprio histórico de vendas, o que tornava qualquer previsão de demanda, por melhor que fosse o algoritmo, uma aposta sobre dados incompletos.

Databricks sobre EC2, não SageMaker, para o processamento pesado

O processamento dos algoritmos preditivos para os mais de 5.000 SKUs rodou em Databricks hospedado sobre instâncias Amazon EC2, que absorveram a camada de computação. O Databricks abstraiu a complexidade de provisionar e escalar clusters de Big Data, permitindo processar previsões em paralelo em vez de sequencialmente.

Vale notar, para quem trabalha com Amazon SageMaker no dia a dia: a fonte não registra treinamento de modelo via SageMaker Training nem deploy via SageMaker endpoints nesta primeira fase. A camada de processamento distribuído ficou com Spark no Databricks rodando sobre EC2 puro. É um padrão comum em migração de pipelines de forecasting legados: primeiro resolve-se escala e qualidade de dado com a stack que a equipe já domina, e só depois se migra o ciclo de vida do modelo para um ambiente gerenciado de MLOps.

Step Functions e Lambda cortam o ciclo de duas semanas para seis horas

A automação do pipeline, que antes dependia de trabalho manual distribuído ao longo de semanas, veio da combinação de AWS Step Functions e AWS Lambda. O Step Functions orquestrou o pipeline de ponta a ponta, coordenando cada etapa com visibilidade e controle sobre o fluxo. O Lambda executou tarefas orientadas a evento, automatizando decisões pontuais do processo sem servidor dedicado.

Essa combinação é o que converteu o ciclo de forecast de um evento quinzenal manual em um fluxo que roda em horas, liberando a equipe de operações para interpretar o resultado em vez de produzi-lo.

Os números depois de cinco meses

A arquitetura completa, do saneamento de dado ao pipeline orquestrado, foi entregue em cinco meses. Os três indicadores que a Cantu monitorava mudaram de patamar nesse período.

A fonte atribui à queda do WMAPE um impacto financeiro de dezenas de milhões de reais, somando melhor fluxo de caixa na compra de itens, menos estoque excessivo parado, menos custo logístico desnecessário e menos ruptura de estoque na ponta. Manuela Nascimento, diretora de marketing da Cantu Inc., trata o resultado como ponto de partida, não como meta alcançada.

Alcançamos uma melhoria de 15% do nosso forecast em apenas 5 meses, um ganho inicial que já trará muito impacto positivo para nossa jornada. Acreditamos que esse resultado representa apenas um início. Vamos refinar a solução cada vez mais e buscar ainda mais excelência.

Manuela Nascimento, Diretora de Marketing da Cantu Inc.

Onde o SageMaker entra no roadmap

A evolução planejada pela Cantu é onde o caso volta a interessar diretamente quem opera modelos em produção. O Amazon SageMaker Unified Studio está previsto para assumir o ciclo de vida de MLOps: treinamento, deploy e monitoramento dos modelos de previsão de forma centralizada, evoluindo o que hoje é um pipeline de forecast orquestrado por Step Functions e Lambda para um conjunto de serviços gerenciados de IA.

Em paralelo, o roadmap prevê o Amazon Quick para dashboards de BI com insights gerados por IA para quem toma decisão na ponta, e o Amazon Bedrock para análises qualitativas de mercado, resumos de cenário macroeconômico e assistentes para a cadeia de suprimentos. Nenhum desses três componentes está detalhado com data de entrega ou métrica de resultado na fonte: são itens de roadmap, não entregas já medidas como a redução de WMAPE.

O que o caso não resolve

A fonte não informa em qual região AWS a carga roda, nem detalha custo de infraestrutura, nem o algoritmo de forecasting usado dentro do Databricks. Também não há benchmark comparando o desempenho desse pipeline com uma alternativa nativa em SageMaker Training ou SageMaker Canvas para a mesma carga de 5.000 SKUs, o que deixa em aberto se a escolha por Databricks sobre EC2 foi definitiva ou transitória até a maturidade do SageMaker Unified Studio no ambiente da empresa.

Fonte: AWS Brasil — Blog