Observabilidade em Ação: Monitorando Nulos e Frequência de Cargas para Blindar seus Pipelines (Estudo Prático)

Michel Souza Santana
15 de nov.
5 min de leitura

Quando a gente fala de Engenharia de Dados, o "mover bits" é só uma parte da história. A outra, e talvez a mais crítica, é garantir que esses bits não sejam apenas transportados, mas que cheguem com qualidade e no tempo certo. E, honestamente, depois de trabalhar em diversos projetos, aprendi que a falha em um pipeline de dados tem um custo altíssimo, que vai desde relatórios incorretos até prejuízos reais ou decisões regulatórias erradas.

Foi exatamente com esse mindset de mitigação de riscos que decidi me aprofundar em estudos sobre Observabilidade em Dados e Data Quality, muito inspirados pelo que li no livro "Fundamentos da Qualidade de Dados". Meu objetivo era ir além dos logs de sucesso/falha de processamento e começar a monitorar a saúde intrínseca dos dados.

Neste artigo, vou compartilhar um estudo que fiz focando em dois pontos de verificação cruciais que acredito que devem ser desenvolvidos, principalmente quando se tratar de projetos financeiros: o percentual de dados nulos em colunas críticas e a frequência de cargas de dados, ambos vitais para detectar anomalias antes que virem um problema.

Ameaça Silenciosa: Dados Nulos em Colunas Críticas do Setor

No setor financeiro principalmente, a precisão é não negociável. Um valor nulo na coluna saldo_atual ou cpf_cliente pode ser mais do que um erro de ETL; pode ser a porta de entrada para uma análise de risco falha ou, pior, uma fraude que passou despercebida.

Eu percebi que um pipeline podia rodar com sucesso, mas se de repente o volume de nulos em uma coluna chave subisse de 0.1% para 5%, isso indicava uma anomalia de dados grave. O sistema não quebrou, mas o dado, sim.

Null Rate Check e o Ponto de Atenção

O conceito é simples, mas poderoso: estabelecer um limiar aceitável (um threshold) para o percentual de nulos em colunas específicas.

Colunas Críticas: Em um projeto de análise de transações, eu considero críticas colunas como IDs únicos, valores transacionais, datas de registro e chaves de relacionamento.
Limiar: Se o percentual de nulos em id_transacao exceder 0.01% (basicamente, um ou outro erro isolado), o alerta deve soar. Em colunas menos críticas, o threshold pode ser mais flexível, mas em finanças por exemplo, a tolerância é mínima.

Exemplo Prático de Verificação com PySpark

Para um laboratório que criei usando PySpark e simulando dados transacionais no Databricks, o script de verificação de qualidade de dados (DQ) era algo assim:

Python

# 1. Conceito: Calcular o percentual de nulos
def check_null_percentage(df, col_name, threshold):
    total_rows = df.count()
    null_count = df.filter(df[col_name].isNull()).count()
    null_percentage = (null_count / total_rows) * 100
    
    # 2. Exemplo prático: Verificação
    if null_percentage > threshold:
        print(f"⚠️ Alerta: A coluna '{col_name}' excedeu o limite de nulos!")
        print(f"Percentual de Nulos: {null_percentage:.2f}% | Limite: {threshold:.2f}%")
        return False
    else:
        print(f"✅ Qualidade OK na coluna '{col_name}'. Nulos: {null_percentage:.2f}%")
        return True

# 3. Explicação do resultado
# df_transacoes é o DataFrame carregado.
THRESHOLD_ID = 0.01 
check_null_percentage(df_transacoes, "id_cliente", THRESHOLD_ID)

O resultado dessa verificação é um alerta imediato no pipeline (seja via e-mail, Slack ou painel de observabilidade) se a saúde do dado for comprometida. No ambiente financeiro, um aumento inesperado de nulos em uma chave primária pode indicar um problema na fonte de dados (por exemplo, um sistema de origem falhando ao gravar o dado) ou um erro de mapeamento durante a ingestão na Cloud (GCP, Azure ou AWS). Monitorar isso é a diferença entre ser reativo e ser proativo.

