CASO DE USO
Data quality LATAM: validación batch para warehouses y data lakes
Tu warehouse tiene 5 años de datos LATAM acumulados. Algunos tax IDs son válidos, otros son garbage histórico, otros pasaron validación en 2019 pero hoy no porque cambió el formato. Sin pipeline de format drift detection, no sabés cuánto de tu data quality es real.
EL PROBLEMA
El format drift en data warehouses crece silencioso
Los formatos de tax IDs evolucionan. Las librerías de validación se updatean. Los pipelines de ingesta tienen bugs ocasionales. Sin auditoría batch, el drift sólo aparece cuando un consumer downstream rompe.
Datos viejos pasaron validation cuando era laxa
En 2019 tu pipeline aceptaba CPFs sin validar DV. En 2024 actualizaste el validator. Hoy tenés 4 años de rows que no pasarían la validation actual — pero nadie los re-evaluó.
Consumers downstream rompen por drift
Un nuevo report financiero hace join sobre tax_id. Falla porque 8% de las rows tienen formato inválido. El equipo de finanzas culpa al data team. El data team no sabía que existía drift.
Validation rules en dbt no cubren LATAM
Great Expectations y dbt tests tienen built-ins para email y phone pero no para CPF/CUIT/RFC. Tu team escribe tests custom que envejecen mal.
POR QUE LAS SOLUCIONES ESTANDAR NO ALCANZAN
Por qué validar solo al ingest no alcanza
dbt tests con regex
Captura shape pero no DV. CPFs con DV inválido pasan el test porque tienen 11 dígitos.
Great Expectations + custom
Escribís expectations custom por país. Funciona pero requiere mantenimiento. Cuando agregás un país o cambia un formato, hay que updatear.
Auditorías manuales trimestrales
Un analista samplea 1000 rows y reporta. Útil pero no captura drift continuo y no escala.
COMO NORMADATA AYUDA
Como Normadata te ayuda
POST /v1/verify (smart parse) iterado sobre cada row del dataset. Schedule un job dbt o Airflow nocturno que corre sobre la tabla principal y escribe response a una shadow table _dq.
El shadow _dq table contiene per-row: valid (bool), normalized (canonical), warnings (array). Tu dashboard de data quality consume _dq directamente — sin tocar la tabla source.
Track el rate de valid:true por mes en _dq. Si baja, identificás drift antes de que rompa un consumer downstream. Si sube, identificás mejoras en upstream ingesta.
MIRALO EN ACCION
Miralo en accion
# Nightly batch — run rows through Smart Parse
$ curl -X POST api.normadata.io/v1/verify \
-H "X-API-Key: nd_a8f3b2c1d4e5f6g7h8i9j0k1l2m3n4o5" \
-d '{"country":"AR","value":"20-31456789-0"}'
{
"valid": true,
"normalized": "20314567890",
"identifier": { "type": "CUIT" }
}
# Airflow DAG pseudocode:
# for row in customers:
# resp = verify(row.country, row.tax_id)
# write_to(customers_dq, row.id, resp.valid, resp.normalized)
# dbt test: select count(*) from customers_dq where valid=false
# Track invalid_rate over time to detect format driftLIMITACIONES
Lo que Normadata no hace en data quality LATAM
—No corre dentro de tu warehouse. Es una REST API — vos orquestás el job con tu tooling (dbt, Airflow, n8n).
—No es un rules engine completo. Da señales por row (valid + warnings) — tu DQ tool agrega y dashboardea.
PREGUNTAS FRECUENTES
Preguntas frecuentes
¿Cuántos rows puedo procesar por noche?
Es función de tu rate limit y de tu paralelización. Una tabla de 1M rows con 10 workers paralelos a ~30ms/call = ~50 minutos. Para volúmenes mayores, batchear por particiones.
¿Integra con dbt directamente?
No hay paquete dbt oficial. La integración es un modelo Python custom o un test custom que llama a la API y escribe a shadow.
Integra Normadata en tu stack
El acceso se otorga manualmente. Unite a la lista de espera y te damos acceso a la API.