Data quality monitoring (schema, nulls, drift)

La automatización monitorea continuamente la calidad de los datos en el data warehouse y detecta desviaciones antes de que lleguen a los informes y dashboards. Las verificaciones se ejecutan según una programación o por evento de carga, y los resultados se presentan como alertas con detalle — qué tabla y qué regla fueron vulneradas.

Qué ocurre en el proceso

1. Inventario de tablas críticas. El equipo describe qué datasets en el warehouse son críticos para la elaboración de informes y las decisiones operativas, y registra los propietarios de los datos.
2. Formalización de expectativas. Para cada tabla se registran tres grupos de reglas: el esquema esperado (lista de columnas y sus tipos), la proporción admisible de NULL por columnas, el rango de valores de las métricas clave.
3. Obtención del baseline histórico. Para las verificaciones de drift, el sistema calcula las características estadísticas (media, mediana, proporciones de categorías) en la ventana de los últimos N días.
4. Verificación en cada nueva carga. Al aparecer un incremento de datos, se ejecuta un conjunto de pruebas: el esquema no ha cambiado, el NULL está dentro del umbral, la distribución de valores no se ha desplazado respecto al baseline.
5. Alerting con contexto. Cuando se activa una regla, se envía a Slack o por email un mensaje con el nombre de la tabla, la columna, la regla vulnerada, el valor real y el enlace al runbook.
6. Registro del historial. Todos los lanzamientos y resultados se guardan en una tabla separada para la retrospectiva y el reporting de data-health.

Qué no hace la automatización

1. No corrige los datos automáticamente. El sistema registra la desviación, pero la remediación (fix en ETL, reversión de la carga, corrección manual) la realiza el ingeniero de datos o el propietario de la tabla.
2. No reemplaza los unit tests de los pipelines. El monitor trabaja sobre el resultado — con los datos que ya se encuentran en el warehouse. La lógica de las transformaciones se prueba por separado en CI/CD.
3. No define las reglas de negocio por sí sola. Los umbrales de NULL, los rangos admisibles y la sensibilidad al drift los define el equipo — la automatización ejecuta estas reglas, sin determinar cuáles deben ser.

Técnicamente, la solución se compone de cuatro capas: almacén de reglas, runner de verificaciones, integración con data warehouse y canal de alertas. La implementación es custom-code (Python + SQL), sin dependencia de ninguna herramienta SaaS específica.

Arquitectura

1. Reglas en código o YAML. Cada regla se describe de forma declarativa: tabla, columna, tipo de verificación (schema / null / drift), parámetros (umbral, ventana baseline). Las reglas se almacenan en git — los cambios pasan por code review habitual.
2. Runner de verificaciones. El planificador (cron, Airflow, Dagster, dbt — según elección del equipo) ejecuta el runner tras cada carga o según el calendario. El runner lee las reglas, genera consultas SQL al warehouse y compara el resultado con las expectativas.
3. Conexión al warehouse. El runner accede al data warehouse a través de un SQL-conector nativo y ejecuta las agregaciones en el lado de la BD — para no extraer millones de filas hacia la aplicación.
4. Alertas y dashboard. Las violaciones se envían a Slack o por email. El historial de ejecuciones se escribe en una tabla separada del warehouse, sobre la que se construye el dashboard data-health.

Variantes típicas de configuración

Pasos de implementación

1. Auditoría de datasets críticos (1 semana). Con analistas y data-ingenieros se establece la lista de tablas de las que dependen los dashboards y métricas clave.
2. Descripción de reglas para la primera oleada (1–2 semanas). Para las 5–10 tablas más importantes se formalizan schema, umbrales NULL y drift-checks. Se comienza con umbrales conservadores.
3. Configuración del runner e integraciones (1–2 semanas). El runner se despliega en el orquestador existente, se conecta al warehouse y al canal de alertas.
4. Baseline y calibración (1–2 semanas). El sistema funciona en modo «silencioso»: registra activaciones pero no envía alertas. El equipo ajusta los umbrales en base a datos reales para eliminar los falsos positivos.
5. Puesta en producción. Se activan las alertas, se añade un runbook a cada tipo de verificación y se registran los propietarios de tablas.

Enfoques alternativos

En lugar de custom-code, existen herramientas listas — Great Expectations, Soda Core, dbt tests, así como plataformas comerciales de observability. El custom-code se justifica cuando son importantes el control sobre la lógica de reglas, la ausencia de vendor lock-in y la integración con el orquestador existente. Las soluciones listas arrancan más rápido, pero añaden costes y limitaciones de personalización.

Seguridad y compliance

El runner opera con la cuenta de servicio del warehouse en modo read-only — el monitoreo no modifica los datos. Las reglas en git pasan por code review como cualquier otro código. Los resultados de las verificaciones contienen únicamente valores agregados (contadores, medias), sin muestras de filas brutas — lo que reduce los riesgos al trabajar con datasets sensibles.

Para iniciar el monitoreo se necesitan tres elementos: acceso al data warehouse, orquestación básica y lista de tablas críticas con sus propietarios.

Datos y accesos

• Data warehouse (Snowflake, BigQuery, Redshift, PostgreSQL o equivalente) con posibilidad de ejecutar agregaciones SQL en el lado de la BD.
• Cuenta de servicio con permisos read-only sobre las tablas de destino y permisos write sobre el esquema de servicio para el historial de ejecuciones.
• Canal de alertas: Slack workspace con posibilidad de crear un incoming webhook o acceso SMTP para email.

Infraestructura

• Orquestador en el que se ejecutarán las verificaciones: Airflow, Dagster, dbt Cloud/Core, GitHub Actions o cron en una máquina dedicada.
• Repositorio Git para almacenar las reglas y el código del runner.
• Proceso CI/CD para el despliegue de cambios en las reglas.

Preparación del equipo

• Ingeniero de datos o analista capaz de escribir SQL y trabajar con Python.
• Propietarios de datos (data owners) por dominios clave — personas que reciben las alertas y son responsables de la remediación.
• Formato de alertas acordado y canal de entrega.

Prerrequisitos organizacionales

• Lista de las primeras 5–10 tablas críticas para monitoreo — es razonable comenzar con un scope reducido e ir ampliando.
• Plantilla de runbook: qué hacer ante cada tipo de activación (schema change, incremento de NULL, drift).

Plazos

La implementación completa toma 6–10 semanas para un caso de medium-complexity: 1–2 semanas de auditoría y acuerdo del scope, 2–3 semanas de configuración y primera oleada de reglas, otras 2–3 semanas de calibración del baseline y paso a producción. El plazo exacto depende de la madurez de la data-plataforma y el número de tablas en la primera iteración.