Como Construir uma Plataforma de Data Observability com Ferramentas Open-Source (Sem Vendor Lock-In)

O Problema com Data Observability Hoje

Times de dados sao cobrados a monitorar dados da mesma forma que SREs monitoram aplicacoes. Mas enquanto observabilidade de aplicacoes tem ferramentas maduras e padronizadas (Prometheus, Grafana, OpenTelemetry), data observability continua dominado por vendors caros que cobram por tabela e escalam de forma dolorosa junto com seu warehouse.

As capacidades que voce realmente precisa nao sao ciencia de foguete: coleta de metadados, deteccao estatistica de anomalias, rastreamento de lineage, monitoramento de SLA e alertas. Cada uma dessas pode ser construida com ferramentas open-source e praticas padrao de engenharia.

Construi uma implementacao funcional para provar isso. O codigo completo esta disponivel em data-observability-platform, e este artigo percorre a arquitetura, os tradeoffs e as licoes aprendidas.

Visao Geral da Arquitetura

A plataforma segue um padrao collector-processor-dashboard:

[Metadata Collectors]     [Processing Layer]      [Presentation]
  Airflow tasks      -->   Anomaly Detection  -->  Streamlit Dashboard
  dbt artifacts      -->   Lineage Builder    -->  REST API
  Database stats     -->   SLA Monitor        -->  Alert Channels
         |                      |                      |
         v                      v                      v
     [PostgreSQL - Central Metadata Store]

Tudo flui para um banco PostgreSQL central que armazena snapshots de metadados ao longo do tempo. Essa abordagem de time-series para metadados e o que habilita analise de tendencias e deteccao de anomalias.

Metadata Collectors: A Fundacao

Observabilidade comeca pela coleta. A plataforma implementa tres tipos de coletores, cada um rodando em seu proprio schedule.

Airflow Metadata Collector

O coletor de Airflow extrai historico de DAG runs, duracoes de tasks, taxas de falha e atrasos de scheduling do banco de metadados do Airflow. Ele captura:

• Duracao de execucao de tasks (p50, p95, p99)
• Taxas de sucesso/falha de DAGs em janelas deslizantes
• Lag de scheduling (tempo entre inicio agendado e real)
• Historico de violacoes de SLA

Esses dados alimentam diretamente o motor de deteccao de anomalias. Quando uma task que normalmente leva 3 minutos de repente leva 45, voce quer saber antes que os consumidores downstream percebam dados ruins.

dbt Artifacts Collector

Apos cada dbt run, a plataforma faz parse de manifest.json, run_results.json e catalog.json para extrair:

• Tempos de execucao de modelos e contagem de linhas
• Resultados de testes com detalhes de falha
• Mudancas de schema (novas colunas, mudancas de tipo, colunas removidas)
• Resultados de checagem de freshness de sources

O coletor de dbt e provavelmente o mais valioso porque o dbt ja conhece seus data contracts (via testes e definicoes de schema). A plataforma de observabilidade so precisa rastrear esses sinais ao longo do tempo.

Database Statistics Collector

O coletor de banco roda queries periodicas de profiling contra as tabelas do seu warehouse:

• Contagem de linhas e taxas de crescimento
• Percentuais de NULL por coluna
• Contagem de valores distintos e mudancas de cardinalidade
• Min/max/media para colunas numericas
• Histogramas de distribuicao de valores para colunas categoricas

Essas estatisticas sao armazenadas como dados de time-series, habilitando o motor de deteccao de anomalias a estabelecer baselines e detectar drift.

Deteccao Estatistica de Anomalias: Simples Mas Eficaz

Plataformas de vendors adoram fazer marketing da sua "deteccao de anomalias com IA." Na pratica, a maioria das anomalias em dados e pega por metodos estatisticos diretos. A plataforma implementa duas abordagens complementares.

Deteccao por Z-Score

Para metricas com distribuicoes aproximadamente normais (contagem de linhas, tempos de execucao, agregados numericos), deteccao por z-score funciona bem:

def detect_zscore_anomaly(
    metric_history: list[float],
    current_value: float,
    threshold: float = 3.0,
) -> AnomalyResult:
    mean = statistics.mean(metric_history)
    stdev = statistics.stdev(metric_history)
    if stdev == 0:
        return AnomalyResult(is_anomaly=False)
    z_score = (current_value - mean) / stdev
    return AnomalyResult(
        is_anomaly=abs(z_score) > threshold,
        severity=classify_severity(abs(z_score)),
        z_score=z_score,
    )

A decisao de design chave e a janela de lookback. Muito curta e voce recebe alertas ruidosos de variancia normal. Muito longa e voce perde drift gradual. A plataforma usa 30 dias como padrao com janelas configuraveis por metrica.

Median Absolute Deviation (MAD)

Para metricas com outliers ou distribuicoes enviesadas (comum em dados reais), MAD e mais robusto que z-score:

def detect_mad_anomaly(
    metric_history: list[float],
    current_value: float,
    threshold: float = 3.5,
) -> AnomalyResult:
    median = statistics.median(metric_history)
    mad = statistics.median(
        [abs(x - median) for x in metric_history]
    )
    if mad == 0:
        return AnomalyResult(is_anomaly=False)
    modified_z = 0.6745 * (current_value - median) / mad
    return AnomalyResult(
        is_anomaly=abs(modified_z) > threshold,
        severity=classify_severity(abs(modified_z)),
        modified_z_score=modified_z,
    )

MAD lida com o cenario comum onde uma tabela ocasionalmente recebe cargas bulk atrasadas que distorceriam a media mas nao a mediana.

Combinando Detectores

