Pruebas de Calidad de Datos en Plataformas Modernas

Los volúmenes, velocidades y variedades de datos no dejan de crecer, pero los responsables de la toma de decisiones ya no toleran un enfoque de "más o menos" en cuanto a calidad de datos. Si un modelo de aprendizaje automático predice la demanda en la moneda equivocada, los KPIs o dashboards podrían duplicar ingresos debido a claves primarias duplicadas, lo que socava la confianza. Las arquitecturas modernas de datos, como el enfoque orientado a dominios, descentralizan la propiedad de los datos. Por lo tanto, la responsabilidad sobre la calidad debe descentralizarse junto con ellos. Esto significa que cada conjunto de datos debe incluir:

• 1. Un contrato legible por máquina que defina qué significa "buena calidad".
• 2. Un conjunto de pruebas automatizadas que lo validen.
• 3. Un catálogo o capa de gobernanza que muestre la puntuación resultante, para que los consumidores puedan decidir si confiar en él.

Marcos Comunes para la Calidad de Datos (Panorama 2025)

Patrón pragmático: elegir un motor de reglas (GX, Soda, Deequ) para autoría e integración continua (CI), más un plano de observabilidad (Purview, DataZone, Unity Catalog, DataHub) para catalogar los resultados.

Reglas que Detectan el 80% de Incidentes Reales

Los equipos de plataforma suelen proporcionar herramientas y plantillas para los desarrolladores. La observación es que unas pocas reglas pueden cubrir la mayoría de los problemas de calidad de datos. Según el principio de Pareto, el 80% de los problemas puede resolverse con un 20% del esfuerzo usando pruebas simples y estructurales en cada micro-lote, y reservando análisis estadísticos más complejos para ejecuciones menos frecuentes.

Por lo tanto, se recomienda implementar verificaciones estructurales económicas en cada micro-lote y reservar los análisis más completos de deriva estadística para programaciones de ejecución más prolongadas.

Implementación de Calidad en las Tres Grandes Nubes y en un Data Mesh

Azure Data Lakehouse (Synapse + Fabric)

• Puntos de ejecución – Las canalizaciones de Synapse y los flujos de datos de Fabric incluyen pasos de tipo Assert; los notebooks de Spark ejecutan pruebas con GX o Soda; Microsoft Purview ingiere los resultados y los muestra en tarjetas de puntuación dentro del catálogo.
• Flujo de trabajo de referencia:
• • El archivo de reglas en YAML se encuentra junto al JSON de la canalización en Git.
  • Un trabajo en Azure Pipelines inicia un pequeño clúster de Spark y ejecuta las pruebas GX sobre una muestra del pull request.
  • La canalización de producción vuelve a ejecutar las reglas; las particiones con errores se etiquetan como "cuarentena" en ADLS.
  • Purview muestra una insignia con la "Puntuación de Calidad"; sus políticas pueden bloquear la exportación si la puntuación es menor al 95 %.

AWS Data Lake (S3 + Glue)

• Puntos de ejecución – AWS Glue Data Quality o PyDeequ en EMR; las reglas se definen utilizando DQDL (Data Quality Definition Language), documentado en docs.aws.amazon.com.
• Flujo de trabajo de referencia:
• • Los archivos DQDL se almacenan junto al código de infraestructura como código (IaC) en CDK o Terraform.
  • Un trabajo de Glue en la etapa "stage-0" valida los archivos sin procesar; si hay fallos, se envían alertas a través de EventBridge y se escriben archivos de eliminación en Iceberg para enmascarar las filas defectuosas.
  • Las métricas se transmiten a CloudWatch, luego a QuickSight y a los gráficos de linaje en AWS DataZone.
  • Las políticas basadas en etiquetas de Lake Formation pueden denegar la lectura de cualquier partición cuyo estado sea = FAIL.

Databricks Lakehouse (Any Cloud)

• Puntos de ejecución – Se utilizan Delta Live Tables (DLT) con Expectations para canalizaciones de datos en streaming o por lotes, y se aplican restricciones Delta para validaciones estrictas, según la documentación en docs.databricks.com.
• Flujo de trabajo de referencia

  • El desarrollador escribe directamente en SQL reglas como EXPECT id IS NOT NULL ON VIOLATION FAIL.
  • Las métricas generadas por estas expectativas se registran automáticamente en el Unity Catalog y se muestran en el historial de la tabla.
  • Para notebooks ad-hoc, las bibliotecas GX o Soda se ejecutan sobre tablas de Spark y envían los resultados a MLflow o a las métricas de Unity.
  • Las políticas de acceso pueden verificar las etiquetas de calidad en Unity antes de permitir conexiones desde herramientas de BI.

Federated Data Mesh

Un data mesh distribuye los productos de datos entre distintos dominios; por lo tanto, la calidad sigue un modelo de "plantillas federadas, umbrales locales":

