1. Por que a qualidade de dados importa
Todo time tem uma historia: dashboard mostra +40% de receita, o CEO anuncia, depois alguem acha uma join duplicada. Data quality e pegar o problema antes dos decisores, nao ser perfeito.
O custo de dados ruins
A Gartner estima $12.9M por ano em media. Pior e perder confianca: quando isso acontece, as decisoes voltam a ser no instinto.
Qualidade gera tres resultados:
Confianca
Stakeholders usam porque sabem que foi validado. Fim do "deixa eu conferir".
Velocidade
Problemas achados na origem em vez de debugar dashboard. Minutos ao inves de horas.
Escala
Checks automaticos escalam com o dado. Conferencia manual nao escala com centenas de tabelas.
Da pratica
Times vencedores tratam qualidade como testes unitarios: nao se faz deploy sem teste, nem se entrega dado sem check. E seguro, nao burocracia.
2. As seis dimensoes da qualidade de dados
Nem todo problema e igual. Estas dimensoes dao o mapa do que pode quebrar e do que testar.
Completude
Tudo que e obrigatorio esta presente?
Teste: Taxa de null em campos obrigatorios = 0%
Acuracia
Os valores refletem a realidade?
Teste: Reconciliar com sistemas fonte
Consistencia
Mesmo formato em todos os sistemas?
Teste: Formatos de data, enums, nomenclatura
Atualidade
O dado esta fresco o suficiente?
Teste: max(updated_at) dentro do SLA
Validade
Segue as regras de negocio?
Teste: Status in ('active','inactive'), price > 0
Unicidade
Sem duplicatas indevidas?
Teste: Chave primaria unica, nenhum pedido duplicado
| Dimensao | Pergunta | Falha comum |
|---|---|---|
| Completude | Esta tudo la? | Nulls em campos obrigatorios |
| Acuracia | Esta correto? | Cache desatualizado, joins errados |
| Consistencia | Igual em todos os lugares? | Formatos de data diferentes |
| Atualidade | Esta fresco? | Atrasos de pipeline, SLA quebrado |
| Validade | Faz sentido? | Precos negativos, datas futuras |
| Unicidade | Ha duplicatas? | Duplicatas de fan-out joins |
3. Onde testar na sua pipeline
O principio de "testar nas fronteiras": validar quando entra e quando sai. Assim capturamos problemas upstream e bugs de transformacao.
Estagio 1: Validacao da fonte (ingestao)
Teste o dado ao chegar de sistemas externos. Primeira linha de defesa.
O que checar:
- • Schema esperado (sem colunas novas/faltando)
- • Contagem de linhas no intervalo esperado
- • Campos obrigatorios nao nulos
- • Dados chegaram no prazo (freshness)
Estagio 2: Testes de transformacao
Teste o output das transformacoes. Encontra bugs de logica em SQL/Python.
O que checar:
- • Chaves primarias unicas (sem fan-out)
- • Agregacoes somam corretamente
- • Regras de negocio aplicadas
- • Integridade referencial mantida
Estagio 3: Validacao de saida (delivery)
Teste antes de chegar em dashboards e consumidores. Ultima chance de barrar problemas.
O que checar:
- • Metricas dentro do esperado
- • Sem anomalias vs historico
- • Dashboards criticos com dados
- • SLAs cumpridos
Pro tip
Fail fast, fail loud
Melhor a pipeline falhar as 6h com erro claro do que gerar dado ruim descoberto na reuniao de conselho. Configure testes para bloquear propagacao de dado corrompido.
4. O que testar (checks praticos)
Comece com estes checks de alto valor e baixo esforco. Cobrem 80% dos problemas.
Limites de contagem de linhas
Cheque se o numero de linhas esta no intervalo esperado (ex.: 900K-1.1M). Pega cargas truncadas ou duplicadas.
expect_table_row_count_to_be_between(min=900000, max=1100000)Taxa de null
Campos obrigatorios devem ter 0% null. Campos opcionais devem ter taxa estavel (alerta se variar >10%).
expect_column_values_to_not_be_null(column="customer_id")Restricoes de unicidade
Chaves primarias precisam ser unicas. Evita fan-out que multiplica metricas.
expect_column_values_to_be_unique(column="order_id")SLA de frescor
Dados nao podem ser mais velhos que o SLA. Cheque max(updated_at) ou particao.
expect_column_max_to_be_between(column="updated_at", min=now()-24h)Intervalos de valor
Campos numericos precisam ficar em limites validos. Receita > 0, idade 0-150, percentual 0-100.
expect_column_values_to_be_between(column="price", min=0, max=100000)Validacao de enum
Campos de status so devem conter valores esperados. Captura typos e estados inesperados.
expect_column_values_to_be_in_set(column="status", value_set=["active", "inactive", "pending"])Exemplo: teste de schema dbt
# models/marts/orders.yml
version: 2
models:
- name: orders_mart
description: "Order-level facts for analytics"
columns:
- name: order_id
tests:
- unique
- not_null
- name: customer_id
tests:
- not_null
- relationships:
to: ref('dim_customers')
field: customer_id
- name: order_total
tests:
- not_null
- dbt_utils.accepted_range:
min_value: 0
max_value: 10000005. Alertas sem fadiga
O maior risco no monitoramento nao e perder algo, mas a fadiga de alerta. Falsos positivos em excesso viram ruido. Veja como manter sinal.
Faca isso
- • Faça tiering: P1 (pager), P2 (Slack), P3 (email digest)
- • Use deteccao de anomalia para metricas volateis
- • Inclua contexto no alerta: o que quebrou, impacto, link de runbook
- • Defina limiares baseados em historico
- • Revise e ajuste todo mes
Evite isso
- • Pager em todo teste falho
- • Limiar hard-code que nao se adapta
- • Alertas sem owner definido
- • Ignorar testes "flaky" em vez de consertar
- • Falta de runbook para falhas comuns
Modelo de severidade
P1 - Pager agora
Dado errado em dashboards de producao. Executivos afetados. Impacto de receita.
P2 - Alerta no Slack
Qualidade degradada, mas nao critica. Resolver em ate 4h.
P3 - Digest diario
Questao menor, informativa. Revisar no proximo sprint.
Da pratica
Ja vi time com 200+ alertas por dia ignorados. Reduzimos para 15 alertas de alto sinal e os problemas eram corrigidos no mesmo dia. Menos ruído, mais acao.
6. Ferramentas para data quality
| Ferramenta | Melhor para | Abordagem | Preco |
|---|---|---|---|
| dbt tests | Testes de transformacao | Schema + testes custom | Gratis (OSS) |
| Great Expectations | Validacao abrangente | Expectation suites | Gratis (OSS) |
| Monte Carlo | Data observability | Deteccao de anomalia ML | Enterprise |
| Soda | Monitoramento de dados | Checks SodaCL | Gratis + planos pagos |
| elementary | Observability nativa dbt | Deteccao de anomalia | Gratis (OSS) |
Testes proativos
Voce define regras. Os testes rodam em cada execucao. Explicito e deterministico.
Ferramentas: dbt tests, Great Expectations, Soda
Deteccao de anomalias
ML aprende o padrao "normal" e alerta nas desviacoes. Pega unknown unknowns.
Ferramentas: Monte Carlo, elementary, Bigeye
7. Checklist de boas praticas
Testar nas fronteiras
Validar na ingestao (problemas upstream) e na entrega (problemas de transformacao). Identifique cedo.
Comece pelas tabelas criticas
Foque primeiro nas tabelas de dashboards executivos e relatórios criticos. Mostre valor e depois expanda.
Use regras e anomalias
Regras pegam conhecidos (nulls, duplicatas). Anomalia pega desconhecidos (saltos de volume).
Faça tiering de alertas
Nem todo erro merece pager. P1 impacto em receita, P2 degradado, P3 informativo.
Runbooks ligados aos alertas
Cada alerta deve linkar para doc: significado, investigacao, passos de correção.
Acompanhe metricas de qualidade
Meça taxa de sucesso dos testes, mean time to detection, mean time to resolution. Melhore continuamente.
Inclua qualidade no CI/CD
Rode testes em cada PR. Bloqueie merges que quebram qualidade. Shift left.
Revisao mensal
Limiar deriva, padroes mudam. Revise mensalmente para manter relevancia.
Pro tip
O teste "Eu apostaria?"
Antes de publicar uma metrica, pergunte: "Eu apostaria $1.000 que este numero esta certo?" Se nao, faltam testes. Qualidade gera confianca, e confianca vem de validacao.
8. Perguntas frequentes
Quais sao as dimensoes-chave da qualidade de dados?
Completude, Acuracia, Consistencia, Atualidade, Validade, Unicidade. Em resumo: nada faltando, valores corretos, formato uniforme, fresco o bastante, segue regras, sem duplicatas.
Como medir qualidade?
Testes automaticos: contagem de linhas, taxa de null, unicidade, frescor, drift de schema, regras de negocio. Acompanhe no tempo e defina limiares.
Quais ferramentas escolher?
Great Expectations, testes dbt, Monte Carlo, Soda, elementary. Escolha se precisa de regras claras ou deteccao de anomalia.
Testar antes ou depois das transformacoes?
Os dois. Checks de origem antes (fail fast) e checks de saida depois para validar logica. Assim voce captura problemas na entrada e na entrega.
Documente sua estrategia de data quality
Crie diagramas claros das pipelines com checkpoints de qualidade. Mostre aos stakeholders onde e como ocorre a validacao.
Guias relacionados
Documentacao de pipelines
Documentar pipelines que novos engenheiros podem debugar no dia 1
Data Lineage Best Practices
Rastrear dados da fonte ao dashboard
Data Contracts
Definir SLAs de qualidade com contratos
Medallion Architecture
Estratificar qualidade com Bronze, Silver, Gold
Arquitetura de pipeline ML
Aplicar monitoring aos pipelines de features ML