A plataforma roda ambos os detectores e usa uma abordagem de consenso: se ambos sinalizam anomalia, e severidade alta. Se apenas um sinaliza, e media. Isso reduz falsos positivos significativamente comparado a usar qualquer metodo sozinho.

Grafo de Lineage com Analise de Impacto

Data lineage e o recurso que separa uma ferramenta de monitoramento de uma plataforma de observabilidade de verdade. Quando algo quebra, voce precisa responder duas perguntas instantaneamente: "O que causou isso?" e "O que mais foi afetado?"

A plataforma constroi um grafo aciclico direcionado (DAG) a partir de tres fontes:

1. dbt refs e sources - Relacionamentos modelo-para-modelo e modelo-para-source
2. SQL parsing - Para transformacoes fora do dbt, parsing basico de SQL extrai referencias de tabelas
3. Dependencias de tasks do Airflow - Conecta lineage no nivel de orquestracao ao lineage no nivel de dados

O grafo de lineage habilita duas operacoes criticas:

Rastreamento upstream: Dada uma tabela com dados anomalos, caminhar upstream para encontrar qual source ou transformacao introduziu o problema.

Impacto downstream: Dado um source que falhou ao carregar, identificar imediatamente cada modelo, dashboard e consumidor downstream afetado.

def get_downstream_impact(
    graph: nx.DiGraph,
    node_id: str,
) -> ImpactReport:
    descendants = nx.descendants(graph, node_id)
    impacted_models = [
        graph.nodes[n] for n in descendants
        if graph.nodes[n]["type"] == "model"
    ]
    impacted_dashboards = [
        graph.nodes[n] for n in descendants
        if graph.nodes[n]["type"] == "dashboard"
    ]
    return ImpactReport(
        total_impacted=len(descendants),
        models=impacted_models,
        dashboards=impacted_dashboards,
        critical_path=find_critical_consumers(descendants),
    )

O grafo e armazenado no PostgreSQL usando lista de adjacencia e reconstruido incrementalmente a cada execucao de coletor. Para visualizacao, o dashboard Streamlit renderiza o lineage usando graphviz com nos coloridos indicando status de saude.

Monitoramento de SLA

Monitoramento de SLA conecta tudo ao definir contratos para freshness, completude e qualidade dos dados.

Cada SLA e definido declarativamente em YAML:

slas:
  - name: daily_revenue_report
    table: gold.fact_revenue
    checks:
      - type: freshness
        max_age_hours: 6
      - type: row_count
        min_rows: 1000
      - type: null_percentage
        column: revenue_amount
        max_null_pct: 0.01
    alert_channels:
      - slack:data-alerts
      - pagerduty:data-team
    schedule: "0 */2 * * *"

O motor de SLA avalia essas checagens no schedule definido e rastreia historico de violacoes. Combinado com o grafo de lineage, pode alertar proativamente quando uma falha upstream provavelmente causara uma violacao de SLA downstream antes que ela realmente aconteca.

Dashboard Streamlit

O dashboard fornece uma visao unica da saude dos dados em toda a plataforma:

• Visao geral de saude: Scores de saude por tabela baseados em contagem recente de anomalias, falhas de testes e status de SLA
• Timeline de anomalias: Grafico interativo mostrando anomalias detectadas ao longo do tempo com drill-down
• Explorador de lineage: Grafo visual do fluxo de dados com destaque de propagacao de anomalias
• Tracker de SLA: Status atual e taxas de compliance historicas para todos os SLAs definidos
• Snapshots de profiling: Estatisticas por coluna ao longo do tempo para qualquer tabela monitorada

Streamlit foi escolhido deliberadamente ao inves de construir um frontend React customizado. Para uma ferramenta interna de observabilidade, a velocidade de desenvolvimento e a biblioteca de componentes data-native superam as limitacoes em customizacao.

O Que Eu Mudaria em Producao

O repositorio showcase e uma implementacao funcional, mas deployments em producao precisariam de ajustes:

Armazenamento de time-series: PostgreSQL funciona para escala moderada, mas um banco de time-series dedicado (TimescaleDB ou ClickHouse) lidaria melhor com o volume de metadados em escala de warehouse.

Confiabilidade dos coletores: Os coletores atuais rodam como scripts standalone. Em producao, deveriam ser tasks do Airflow, ganhando retry logic, alertas sobre falhas de coletores e integracao de scheduling de graca.

Gestao de fadiga de alertas: O alerta atual e basico, baseado em threshold. Producao precisa de agrupamento de alertas, supressao durante janelas de manutencao conhecidas e politicas de escalonamento.

Suporte multi-warehouse: O coletor de banco atualmente mira PostgreSQL. Deployments reais precisariam de conectores para Snowflake, BigQuery, Databricks e Redshift.

O Ponto Pratico

Data observability nao e uma categoria de produto que exige um vendor. E um conjunto de praticas de engenharia: coletar metadados sistematicamente, detectar anomalias estatisticamente, rastrear lineage automaticamente e monitorar SLAs contratualmente.

O repositorio data-observability-platform demonstra que uma plataforma de observabilidade capaz pode ser construida com PostgreSQL, Python e Streamlit. O custo total de infraestrutura e um banco de dados e uma instancia de compute.

Comece instrumentando o que voce ja tem. Se voce roda dbt, ja tem resultados de testes e metadados de schema. Se roda Airflow, ja tem metricas de execucao. A plataforma de observabilidade so conecta esses sinais e os observa ao longo do tempo.

Monitore seus dados como SREs monitoram aplicacoes. Seus stakeholders merecem as mesmas garantias de confiabilidade para seus dashboards que seus usuarios esperam das suas APIs.