Eram nove da manhã de uma segunda-feira quando o relatório de vendas apareceu a zero. Não tinha sido um mau fim de semana: era um ficheiro que não chegou. A origem falhou durante a noite, o pipeline correu na mesma sobre dados vazios e o painel mostrou, com toda a confiança, um número errado. Quem deu por isso foi o diretor comercial — não a equipa de dados.
Esta cena repete-se em muitas organizações e explica porque a observabilidade de dados deixou de ser um luxo. À medida que os dados passam por mais etapas — ingestão, transformação, modelos, relatórios — multiplicam-se os pontos onde algo pode partir em silêncio. E o problema mais caro não é o pipeline que falha com estrondo; é o que continua a correr e a produzir números plausíveis mas errados.
Observabilidade de dados é a prática de saber, a qualquer momento, se os dados em que confiamos estão saudáveis — e de ser avisado quando não estão, antes de a decisão errada já ter sido tomada. Este artigo explica o conceito, porque os testes tradicionais não bastam, quais os cinco pilares que a compõem e como começar sem ter de comprar já uma plataforma.
O que é a observabilidade de dados
O termo vem da engenharia de software. Em sistemas aplicacionais, observabilidade é a capacidade de perceber o estado interno de um sistema a partir dos sinais que ele emite: métricas, logs e traces. A observabilidade de dados pega nessa ideia e, em vez de vigiar utilização de CPU ou latência de pedidos, vigia a saúde dos próprios dados e dos pipelines que os movem.
O princípio é o mesmo: instrumentar o sistema para que ele conte o que se está a passar e detetar desvios cedo. Aplicada a dados, traduz-se em monitorizar continuamente sinais como a hora a que uma tabela foi atualizada, quantas linhas recebeu, se o esquema mudou e se a distribuição dos valores continua parecida com o habitual. Quando algum desses sinais foge ao padrão, alguém é avisado — de preferência antes do relatório.
Porque os testes não chegam
Muitas equipas já escrevem testes de dados: uma coluna não pode ter nulos, uma chave tem de ser única, um total tem de bater certo. São valiosos e devem existir. Mas os testes verificam aquilo que já sabemos que pode correr mal — os chamados known unknowns. Escrevemos uma asserção porque antecipámos o problema.
A realidade produz sobretudo unknown unknowns: a falha que ninguém previu. Uma origem que muda o formato de uma data, um fornecedor que começa a enviar valores em maiúsculas, uma junção que passa a duplicar linhas depois de uma alteração a montante. Não há teste escrito para isso, porque ninguém imaginou o cenário. A observabilidade cobre esse território: em vez de perguntar apenas se os dados passam nas regras que escrevemos, pergunta se estão diferentes do que costumam ser. Testes e observabilidade não competem — completam-se.
Os cinco pilares da observabilidade de dados
Uma forma amplamente usada de organizar o tema descreve cinco pilares. Juntos, cobrem a maioria dos sintomas de dados doentes:
- Frescura (freshness) — os dados estão atualizados? Quando foi a última vez que a tabela recebeu novas linhas?
- Volume — a quantidade está dentro do esperado? Um dia com metade das linhas habituais, ou com o dobro, é suspeito.
- Esquema (schema) — a estrutura mudou? Uma coluna que desaparece, muda de tipo ou é renomeada parte tudo o que vem a jusante.
- Distribuição — os valores continuam plausíveis? Um pico de nulos, um campo que passa a ter só zeros ou uma média que salta revelam problemas que a contagem de linhas não apanha.
- Linhagem (lineage) — como se ligam tabelas e relatórios entre si? É o mapa que permite ir do sintoma à causa e medir o impacto.
Nenhum pilar chega sozinho. Uma tabela pode estar fresca e com o volume certo, mas cheia de nulos por causa de uma alteração no esquema da origem. É a leitura combinada que dá confiança.
Frescura e volume: os sinais que mais cedo avisam
Frescura e volume são, muitas vezes, os alarmes mais úteis porque apanham as falhas mais frequentes — dados que não chegaram ou chegaram a menos. Monitorizar a frescura é comparar a hora da última atualização com a que seria de esperar: se a tabela costuma ser carregada até às 6h e às 8h ainda está com a de ontem, algo falhou.
O volume acrescenta uma segunda leitura. Um pipeline pode correr a horas e mesmo assim trazer só uma fração das linhas — por exemplo, porque a origem só exportou uma região. Definir bandas de normalidade para a contagem diária de linhas, com margem para a sazonalidade natural, transforma um silêncio perigoso num alerta acionável. Estes dois sinais, sozinhos, evitam uma parte considerável dos incidentes clássicos.
Esquema e distribuição: quando a forma dos dados muda
As alterações de esquema são das causas mais traiçoeiras de avarias. Alguém, três equipas a montante, renomeia uma coluna ou muda-lhe o tipo, e o pipeline ou rebenta ou — pior — preenche o campo com nulos sem se queixar. Vigiar o esquema significa registar a estrutura esperada e alertar quando colunas aparecem, desaparecem ou mudam de tipo.
A distribuição é mais subtil. Aqui olha-se para a forma dos valores: a percentagem de nulos, a proporção entre categorias, a média e a dispersão de um campo numérico, o número de valores distintos. Uma coluna de país que sempre teve vinte valores e passa a ter dois, ou um preço médio que triplica de um dia para o outro, são sinais de que algo mudou na origem — mesmo que o volume e a frescura estejam impecáveis. É a diferença entre saber que os dados chegaram e saber que os dados fazem sentido.
Linhagem: do sintoma à causa e ao impacto
Quando um alerta dispara, seguem-se duas perguntas: o que causou isto e quem é afetado? A linhagem responde às duas. Ao mapear como cada tabela deriva de outras e que relatórios dependem de cada tabela, é possível subir a cadeia até à origem do problema e, ao mesmo tempo, listar os painéis que devem levar um aviso de dados sob suspeita.
Sem linhagem, cada incidente é uma investigação do zero, feita a correr e sob pressão. Com linhagem, a análise de causa e a análise de impacto tornam-se quase imediatas. É também a linhagem que permite comunicar com transparência: avisar proativamente quem usa um relatório afetado gera muito mais confiança do que deixar que seja o utilizador a descobrir o erro.
Como começar sem comprar uma plataforma
Não é preciso adquirir uma ferramenta dedicada para dar os primeiros passos. Muito do valor obtém-se com consultas simples sobre os metadados que o próprio armazém já guarda. Uma verificação de frescura pode ser tão direta como comparar a data máxima de uma tabela com o momento atual:
SELECT MAX(data_carga) AS ultima, CURRENT_TIMESTAMP AS agora FROM vendas;
Uma verificação de volume compara a contagem do dia com a média recente:
SELECT COUNT(*) FROM vendas WHERE data_carga = CURRENT_DATE;
A partir daqui, o caminho é incremental: agendar estas consultas, guardar o histórico dos resultados, definir limiares e enviar um alerta quando são ultrapassados. Comece pelas tabelas mais críticas — aquelas de que dependem os relatórios que a gestão vê — e alargue a cobertura à medida que o valor se prova. Só quando o número de tabelas e de pipelines torna o esforço manual incomportável é que faz sentido avaliar uma plataforma dedicada, com deteção automática de anomalias.
Mini-caso: uma empresa de retalho que deixou de descobrir os erros pelos clientes
Considere-se uma empresa de retalho com uma dezena de lojas e um punhado de analistas. Os relatórios de vendas e de stock eram alimentados por vários pipelines noturnos. Cerca de uma vez por mês, um relatório aparecia errado — e, quase sempre, era um gestor de loja a reportá-lo, o que corroía a confiança em toda a plataforma de dados.
A equipa começou por instrumentar apenas as cinco tabelas mais importantes, com verificações de frescura e de volume e um punhado de regras de distribuição sobre campos críticos, como a percentagem de nulos no identificador de produto. Em três meses, o tempo médio de deteção de um problema caiu de mais de um dia para menos de uma hora, e a maioria dos incidentes passou a ser apanhada antes de chegar a um relatório. O número de erros reportados por utilizadores de negócio caiu para perto de zero.
O ganho não foi apenas técnico. Ao avisar proativamente que um painel podia estar afetado e estava a ser corrigido, a equipa de dados trocou a imagem de fonte de surpresas desagradáveis pela de um serviço fiável. A observabilidade pagou-se não em linhas de código, mas em confiança recuperada.
Métricas para provar o valor
Como qualquer investimento, a observabilidade deve mostrar resultados. Três métricas ajudam a contar a história. O tempo médio de deteção mede quanto se demora a descobrir um problema depois de ele acontecer; o tempo médio de resolução mede quanto se demora a corrigi-lo. Ambos devem descer à medida que a cobertura cresce.
A terceira é o tempo de indisponibilidade de dados (data downtime): o período em que os dados estiveram errados, em falta ou parciais, tipicamente estimado como o número de incidentes multiplicado pela soma dos tempos de deteção e de resolução. É uma medida honesta do risco a que o negócio esteve exposto — e a forma mais eloquente de justificar o esforço a quem decide o orçamento.
Na prática
A observabilidade de dados não é uma moda nem exige começar por comprar software. Começa por uma mudança de postura: assumir que os dados vão falhar de maneiras que não conseguimos antecipar e instrumentar os pipelines para que essas falhas se anunciem cedo, em vez de serem descobertas pelo cliente.
Escolha as tabelas de que mais depende, comece por vigiar frescura e volume, acrescente algumas regras de distribuição sobre os campos que mais doem quando falham e mapeie a linhagem que liga cada relatório às suas origens. É um investimento modesto no arranque e com um retorno claro: menos surpresas, decisões mais seguras e uma equipa de dados em quem a organização volta a confiar.
