Resposta curta
A engenharia por baixo do painel: ingestão idempotente por fonte, histórico preservado para comparar com o ano passado, métrica em código com teste, e linhagem do indicador até a coluna de origem. Relatório lendo o banco de produção funciona até a empresa crescer. Depois concorre com quem está operando.
Relatório lendo produção é dívida com juros
O primeiro painel quase sempre nasce apontando direto para o banco do ERP, porque funciona na sexta-feira em que foi feito. O custo aparece depois: a consulta pesada concorre com quem está operando e a lentidão chega no fechamento, exatamente quando a carga de leitura e a de escrita disputam o mesmo recurso.
O segundo problema é silencioso. Banco de produção guarda o estado de agora, não a série: quando um cadastro muda de categoria, o valor antigo é sobrescrito. Meses depois, ninguém consegue reproduzir o número que foi apresentado, porque o registro que o gerava não existe mais naquela forma.
O terceiro é de manutenção. Sem uma camada de transformação, a regra de cálculo se espalha entre a consulta salva no BI, a macro da planilha e o campo calculado da ferramenta. Mudar a definição vira uma caçada, e as versões divergem sem que nada acuse.
Como fazemos
Inventário das fontes e do modo de extração
Cada sistema entra pelo caminho que ele suporta: captura de mudança quando o banco expõe log de transação, API paginada quando há limite de requisição, carga cheia quando a tabela é pequena. Escolher errado aqui aparece semanas depois, como janela de carga que não fecha.
Ingestão idempotente, com histórico
A carga pode rodar duas vezes sem duplicar e ser reprocessada de uma data sem sujar o resto. Dimensão que muda com o tempo é historizada em vez de sobrescrita, que é o que torna a comparação com o ano passado possível de verdade.
Camadas de modelagem separadas
Bruto, intermediário e consumo ficam em camadas distintas: a primeira reproduz a origem sem opinião, a segunda concentra a regra de negócio, a terceira serve o painel. Sem essa divisão, corrigir uma regra obriga a mexer em consulta que também faz extração.
Teste de dado, não só de código
O pipeline valida o que passa por ele: chave única, referência que existe, campo obrigatório preenchido, total que bate com a origem. Erro de dado não estoura exceção sozinho: sem asserção, ele chega ao painel com aparência de número normal.
Linhagem e frescor expostos
Cada indicador tem caminho rastreável até a tabela e a coluna que o originaram, e todo painel carrega o horário da última carga bem-sucedida. Quando a carga falha, o aviso sai antes de alguém decidir em cima de dado velho.
O que você recebe
- Ingestão idempotente por fonte, com reprocessamento por intervalo de data
- Camadas bruto, intermediário e consumo, versionadas no repositório
- Suíte de testes de dado rodando a cada carga, com falha bloqueante
- Linhagem do indicador até a coluna de origem
- Carimbo de frescor no painel e alerta de carga falha
- Documentação gerada do próprio modelo, sem virar página desatualizada
Com o que trabalhamos
Perguntas frequentes
Dá para rodar sem data warehouse, direto numa réplica?
Dá, e para operação pequena é uma escolha razoável: réplica de leitura já tira a consulta pesada de cima de quem opera. O limite aparece quando começa a ser preciso guardar histórico que a origem sobrescreve, ou juntar fonte que não é banco. Réplica resolve concorrência; não resolve historização nem integração.
Como vocês tratam exclusão de registro na origem?
Depende de como a origem apaga. Quando há exclusão lógica, o campo é lido e o registro fica marcado sem sumir. Quando a exclusão é física, a reconciliação por intervalo detecta a ausência e marca o registro como encerrado no destino. Apagar em cascata no warehouse é o caminho mais rápido para perder série histórica sem perceber.
O que acontece quando o esquema da origem muda?
Coluna nova entra sem quebrar. Coluna removida ou com tipo alterado faz o teste falhar e a carga parar, de propósito: seguir com conversão implícita é como um número errado entra num painel sem nenhum aviso. O alerta aponta a tabela e a coluna que mudaram.
Precisamos de um time de dados para manter isso?
Não. As transformações são SQL versionado no repositório e a orquestração roda sozinha, com alerta quando falha. Quem já mantém o sistema consegue mexer numa métrica lendo o modelo. Time dedicado passa a fazer sentido quando as fontes se multiplicam, não no começo.