CASO DE USO

Data quality LATAM: validação batch para warehouses e data lakes

Seu warehouse tem 5 anos de dados LATAM acumulados. Alguns tax IDs são válidos, outros são garbage histórico, outros passaram pela validação em 2019 mas hoje não — porque o formato mudou. Sem pipeline de format drift detection, você não sabe quanto da sua data quality é real.

Entrar na lista de espera Ler documentacao

O PROBLEMA

O format drift em data warehouses cresce silencioso

Os formatos de tax IDs evoluem. As bibliotecas de validação se atualizam. Os pipelines de ingestão têm bugs ocasionais. Sem auditoria batch, o drift só aparece quando um consumer downstream quebra.

Dados antigos passaram pela validation quando ela era frouxa

Em 2019 seu pipeline aceitava CPFs sem validar DV. Em 2024 você atualizou o validator. Hoje tem 4 anos de rows que não passariam pela validação atual — mas ninguém os reavaliou.

Consumers downstream quebram por drift

Um novo report financeiro faz join sobre tax_id. Falha porque 8% das rows têm formato inválido. O time de finanças culpa o data team. O data team não sabia que existia drift.

Validation rules em dbt não cobrem LATAM

Great Expectations e dbt tests têm built-ins para email e phone mas não para CPF/CUIT/RFC. Seu time escreve tests custom que envelhecem mal.

POR QUE AS SOLUCOES PADRAO NAO SAO SUFICIENTES

Por que validar só no ingest não basta

dbt tests com regex

Captura shape mas não DV. CPFs com DV inválido passam no test porque têm 11 dígitos.

Great Expectations + custom

Você escreve expectations custom por país. Funciona mas exige manutenção. Quando adiciona um país ou muda um formato, tem que atualizar.

Auditorias manuais trimestrais

Um analista amostra 1000 rows e reporta. Útil mas não captura drift contínuo e não escala.

COMO O NORMADATA AJUDA

Como o Normadata ajuda

POST /v1/validate/tax-ids em lotes de até 1.000 rows. Agende um job dbt ou Airflow noturno que roda sobre a tabela principal e escreve a response em uma shadow table _dq.

A shadow table _dq contém per-row: valid (bool), normalized (canonical), warnings (array). Seu dashboard de data quality consome _dq diretamente — sem tocar a tabela source.

Acompanhe a taxa de valid:true por mês em _dq. Se cair, você identifica drift antes que quebre um consumer downstream. Se subir, identifica melhorias na ingestão upstream.

VEJA EM ACAO

Veja em acao

# Nightly batch — push rows in chunks of up to 1,000 items
$ curl -X POST api.normadata.io/v1/validate/tax-ids \
  -H "X-API-Key: nd_a8f3b2c1d4e5f6g7h8i9j0k1l2m3n4o5" \
  -d '{"items":[
    {"id":"r1","country":"AR","type":"cuit","value":"20-12345678-6"},
    {"id":"r2","country":"BR","type":"cpf","value":"123.456.789-09"}
  ]}'

{
  "results": [
    { "id": "r1", "valid": true, "normalized": "20123456786" },
    { "id": "r2", "valid": true, "normalized": "12345678909" }
  ]
}

# Airflow DAG pseudocode:
#   for chunk in chunks(customers, 1000):
#     for r in verify(chunk)['results']:
#       write_to(customers_dq, r['id'], r['valid'], r.get('normalized'))

# dbt test: select count(*) from customers_dq where valid=false
# Track invalid_rate over time to detect format drift

LIMITACOES

O que a Normadata não faz em data quality LATAM

—Não roda dentro do seu warehouse. É uma REST API — você orquestra o job com seu tooling (dbt, Airflow, n8n).

—Não é um rules engine completo. Dá sinais por row (valid + warnings) — sua DQ tool agrega e dashboardeia.

Ver limitacoes completas

PERGUNTAS FREQUENTES

Perguntas frequentes

Quantas rows posso processar por noite?

É função do seu rate limit e da sua paralelização client-side. Para volumes grandes, batchear por partições — o throughput é dominado fora da API.

Integra com dbt diretamente?

Não há pacote dbt oficial. A integração é um modelo Python custom ou um test custom que chama a API e escreve em shadow.

Ver validadores →

See endpoint in docs →

Integre o Normadata no seu stack

Acesso antecipado. Entre na lista e daremos acesso à API.

Entrar na lista de espera Ler documentacao