Observabilidade de Dados: Rompendo o ciclo de apagar incêndios

O profissional de dados que nunca recebeu uma mensagem como essa que atire a primeira pedra!

Antes de mais nada, quero te explicar o porquê isso é um problema maior do que você pensa…

Quando recebemos uma mensagem como essa, estamos gastando o recurso mais escasso que os times de dados possuem: a confiança.

Imagine que o gerente do time comercial (vamos chamá-lo de João) nos avisou que o principal dashboard da área dele está quebrado. O João bem provavelmente tem que dar conta de muita coisa, e por consequência sua agenda é bem apertada. Quando ele acessa algum produto do time de dados, ele não só precisa da informação que o dashboard em questão deveria apresentar, mas precisa também tomar alguma ação em cima dessa informação. Afinal de contas isso é ser data-driven, certo? Tomar decisões e ações baseadas em dados.

Existem ações que podem ser realizadas sem o input de dados, mas outras, como a realização do pagamento de comissões do time comercial, bem provavelmente irão sofrer bloqueio até que o time de dados resolva o problema.

Veja que nessa situação hipotética, além de deixar o João "na mão", interrompemos bruscamente a jornada dele, causando um atrito que ainda pode piorar muito durante o processo de resolução desse ticket, mas isso é papo para outro artigo.

Casos como o do João são recorrentes. De acordo com uma pesquisa feita por Dun & Bradstreet (The Past, Present and Future of Data), 42% das empresas já enfrentaram problemas com dados inconsistentes.

Existem inúmeros motivos que resultam em problemas de dados, sendo geralmente agrupados em problemas de regulamentação, demanda de negócio, erro humano, erro de interpretação e data drift. É importante entendermos esses problemas como algo que acompanha projetos de dados, não incompetência do time ou da solução desenvolvida. Este artigo do Google inclusive aponta que existe uma prevalência de 92% de ocorrer um problema de dados em um projeto.

O que torna difícil lidar com essas situações é que, por si só, um conjunto de dados não gera exceptions. Por mais errado que esse dataset esteja, a inconsistência só será descoberta quando ele for utilizado. Andy Petrella, autor do livro Fundamentals of Data Observability, ainda vai além ao chamar dados de "assassino silencioso", uma vez que situações como essa resultam em uma desaceleração geral, destruição da confiança e aumento do estresse, raiva e ansiedade, sem que houvesse qualquer alerta de aviso.

O que é observabilidade de dados na prática

O objetivo da observabilidade, e deste artigo em específico sobre dados, é informar um observador sobre o status de um sistema. Para isso, fazemos uso de três principais componentes: logs, traces e métricas, acompanhando a execução das diversas etapas de um pipeline de dados e gerando alertas caso alguma regra não seja respeitada.

No exemplo anterior, quando fomos avisados que o dashboard comercial apresentava inconsistências, para resolver o problema teríamos que sair explorando cada etapa da estrutura de dados até identificar o erro. Será que ele está no dashboard? No data warehouse? O ELT funcionou corretamente? São muitas etapas para explorar, porém, se utilizarmos os instrumentos de observabilidade, conseguimos identificar essas inconsistências antes mesmo dos nossos usuários notarem. Isso conecta diretamente com data lineage: observabilidade te avisa que algo quebrou, lineage te mostra exatamente onde e o que foi afetado.

Imagine que você recebeu um alerta de que existe inconsistência na tabela orders_raw e, por consequência, todas as etapas dependentes não serão atualizadas. A partir dessa notificação, podemos avisar o time que o dashboard de vendas está desatualizado, além de conseguir dar uma estimativa para correção. São situações de estresse evitadas puramente porque recebemos um alerta sobre o erro no pipeline de dados.

A regra de ouro dos alertas

A principal regra que sempre deve ser seguida na implementação de alertas é que, caso um alerta seja gerado, uma ação deve ser tomada. Quem nunca silenciou um canal de notificações no Slack que atire a primeira pedra (estamos ficando sem pedras já, hahaha).

