Seção: Dicas Rápidas
Tem um hábito muito comum em time de dados que passa sensação de controle, mas abre espaço para erro silencioso: validar a atualização da base olhando só o MAX(data).
A query roda, devolve a data de hoje e alguém conclui: “a carga está em dia”. Só que, no mundo real, essa conclusão costuma ser cedo demais.
Já vi tabela com MAX(data) certo e metade do volume faltando. Já vi partição de uma loja chegar e a de outras nove atrasar. Já vi evento de conversão entrar antes da receita consolidada e o dashboard parecer “atualizado” com a parte mais sensível incompleta.
O ponto é simples: ter a data mais recente não prova que o lote chegou inteiro.
O falso sinal verde
Este é o check mais comum:
SELECT MAX(data_referencia) AS data_mais_recente
FROM fato_vendas;
Se o resultado vier 2026-06-15, muita gente relaxa. Mas essa query só responde uma pergunta: existe pelo menos um registro com essa data?
Ela não responde outras, que costumam importar mais:
- chegou o volume esperado?
- todas as partições daquele dia foram carregadas?
- todas as fontes críticas já escreveram?
- o lote terminou ou só começou?
É por isso que MAX(data) funciona bem como termômetro inicial, mas mal como validação final.
Onde isso costuma quebrar
Esse falso conforto aparece bastante em três cenários:
1. Carga parcial do dia
O job começa a escrever cedo, uma parte entra, outra falha ou atrasa. A tabela já mostra a data mais nova, mas ainda não representa a operação inteira.
2. Partição ou origem faltando
Uma região, canal, loja, sistema ou arquivo do dia não chegou. Como alguma outra fatia escreveu normalmente, o MAX(data) continua bonito.
3. Tabela final atualizada com insumo incompleto
Às vezes o pipeline principal roda no horário certo, mas uma fonte dependente chegou pela metade. A tabela final foi reconstruída, só que em cima de um insumo incompleto. Visualmente, parece tudo em dia. Analiticamente, não está.
O trio de checks que fecha melhor
Quando a base é relevante para decisão, eu prefiro combinar três perguntas rápidas.
1. O volume do dia está plausível?
Não precisa acertar o número exato, mas precisa bater com uma faixa coerente.
SELECT
data_referencia,
COUNT(*) AS linhas,
SUM(valor_total) AS receita
FROM fato_vendas
WHERE data_referencia >= CURRENT_DATE - INTERVAL '7 day'
GROUP BY 1
ORDER BY 1 DESC;
Se hoje tem a data certa, mas 20% do volume normal, a carga não está “ok”. Ela está aparentemente fresca e materialmente incompleta.
2. Todas as partições esperadas chegaram?
Se a base depende de canal, loja, país, arquivo, tenant ou outro recorte operacional, esse check evita um erro clássico: uma fatia entrou, outra não.
SELECT
data_referencia,
COUNT(DISTINCT loja_id) AS lojas_presentes
FROM fato_vendas
WHERE data_referencia >= CURRENT_DATE - INTERVAL '3 day'
GROUP BY 1
ORDER BY 1 DESC;
Se normalmente você tem 42 lojas e hoje só aparecem 31, o MAX(data) não merece confiança ainda.
3. O lote crítico terminou de verdade?
Aqui vale usar o que existir na sua operação: batch_id, nome de arquivo, timestamp de ingestão, quantidade de registros por fonte, contagem de pedidos únicos, ou outro marcador que prove completude.
SELECT
origem,
COUNT(*) AS registros,
MAX(ingested_at) AS ultimo_recebimento
FROM staging_pedidos
WHERE data_referencia = CURRENT_DATE
GROUP BY 1
ORDER BY 1;
Às vezes o melhor indicador não é a data da tabela final. É saber se as origens críticas realmente terminaram de chegar.
O erro de gestão que nasce daí
O problema não é só técnico. Ele vira problema de decisão muito rápido.
Se o time olha um dashboard “atualizado” às 9h e redistribui verba, aciona operação ou reporta queda de receita antes da carga fechar, você criou ruído com cara de evidência.
Esse é um ponto que separa análise operacional de análise confiável: não basta o dado existir; ele precisa estar suficientemente completo para sustentar a leitura.
Uma regra curta que ajuda bastante
Eu costumo resumir assim:
MAX(data)prova presença.- volume prova plausibilidade.
- cobertura prova completude operacional.
Quando os três passam, a confiança sobe bastante. Quando só o primeiro passa, eu trato como sinal amarelo, não como liberação.
Resumo direto
Validar carga só com MAX(data) é confortável porque é rápido. Mas rapidez não deveria ser confundida com segurança.
Se a base alimenta relatório, dashboard, rotina comercial ou decisão de operação, vá um passo além. Confira se o volume faz sentido, se as partições esperadas chegaram e se o lote realmente terminou.
Em dados, muita base “atualizada” ainda está incompleta. E esse detalhe costuma aparecer só depois que alguém já decidiu em cima dela.
Se quiser aprofundar esse raciocínio, estes conteúdos ajudam na sequência:
