Atualidade de Dados: SLAs, Monitoramento e Como Detectar Dados Velhos
Atualidade de dados mede o quanto um conjunto de dados ainda reflete o estado atual do mundo: é o tempo desde a última atualização comparado ao intervalo esperado. Um dado desatualizado não anuncia que está errado. A query roda, o dashboard carrega, e o número parece exatamente como parecia na semana passada. Em muitos casos, porque é o número da semana passada.
Por que dado desatualizado não aparece no dashboard
A maioria dos sistemas de orquestração reporta sucesso quando o job termina, não quando os dados chegam. Um pipeline que conclui em 3 minutos com zero linhas escritas aparece como "Success" no Airflow, no dbt Cloud e no Cloud Scheduler. A tabela de destino não muda. Nenhum erro dispara. O dashboard mostra o número anterior, que parecia razoável na semana passada e continua parecendo razoável hoje.
O padrão mais comum de falha silenciosa:
- Uma API de origem muda o formato de resposta ou rotaciona credenciais
- O pipeline roda e finaliza com sucesso, com zero linhas escritas ou linhas incorretas
- A métrica downstream repete o valor anterior ou vai a zero
- Nenhum alerta dispara porque nenhum threshold de tabela foi violado
- Um stakeholder percebe a anomalia numa reunião, horas ou dias depois
A velocidade de detecção é a única variável que separa um incidente de 10 minutos de um de 72 horas.
Atualidade vs. latência vs. pontualidade
Três propriedades de pipeline que parecem iguais mas medem coisas diferentes:
| Propriedade | O que mede | Exemplo de falha |
|---|---|---|
| Atualidade | Tempo desde a última atualização vs. o intervalo esperado | Tabela com ritmo horário não atualiza há 4 horas |
| Latência | Tempo entre o evento na origem e a disponibilidade no destino | Compra demora 45 min para aparecer no warehouse |
| Pontualidade | Se o dado estava disponível no prazo exigido pelo negócio | Tabela de receita não atualizou antes da revisão das 9h |
Uma tabela pode ser rápida (baixa latência) e estar desatualizada (o pipeline parou há três horas). Uma tabela pode ser pontual (atualizou antes das 9h) e mostrar eventos de seis horas atrás. Cada falha exige sua própria checagem.
Framework de SLA de atualidade de dados
Um SLA de atualidade é uma expectativa documentada: esta tabela deve atualizar no mínimo a cada X minutos e estar disponível com dados atuais até Y. Definir um requer conhecer o ritmo real da tabela e quando a desatualização causa um problema de negócio.
Esta tabela oferece SLAs de ponto de partida para os cinco tipos mais comuns. Ajuste ao comportamento real do seu pipeline.
| Tipo de tabela | Ritmo normal | SLA de atualidade | Frequência de checagem | Threshold de alerta |
|---|---|---|---|---|
| Eventos / clickstream | Contínuo | 30 minutos | A cada 15 min | Última linha > 45 min atrás |
| Pagamentos / transações | Horário | 2 horas | A cada 30 min | Última linha > 2,5 horas atrás |
| Agregados diários (receita, DAU) | Batch noturno | 25 horas | A cada 2 horas | Não atualizado até as 8h |
| Sync de CRM (clientes, contas) | A cada 4–6 horas | 8 horas | A cada 2 horas | Última linha > 10 horas atrás |
| Tabelas de referência / dimensão | Semanal ou sob-mudança | 8 dias | Diária | Não atualizado em 10 dias |
A regra central: defina o SLA em 1,5–2× o intervalo esperado, nunca em 1,0×. Uma tabela com ritmo horário deve alertar em 90–120 minutos, não em 61. Falsos positivos por variação normal treinam o time a ignorar alertas reais.
As quatro checagens de monitoramento de atualidade
Monitoramento de atualidade não é uma única checagem. É uma abordagem em camadas onde cada camada pega um modo diferente de falha.
updated_at ou created_at com o horário atual. Se o intervalo ultrapassar o SLA, alerte. É a checagem base: rápida de implementar, mas cega para tabelas sem coluna de timestamp confiável.Antes e depois: o que um alerta de atualidade previne
Um e-commerce de moda roda o pipeline de pedidos toda noite, com conclusão por volta das 2h. O time de growth revisa a dashboard de conversão às 9h da manhã.
Sem monitoramento de atualidade: Na terça à noite, um serviço de dependência fica indisponível das 1h30 às 2h20. O job inicia e finaliza com sucesso. Zero pedidos são escritos. O log registra "0 rows processed." Não um erro, apenas resultado vazio. Na quarta de manhã, a dashboard de conversão mostra o GMV da terça igual ao da segunda. O time de growth interpreta como queda de demanda e pausa duas campanhas de performance. Às 10h30, um engenheiro descobre a carga vazia ao montar um relatório diferente. Sete horas se passaram, com decisões de budget baseadas em dado errado.
Com monitoramento de atualidade: Às 2h05, um alerta no Slack dispara: "tabela orders recebeu 0 linhas nos últimos 60 minutos. Esperado 340 com base no baseline de terça à noite. Pipeline retornou sucesso. Causa provável: serviço de dependência. Query de diagnóstico em anexo." O engenheiro de plantão resolve até as 3h. A revisão das 9h usa dado correto. As campanhas nunca são pausadas.
O esforço de engenharia é idêntico nos dois cenários. A checagem de atualidade levou minutos para configurar e eliminou horas de resposta a incidente.
O que monitoramento de atualidade não pega
Uma tabela pode estar completamente atualizada (modificada há 4 minutos, dentro do SLA) e conter dados errados. A checagem de atualidade confirma que o pipeline rodou. Não confirma que os dados estão corretos.
O gap mais comum: uma mudança de schema upstream faz uma coluna-chave popular como nulo em 70% das linhas. O updated_at da tabela está atual. A contagem de linhas está normal. A checagem de atualidade passa. A taxa de nulos está em 70% e subindo, mas essa checagem nunca foi configurada.
Por isso observabilidade de dados requer cinco sinais trabalhando juntos:
- Atualidade: o pipeline rodou?
- Taxa de nulos: o dado chegou completo?
- Volume / contagem de linhas: chegou a quantidade esperada?
- Schema drift: a estrutura se manteve?
- Distribuição: os valores estão nas faixas esperadas?
Para tabelas que alimentam métricas críticas de negócio, monitore os cinco. Para tabelas de referência que raramente mudam, atualidade e volume geralmente são suficientes.
Como começar a monitorar atualidade de dados sem um time de dados
O setup mínimo viável requer uma conexão somente-leitura ao banco e cinco decisões:
- Escolha cinco tabelas críticas. As tabelas das quais suas métricas principais dependem. Não todas as tabelas: só aquelas onde a desatualização causa problema de negócio em horas.
- Confirme o ritmo real de atualização. Consulte os últimos 30 dias de timestamps para ver o padrão de fato. Uma tabela "diária" que na prática roda às 2h, 6h e meio-dia precisa de um SLA diferente de uma que roda uma vez à meia-noite.
- Defina "desatualizado o suficiente para importar." É uma decisão de negócio. Se a tabela de receita atrasar uma hora mas ninguém revisa antes das 9h, o SLA deve ser "não atualizado até as 8h," não "não atualizado em 61 minutos."
- Roteie alertas para onde o time já está. Slack para times assíncronos, PagerDuty para on-call. Um alerta que exige login em outra ferramenta às 2h da manhã não será acionado.
- Use baseline aprendido, não threshold fixo, para tabelas variáveis. Threshold fixo em dado cíclico dispara falsos positivos nos fins de semana. Um baseline que considera dia da semana e horário elimina o ruído que treina os times a ignorar alertas reais.
Veja como está a atualidade dos seus dados agora: o diagnóstico gratuito de 2 minutos dá uma nota A–F para atualidade e outras quatro dimensões, sem necessidade de cadastro. Compare também as ferramentas de observabilidade de dados disponíveis em 2026. O Tabkeel conecta somente-leitura em menos de dois minutos e começa a monitorar atualidade imediatamente. O plano Free monitora 10 tabelas, sem cartão.
Perguntas frequentes
O que é atualidade de dados?
Atualidade de dados (data freshness) é o tempo decorrido desde a última atualização de um conjunto de dados, comparado ao intervalo esperado. Uma tabela está atualizada quando recebeu novos dados dentro da janela esperada; está desatualizada quando não, mesmo que o pipeline tenha reportado sucesso.
O que é um SLA de atualidade de dados?
Um SLA de atualidade é uma expectativa documentada de com que frequência uma tabela deve ser atualizada e até quando deve estar disponível. Por exemplo: "a tabela de pagamentos deve atualizar no mínimo de hora em hora e conter dados das últimas 2 horas." SLAs devem ser definidos em 1,5–2× o intervalo esperado para evitar falsos positivos por variação normal.
O que são dados desatualizados?
Dados desatualizados são dados que não foram atualizados dentro da janela de atualidade esperada. As queries ainda rodam, os dashboards ainda carregam, mas os números refletem um estado do mundo que já não existe. O dado desatualizado mais perigoso passa em todas as checagens padrão de qualidade de dados enquanto está horas ou dias defasado.
Como detectar dados desatualizados automaticamente?
Duas checagens confiáveis: (1) compare o timestamp mais recente da tabela com o horário atual e alerte quando o intervalo ultrapassar o SLA; (2) conte as linhas inseridas numa janela de tempo e alerte quando zero linhas chegarem num período que normalmente tem atividade. A segunda checagem pega o sucesso silencioso (o pipeline roda sem erro mas não escreve nada) que a checagem de timestamp não detecta.
Qual a diferença entre atualidade e latência de dados?
Latência de dados é o tempo entre um evento ocorrer e esse evento aparecer no destino. Atualidade de dados é se o dado atualizou dentro do intervalo esperado, independente da velocidade do pipeline. Um pipeline rápido ainda produz dado desatualizado se parou de rodar. Um pipeline lento produz dado atual se rodou no horário certo.
Artigos relacionados
Observabilidade de Dados: Os 5 Pilares e Por Onde Começar
Observabilidade de dados monitora a saúde dos seus dados em cinco pilares (frescor, volume, distribuição, schema e linhagem) para você detectar problemas em minutos, não em dias.
Qualidade de Dados para Startups: Guia Prático de Monitoramento
Qualidade de dados para startups é saber quando um número no seu dashboard está errado antes de uma decisão ser tomada. Aprenda os 6 modos de falha, a cascata de nulos e como começar com 3 tabelas.
Observabilidade de Dados: Open Source ou Ferramenta Paga? (E a Opção Gratuita que Ninguém Menciona)
Observabilidade de dados: open source ou pago? Quatro opções reais, o custo real de cada uma e um checklist de 5 perguntas para decidir.