• Biblioteca de reglas – El equipo central de plataforma mantiene una colección de macros en YAML/Spark/dbt (como expect_unique_key, expect_freshness) y las publica como un paquete liviano.
• Integración continua por dominio (CI) – Cada repositorio hereda una plantilla de GitHub Actions que ejecuta la biblioteca sobre datos de muestra.
• Registro de contratos – El catálogo (DataHub, Purview, DataZone) actúa como fuente de verdad para esquemas, reglas y SLOs (objetivos de nivel de servicio); las versiones impulsan análisis de impacto y pull requests automatizados en ThoughtSpot.
• Vista de gobernanza – Un dashboard a nivel del mesh muestra las tendencias de tasas de éxito por dominio; la gobernanza federada solo interviene cuando las insignias de SLA se tornan rojas.

Factor clave para el éxito: flujos de trabajo automatizados de pull requests que notifican a los responsables aguas abajo cuando un cambio en el contrato podría afectarles.

Formatos de Tabla Abiertos

Estos nuevos formatos de tabla están ganando popularidad rápidamente. Por ello, investigué cómo podrían integrarse en el proceso de pruebas de calidad de datos.

Se recomienda ejecutar primero verificaciones únicamente basadas en metadatos (como el recuento de filas o detección de cambios en el esquema) utilizando las "tablas de metadatos" de Iceberg o Delta, y solo escalar a marcos de escaneo completo si esas pruebas económicas fallan.

De Señales de Calidad a Controles de Gobernanza

La gobernanza moderna se basa en dos preguntas clave: “¿Puedo confiar en estos datos?” y “¿Estoy autorizado a usarlos?” Las pruebas de calidad de datos ofrecen una respuesta medible a la primera y, con frecuencia, condicionan la segunda:

1.Canal de eventos – Cada resultado de regla emite un evento JSON (tabla, regla, estado, puntuación).

2. Ingesta al catálogo – Herramientas como Collibra, Purview, Unity Catalog, DataZone u OpenMetadata convierten estos eventos en facetas de calidad, almacenadas junto a esquemas y linajes.

3. Evaluación de políticas – OPA, Lake Formation o Synapse RBAC evalúan el acceso con reglas como: PERMITIR lectura SI la puntuación de calidad ≥ 95 Y la clasificación está en ('pública', 'interna').

4. Auditoría y linaje – Cuando una regla falla, el linaje expone de inmediato todos los dashboards afectados aguas abajo; el equipo de DataOps puede silenciar alertas o revertir snapshots.

En resumen, las reglas de calidad dejan de ser burocracia para convertirse en barreras activas que automatizan el cumplimiento normativo.

Ciclo de Vida de Calidad de Datos de Extremo a Extremo (Referencia)

1. Definir el contrato (esquema + reglas + SLOs) en YAML dentro del repositorio del dominio.

2. Puerta CI: GX, Soda o Deequ se ejecutan sobre una muestra del PR; si fallan, se bloquea el merge.

3. Canal de ingesta (ADF, Glue, DLT, etc.) reejecuta las reglas sobre los datos completos; las filas inválidas se gestionan con archivos de eliminación en Iceberg o restricciones Delta.

4. Emisor de métricas envía eventos a Kafka o EventBridge; los reintentos y la cuarentena automática minimizan los falsos positivos.

5. Ingesta al catálogo construye tarjetas de puntuación de calidad; el linaje vincula fallos con consumidores afectados.

6. Motor de políticas impone restricciones como “sin acceso si la puntuación es < 95 %” o si fallan verificaciones de datos sensibles (PII).

7. Ruteo de alertas notifica a guardias solo tras X fallos consecutivos; en caso contrario, se crea un ticket en Jira para revisión por un data steward.

8. Revisión de gobernanza trimestral evalúa MTTR, tendencias y cobertura de reglas, y añade nuevas plantillas a la biblioteca federada.

Puntos clave

• Shift quality left: haz que los errores fallen en las revisiones de código o en los pipelines, no en los dashboards.
• Trata las reglas como código: versión semántica, diferencias en Git, y validación vía CI.
• Aprovecha los metadatos de manifiesto: estadísticas de Iceberg/Delta detectan muchos errores de forma económica.
• Haz visible la confianza: insignias en el catálogo convierten la calidad invisible en valor visible.
• Federar umbrales, centralizar visibilidad: los dominios son dueños de sus métricas; la gobernanza supervisa.
• Automatiza el análisis de impacto: los cambios en contratos generan PRs hacia consumidores aguas abajo.

Conclusión

Una plataforma de datos solo puede considerarse “moderna” si hace que la calidad de datos alta sea el valor predeterminado. Los principios de DevOps como shift-left se aplican eficazmente también en pruebas de calidad de datos.

Independientemente de si la carga de trabajo se ejecuta en Azure Synapse, un data lake en S3 con Glue, un Lakehouse en Databricks o un data mesh federado, mi recomendación es adoptar los siguientes pilares:

• Reglas declarativas, versionadas y asociadas a cada dataset.
• Puntos de ejecución nativos de cada plataforma (Assert, Glue DQ, DLT Expectations) con motores flexibles (GX, Soda, Deequ).
• Formatos de tabla abiertos que proporcionen estadísticas, restricciones y reversión temporal integradas.
• Catálogos de gobernanza que conviertan las métricas de calidad en políticas ejecutables.

Adopta estos cuatros pilares y obtendrás la única métrica que importa: datos confiables entregados de forma constante y a escala.