Frequência de Cargas: Identificando a "Batida do Coração" do Pipeline

Além da qualidade do dado em si, a temporalidade é fundamental. Em cenários de detecção de fraude ou análise de liquidez, um dado que deveria ser atualizado a cada hora, mas que está parado há dois dias, é um dado obsoleto e potencialmente perigoso.

Em meio a criação de um doa meus laboratórios simulando pipeline em empresas reais, percebi que apenas olhar a update_date não era o suficiente. Precisávamos saber a frequência de atualizações do pipeline.

Colunas de Controle e Lasted Charge Date

Para resolver isso, a boa prática de adicionar colunas de controle é essencial:

insert_date: Data da primeira inserção do registro.
update_date: Data da última alteração de qualquer valor da linha.
lasted_charge_date: Data da execução da última carga que tocou essa tabela, independentemente de a linha ter sido alterada.

Esta última coluna é a chave para a observabilidade da frequência. Ela é atualizada em bloco na etapa final do pipeline com a data/hora da execução.

Combate a Fraudes por Timing

Imagine um sistema de monitoramento de transações que busca padrões anormais, como um cliente que nunca transacionou em um certo país, de repente fazendo uma série de compras. A regra de detecção de fraude depende de dados recentes. Se o pipeline de transações parou de carregar, mas o sistema de relatórios continua rodando com dados de ontem, estamos vulneráveis.

A anomalia aqui não é o dado, mas a ausência de dado novo!

Exemplo Prático com DATE_DIFF no Spark SQL

Usando o Spark SQL (muito comum no Databricks ou Google Dataflow via templates SQL), podemos calcular a diferença de dias entre a data da última atualização da linha (update_date) e a data da última carga da tabela (lasted_charge_date).

SQL

-- 1. Conceito: Calcular a diferença de dias entre a atualização da linha e a última carga
SELECT 
    id_cliente,
    update_date,
    lasted_charge_date,
    DATEDIFF(lasted_charge_date, update_date) AS dias_desde_ultima_carga_da_linha
FROM 
    transacoes_financeiras

-- 2. Exemplo prático: Identificar anomalias
WHERE 
    DATEDIFF(lasted_charge_date, update_date) > 5 -- Mais de 5 dias
    AND update_date IS NOT NULL

Se uma linha tem update_date em 01/10/2025, mas a lasted_charge_date é 15/10/2025, o DATEDIFF será 14 dias. Isso é o esperado se a linha não foi alterada, mas o pipeline rodou. O alerta crítico é se a lasted_charge_date estiver, por exemplo, em 05/10/2025 (ou seja, a tabela não recebe dados há 10 dias). Isso indica que o fluxo de ingestão falhou e o dashboard de fraude está lendo dados estagnados. Esse tipo de monitoramento é essencial e deve ser configurado no Airflow ou em qualquer orquestrador que você use.

Conclusão e Próximos Passos

Quando comecei a trabalhar com Engenharia de Dados e ao estudar sobre Data Quality e Governança de Dados, percebi que o maior valor que eu poderia entregar não era apenas a velocidade de processamento, mas a confiança no dado.

O monitoramento da percentagem de nulos em colunas críticas, como demonstrei no estudo, é a nossa primeira linha de defesa contra problemas na estrutura e integridade do dado. Já a verificação da frequência de cargas, usando colunas de controle como a lasted_charge_date, é fundamental para garantir a oportunidade do dado, um fator chave em ambientes de alta criticidade como o financeiro.

Esses estudos, baseados em princípios sólidos de qualidade de dados, nos levam a adotar uma cultura de observabilidade de dados mais madura. Não basta saber se o job rodou; precisamos saber se o dado está saudável e atualizado.

Meu aprendizado com isso é que a qualidade do dado é a base da engenharia. Se você está construindo pipelines na GCP, Azure, ou usando Apache Beam e PySpark, adicione essas verificações de qualidade como etapas obrigatórias no seu fluxo. É o que transforma um pipeline robusto em um pipeline confiável.