BI Operacional

// visão geral

Esse projeto nasceu da limitação natural do anterior: uma coisa é servir dashboard direto de uma base operacional, outra é ter uma arquitetura de dados de verdade, com ingestão, transformação e consumo separados em camadas. Construí um pipeline ETL completo com orquestração automatizada e um Data Warehouse modelado em Star Schema — a diferença entre puxar dado quando alguém lembra e ter uma esteira de dados que roda sozinha, todos os dias, e é confiável o suficiente para alguém tomar decisão em cima dela sem checar duas vezes.

// arquitetura e fluxo

Cada etapa do ETL é uma DAG independente no Airflow, com retry configurado e alertas de falha — a extração não sabe nada sobre a transformação, a transformação não sabe nada sobre como o dado será consumido depois. Essa separação foi o ponto central do desenho: qualquer camada pode ser trocada ou reescrita sem quebrar as outras duas.

// decisões técnicas

Modelagem em Star Schema em vez de manter tabelas normalizadas replicadas do sistema de origem. A escolha reduz drasticamente a complexidade das queries analíticas — fato no centro, dimensões ao redor — e é o padrão que qualquer ferramenta de BI sabe consumir sem ginástica de JOIN. Airflow em vez de cron simples: preciso de idempotência, retry automático e visibilidade sobre qual execução falhou e por quê. Todo o ambiente containerizado com Docker desde o início, não como ajuste de última hora — o pipeline roda igual em desenvolvimento e em produção.

// desafios e soluções

Dado atrasado ou fora de ordem chegando na extração foi o problema mais recorrente. Resolvi com janelas de reprocessamento: a DAG identifica lacunas no histórico e reprocessa automaticamente o intervalo faltante, em vez de simplesmente seguir em frente com o dado incompleto. Outro desafio foi manter a transformação em Pandas performática conforme o volume cresceu — Pandas em memória tem limite. A solução foi particionar a extração por período, processando em lotes menores e mais previsíveis.

// impacto gerado

O time analítico passou a ter uma fonte única de verdade, atualizada automaticamente, em vez de cada pessoa puxando dado de um jeito diferente da base operacional — o que antes gerava número divergente em reunião. A API de consumo também abriu espaço para outras aplicações internas puxarem o mesmo dado padronizado, sem reinventar a extração.

// diferenciais técnicos

• Engenharia de dados ponta a ponta: ingestão, transformação e consumo como camadas independentes
• Orquestração automatizada com controle de falha e reprocessamento
• Modelagem dimensional (Star Schema) pensada para consulta analítica
• Ambiente containerizado, reproduzível e pronto para produção