Total, temporal ou incremental: a escolha que decide se o seu faturamento fecha

O faturamento do mês no dashboard não bate com o do ERP. A diferença tem cara de linha repetida: alguns pedidos aparecem duas vezes, sempre os que foram alterados depois de emitidos. Ninguém recebeu erro, nenhuma tela ficou vermelha, e o time de dados jura que a carga rodou todo dia.

Rodou mesmo. A execução está correta. O que está errado é uma configuração de uma linha, escolhida no primeiro dia do projeto e nunca revisada depois: o tipo de carga.

Vale entender essa configuração mesmo sem ser a pessoa que a configura. Ela é a diferença entre o número que fecha e o número que você vai defender na reunião sem saber que está errado.

A única pergunta que o tipo de carga responde

Todo fluxo que grava no warehouse tem um tipo de carga, e ele responde a uma pergunta só: a cada execução, o que o fluxo apaga antes de inserir os dados novos?

São três respostas possíveis, e não existem outras (Tipos de Carga):

Tipo	O que apaga antes de inserir
Total	tudo. A tabela é esvaziada e recarregada
Temporal	só as linhas dentro de uma janela de datas
Incremental	nada. Só insere ou atualiza

Total: apaga tudo e traz tudo de novo

A cada execução, a tabela é esvaziada e reescrita inteira. É a única das três que não tem como duplicar registro, porque o resultado depende só da última execução.

O preço é reprocessar a origem inteira toda vez. Numa tabela de cidades, de categorias ou de plano de contas, isso não custa nada. Numa tabela de vendas com anos de histórico, custa a madrugada toda e uma discussão com a TI sobre o peso no banco do ERP.

Use quando: a tabela é de cadastro ou de referência, pequena e sem coluna confiável de data.

Temporal: apaga uma janela de datas e reescreve só ela

A carga recarrega um intervalo, por exemplo os últimos trinta dias. Ela apaga as linhas cuja data cai dentro da janela e insere de novo o que a origem devolveu para aquele mesmo período. Fora da janela, o histórico não é tocado.

É o tipo padrão para tabela grande de fato, e o motivo é operacional: correção retroativa acontece. O pedido de terça é cancelado na quinta, a nota é reemitida na sexta, e a janela dos últimos trinta dias absorve essas mudanças sem reprocessar cinco anos de histórico.

Para funcionar, a consulta de origem precisa filtrar pela mesma janela. A plataforma injeta as datas de início e fim no fluxo, e o nó de extração usa essas variáveis dentro do SQL. Se o nó não usar, o fluxo traz a base inteira e a janela deixa de filtrar qualquer coisa na origem.

Use quando: a tabela é de fato, é grande, e tem uma data que não muda depois de gravada.

Incremental: não apaga nada, só traz o que é novo

A carga guarda o maior valor já visto de uma coluna de rastreio, tipicamente updated_at ou created_at, e na execução seguinte pede à origem só o que veio depois daquele ponto. A primeira execução carrega tudo, porque ainda não existe ponto anterior.

É o que menos pesa na origem, porque pede só o que mudou desde ontem. Também é o que mais aparece configurado errado, pelo motivo da próxima seção.

Use quando: a tabela é um log de eventos, ou um registro que muda de status ao longo da vida (pedido, chamado, título a receber).

O outro lado do contrato: a tabela

O tipo de carga é uma propriedade do fluxo, mas metade do resultado depende da tabela de destino. Duas configurações dela importam para você:

• Chave única. Se a tabela declara quais colunas formam a chave (o número do pedido, por exemplo), a linha nova substitui a antiga com a mesma chave. A última carga vence.
• Sem chave única. A linha nova é acrescentada e a antiga permanece.

Essas duas configurações são a diferença entre atualizar um pedido e ter dois pedidos.

As duas armadilhas que aparecem no fechamento

Rastrear alteração sem chave única. É a armadilha do começo deste texto. A carga incremental por updated_at traz o pedido toda vez que ele é alterado. Sem chave única na tabela, cada alteração vira uma cópia nova, e o faturamento cresce sozinho. O mesmo pedido alterado quatro vezes vira quatro linhas.

Usar uma data que muda como janela da carga temporal. A janela precisa ser presa a uma data imutável: data de emissão, data de venda, data de criação. Se alguém escolher a data de vencimento, que muda quando o cliente renegocia, o efeito é o seguinte: a carga apaga a janela antiga, insere o registro na janela nova, e a linha antiga fica parada numa janela que ninguém mais vai apagar. Duplicata de novo, e dessa vez espalhada pelo histórico.

O quadro de escolha

Este é o quadro que vale imprimir e levar para a conversa com quem monta os seus fluxos:

Cenário	Tipo	Coluna de controle	Chave
Cadastro pequeno (cidades, categorias, plano de contas)	Total	nenhuma	sem chave única
Fato grande com data imutável (vendas, faturamento)	Temporal	data_emissao	chave única
Log ou evento que só acumula	Incremental	created_at	sem chave única
Registro que muda (pedido, chamado, contas a receber)	Incremental	updated_at	chave única

As três perguntas que você faz sem ser técnico

Na próxima conversa sobre a tabela que não fecha, estas perguntas chegam à causa mais rápido que qualquer print de dashboard:

1. Qual é o tipo de carga desta tabela, e qual coluna controla a janela? Se a resposta for uma data que a operação altera, a duplicata já tem endereço.
2. Esta tabela tem chave única? Numa tabela de pedidos rastreada por alteração, a resposta precisa ser sim.
3. Quando foi a última carga total desta tabela? Uma carga total pontual reconstrói a tabela do zero e é o jeito mais direto de saber se a diferença é histórico sujo ou erro do dia a dia. Ela pode ser disparada na hora, mesmo num fluxo configurado como temporal (Execução e Agendamento).

Escolher o tipo de carga leva dez minutos no começo do projeto. Descobrir a escolha errada leva o tempo entre o fechamento de dois meses, com uma reunião de diretoria no meio.

A escolha do tipo de carga é um campo na tela do HorusETL, e o histórico fica no HorusDW.