Seguir essa regra garante que os alertas não sejam vistos como algo negativo pelo time, e sim como um canal de informação crítica para a operação de dados. Alerta que ninguém age em cima vira ruído, e ruído é o primeiro passo para o time começar a ignorar todos os alertas, inclusive os que realmente importam.

Ferramentas para implementar observabilidade

Existem várias ferramentas que podem ser usadas para facilitar a implementação de observabilidade em pipelines de dados:

dbt possui vários recursos como testes de schema e de dado, além de testes unitários (disponíveis a partir da versão 1.8), que validam a lógica de uma transformação antes mesmo dela rodar contra dado real.

Great Expectations permite a construção de contratos de dados (data contracts) e gera um alerta caso algum desses contratos seja violado, funcionando como uma camada de validação entre etapas do pipeline.

Esse tipo de instrumentação é o que separa um time que descobre o problema quando o cliente reclama de um time que descobre o problema antes de qualquer um perceber.

Como isso funciona na prática dentro da Erathos

Na Erathos, essa camada de observabilidade já vem pronta pra qualquer um dos mais de 80 conectores disponíveis, sem precisar configurar nada extra:

Tela de jobs consolidada. Todos os pipelines de ingestão numa tabela só, com status, frequência, volume processado e atividade recente. Passa o mouse sobre uma execução recente e já vê o motivo do erro na hora, sem precisar abrir o job.

Histórico completo de execuções. Cada run fica registrado, com linhas processadas, duração e status, e dá pra investigar o detalhe completo de qualquer execução direto na tela, sem abrir log externo.

Alertas com contexto completo. Quando um job falha, a notificação chega no Slack, Discord ou e-mail já com o job, o erro e a duração, sem precisar abrir a ferramenta pra entender o que aconteceu. E dá pra reexecutar o job ou silenciar o alerta direto na notificação, sem sair do canal.

Como o Fernando R., Head of Data em um dos clientes da Erathos, resume: "sem preocupações com ingestão de dados, o time focou na estratégia e não na manutenção de pipelines. Implementar um novo conector leva minutos e a confiabilidade é enorme."

Observabilidade e governança caminham juntas

Observabilidade não é uma prática isolada, ela é parte do mesmo esforço que sustenta uma boa governança de dados: saber o que está acontecendo com o dado, quando algo sai do esperado, e ter uma trilha para investigar rapidamente, em vez de reconstruir o caminho do dado de memória a cada incidente.

Perguntas frequentes sobre observabilidade de dados

Qual a diferença entre observabilidade e monitoramento de dados? Monitoramento costuma focar em métricas específicas e alertas pontuais. Observabilidade é mais ampla: combina logs, traces e métricas para dar visibilidade completa do que está acontecendo em cada etapa do pipeline, permitindo investigar a causa raiz, não só saber que algo deu errado.

Preciso de uma ferramenta dedicada de observabilidade, ou dbt e Great Expectations já bastam? Depende da complexidade do seu stack. Para times menores, testes de dbt e contratos de dados no Great Expectations já cobrem boa parte do problema. Times maiores, com pipelines mais complexos, costumam se beneficiar de ferramentas dedicadas de observabilidade de dados end-to-end.

Por que meu time ignora os alertas que configuramos? Geralmente porque alertas que não geram ação viram ruído. A regra de ouro é simples: se um alerta não exige nenhuma ação real quando dispara, ele não deveria existir, ou precisa ser recalibrado.

Observabilidade de dados também cobre a camada de ingestão? Sim, e é uma das camadas mais importantes, porque um problema na ingestão se propaga para todas as etapas seguintes. Ferramentas de ingestão gerenciada, como a Erathos, já entregam essa camada de observabilidade nativa por sincronização.

Conclusão

Esperamos que o conteúdo tenha contribuído de alguma forma. Se quiser saber mais sobre como a Erathos entrega observabilidade nativa desde a camada de ingestão, crie sua conta gratuita e teste a plataforma.