Delivery Audit & Intelligence Platform: pipeline de dados, auditoria operacional e analytics

A maioria dos projetos de dados mostra volume em dashboards. Menos frequentes são os que mostram onde a operação deixa de cumprir regra de negócio — e quanto isso custa.

A Delivery Audit & Intelligence Platform é um estudo de caso de engenharia de dados que simula uma operação de delivery e leva eventos operacionais a um fluxo auditável: camadas analíticas, regras explícitas de qualidade ligadas ao negócio e métricas que sustentam priorização (por loja, turno, tipo de falha).

O problema: dado existe, controle é que não

Operações de delivery geram alto volume de registros: pedidos, transições de status, pagamentos, cancelamentos. Ter dado bruto, porém, não implica governança nem acionabilidade.

Na prática aparecem padrões como:

• atrasos sem causa clara na cadeia de eventos;
• cancelamentos com custo difícil de consolidar;
• desalinhamento entre visão operacional e financeira;
• indicadores de volume sem vínculo com falha ou SLA;
• dashboards que descrevem o “quanto”, mas pouco o “onde quebrou”.

O efeito é previsível: os dados não sustentam decisão com confiança.

Objetivo do projeto

Construir um pipeline de dados para delivery que:

1. ingira dados simulados de forma controlada (API);
2. organize o dado em arquitetura em camadas, até consumo analítico;
3. aplique auditoria operacional com regras explícitas;
4. produza métricas confiáveis e comparáveis no tempo;
5. permita identificar falhas e estimar impacto financeiro por tipo de evento.

Arquitetura da plataforma

O desenho segue um padrão familiar de engenharia de dados (ingestão → refinamento → consumo), com um ponto de atenção explícito: a auditoria não é um adendo opcional — é parte central do desenho.

graph LR
  A[API Mock] --> B[Ingestão]
  B --> C[Bronze]
  C --> D[Silver]
  D --> E[Gold]
  E --> F[Motor de auditoria]
  F --> G[Analytics / dashboards]

A camada de auditoria consome o dado já estruturado (tipicamente a partir de Gold ou de artefatos derivados) e materializa flags, severidades e atributos de negócio que alimentam análise e priorização.

Ingestão: API mock com FastAPI

Para aproximar um ambiente real sem depender de sistemas legados fechados, a fonte é uma API mock construída com FastAPI, responsável por expor e gerar entidades e eventos:

• pedidos e linha do tempo de status (aceite, preparo, rota, entrega);
• pagamentos e estados associados;
• cancelamentos e motivos;
• cadastros de apoio: clientes, lojas, entregadores.

Isso permite cenários reproduzíveis (incluindo injeção controlada de falhas), essenciais para validar regras de auditoria e o pipeline de ponta a ponta.

Pipeline em camadas: Bronze, Silver e Gold

Bronze — dados brutos

• ingestão próxima ao que a API entrega;
• mínima transformação, preservação de histórico;
• base para rastreabilidade e reprocessamento.

Silver — dados tratados

• normalização de schema e tipos;
• deduplicação e resolução de conflitos básicos;
• enriquecimentos que facilitam joins e métricas downstream.

Gold — camada analítica

• tabelas orientadas a consumo (relatórios, BI, agregações);
• KPIs e fatos consolidados;
• contratos mais estáveis para o time de analytics.

Modelagem: esquema dimensional

A modelagem segue abordagem dimensional, adequada a cortes por loja, tempo, cliente e entregador.

Fato principal: fact_orders

Grão: uma linha por pedido.

Campos típicos incluem:

• chaves surrogate/naturais (pedido, loja, cliente, entregador);
• timestamps por etapa da jornada;
• medidas financeiras e operacionais;
• métricas derivadas (tempos entre etapas, flags pré-calculadas quando fizer sentido).

Dimensões

• dim_store — geografia, cluster operacional, atributos da loja;
• dim_customer — segmentação e comportamento agregado;
• dim_courier — carga e desempenho logístico;
• dim_date (e, se necessário, dimensão de turno) — sazonalidade e comparativos temporais.

Camada de auditoria: qualidade de dados no vocabulário do negócio

Em vez de limitar a qualidade a checks genéricos (“não nulo”, “único”), o projeto implementa um motor de auditoria operacional: regras nomeadas, com severidade e vínculo com impacto estimado.

Exemplos de regras:

• atraso acima do limite no aceite pelo restaurante;
• tempo de preparo fora do padrão contratual;
• violação de SLA de entrega;
• cancelamento após início de preparo (alto custo de desperdício);
• inconsistência entre valor cobrado, taxas e status de pagamento;
• sequência de eventos inválida (ex.: entrega antes de despacho);
• pedido sem entregador alocado em janela crítica.

Exemplo de registro de auditoria

Cada ocorrência pode ser materializada como um registro estruturado, consumível por APIs downstream ou por camadas de BI:

{
  "order_id": "987",
  "flag_type": "cancel_after_prep",
  "severity": "high",
  "estimated_loss": 22.5
}

O importante não é o JSON em si, mas o contrato: tipo de falha, gravidade e dimensão financeira aproximada — o que permite priorizar correções e acompanhamento.

Métricas geradas

Com fato, dimensões e flags de auditoria alinhados, é possível reportar em três níveis complementares:

Operacional — tempo médio por etapa, taxa de cancelamento, aderência a SLA, backlog por loja.

Auditoria — volume e taxa de inconsistências por tipo de flag, distribuição por turno e por região, tendência temporal após mudanças de processo.

Financeiro — perda operacional estimada agregada, ranking por tipo de falha e por unidade, sensibilidade a premissas de custo unitário.

Stack utilizada

• Python — orquestração de transformações e regras;
• FastAPI — API mock e exposição de eventos;
• Pandas — manipulação tabular em etapas de preparação;
• Parquet — armazenamento colunar eficiente entre camadas;
• DuckDB — consultas analíticas locais e prototipagem de agregações;
• Streamlit — camada rápida de exploração e narrativa para stakeholders.

A escolha prioriza reprodutibilidade e baixo atrito para iteração; em produção, os mesmos conceitos migrariam para orquestradores, warehouse e ferramentas de observabilidade já adotados pela organização.

Código e repositório

O código-fonte, a API mock, o pipeline (Bronze → Silver → Gold → auditoria), os dashboards Streamlit e a documentação (docs/architecture.md, docs/data_model.md, docs/audit_rules.md) estão no repositório público Raphaeldaysc/Delivery-Projeto.

Aprendizados principais

1. Dado “limpo” não basta — sem semântica de negócio e rastreabilidade de falha, o time ainda não decide com segurança.
2. Qualidade de dados é decisão de produto e operação — severidade e custo estimado colocam engenharia e negócio na mesma mesa.
3. Auditoria muda o papel do analytics — de descritivo para priorização e acompanhamento de correções.
4. Arquitetura e contratos valem mais que a ferramenta do momento — stack facilita, mas camadas e grão bem definidos sustentam evolução.

Evoluções possíveis

• alertas próximos ao tempo real sobre flags críticas;
• detecção de anomalias sobre séries operacionais;
• integração com fontes reais (ERP, PDV, apps de logística);
• data contracts entre produtores e consumidores do dado;
• monitoramento contínuo de qualidade (SLAs de freshness e taxa de erro por regra).

Conclusão

Pipeline não é fim em si: é meio para garantir que o dado represente a operação, seja auditável e reduza incerteza na decisão.

A Delivery Audit & Intelligence Platform foi desenhada nessa linha: transformar eventos operacionais de delivery em inteligência acionável — porque, no fim, o ativo não é o dado bruto; é a decisão que ele permite tomar com rigor.