Toda herramienta de calidad de datos incorpora una decisión arquitectónica: ¿dónde ocurre la comprobación? Mover los datos fuera de la base de datos para ejecutar controles de calidad externamente introduce latencia de red, una capa de procesamiento adicional, costos de salida de datos y una superficie de seguridad que antes no existía. 

A medida que crecen los volúmenes de datos, esa decisión se vuelve más significativa. Extraer un millón de registros al día para validarlos externamente es manejable. Extraer cien millones de registros desde un entorno de Snowflake con obligaciones de residencia de datos, desde un sistema Teradata en una institución regulada, desde un entorno de Databricks que procesa datos de eventos en tiempo real, es una propuesta diferente. El costo de extracción, la latencia y la exposición al cumplimiento escalan con el volumen de datos. El control de calidad en sí no tiene por qué hacerlo. 

La ejecución de calidad de datos en la base de datos ejecuta toda la lógica de calidad dentro del motor de base de datos, donde ya residen los datos, evitando cada uno de esos costos. Este artículo explica qué significa eso en la práctica y cuándo la decisión importa más. 

¿Qué es la ejecución de calidad de datos en la base de datos? 

La ejecución de calidad de datos en la base de datos significa que los controles de calidad, la detección de anomalías, la supervisión de esquemas y la lógica de validación se ejecutan como inspecciones basadas en SQL dentro del motor de la base de datos de origen. La plataforma de calidad se conecta, emite consultas de inspección, evalúa las métricas resultantes y escribe las banderas de calidad de vuelta en su propio esquema. Ningún registro sale de la base de datos. 

La distinción respecto de las arquitecturas de canalización externas es arquitectónica, no cosmética. Una canalización externa extrae datos del origen, los mueve a un entorno separado donde se ejecutan los controles de calidad y luego descarta o conserva la copia. La lógica de calidad se ejecuta sobre la copia. El origen sigue evolucionando mientras la copia envejece. La ejecución en la base de datos elimina por completo esa tensión. 

El cambio de ETL a ELT refleja exactamente esta idea. Según la investigación sobre canalizaciones de datos documentada en ScienceDirect, el patrón ELT reemplazó a ETL porque realizar la lógica de transformación dentro del almacén, donde ya residen el cómputo y los datos, es más rápido y arquitectónicamente más limpio. La misma lógica se aplica a la calidad de datos: ¿por qué extraer los datos para verificarlos cuando el motor de la base de datos ya tiene todo lo necesario para ejecutar la comprobación? 

Las limitaciones de las canalizaciones externas de calidad de datos que evita la ejecución en la base de datos 

Las canalizaciones externas de calidad de datos presentan cuatro limitaciones estructurales que las arquitecturas en la base de datos evitan. 

• Latencia y obsolescencia: Los controles de calidad se ejecutan sobre copias extraídas. Para cuando la comprobación finaliza, los datos de origen pueden haber cambiado. En entornos con actualizaciones frecuentes o ingestión en streaming, las canalizaciones externas siempre trabajan contra una instantánea que ya va por detrás del estado actual. 

  
  

• Exposición a la seguridad y riesgo de cumplimiento: Cada movimiento de datos es una superficie de ataque. Extraer registros requiere tránsito por la red, credenciales en ambos extremos y una capa de almacenamiento secundaria que debe ser protegida y auditada. Para organizaciones sujetas al RGPD, HIPAA, BCBS 239 o regulaciones de residencia de datos, la extracción en sí puede requerir una justificación explícita. La ejecución en la base de datos evita esto porque ningún dato cruza un límite del sistema. 

  
  

• Coste operativo y mantenimiento: Las canalizaciones externas requieren infraestructura para extraer, transportar y procesar datos por separado del origen. Requieren orquestación, supervisión, gestión de capacidad y manejo de fallos para la propia canalización de extracción, de forma independiente a la lógica del control de calidad. Según las notas de DQOps en su análisis de arquitectura de calidad de datos, ambos enfoques introducen costes de mantenimiento que crecen a medida que aumenta el número de controles, acoplando la lógica de calidad a los ciclos de ejecución de la canalización. 

  
  

• Coste de escala a volumen: En entornos de almacenes de datos en la nube como Snowflake, Databricks o Azure Synapse, la salida de datos tiene un coste financiero directo. A volúmenes de datos empresariales, esos costes se acumulan. La ejecución en la base de datos utiliza el cómputo ya asignado a la base de datos, sin salida de datos. 

Beneficios de rendimiento y seguridad de la calidad de datos en la base de datos en Snowflake y almacenes modernos 

Los almacenes modernos de datos en la nube están diseñados para la ejecución SQL a gran escala con procesamiento paralelo nativo, almacenamiento columnar y optimización de consultas. Cuando los controles de calidad de datos se ejecutan como inspecciones SQL dentro de estos motores, se benefician de las mismas ventajas arquitectónicas: paralelismo, poda de consultas y ejecución nativa sobre el formato de almacenamiento en el que ya residen los datos. 

La ventaja de rendimiento no es marginal. Un control de completitud sobre una tabla de mil millones de filas que se ejecuta como SQL dentro de Snowflake opera sobre almacenamiento columnar comprimido con poda de micro-particiones. El mismo control en un entorno Python externo procesa registros descomprimidos de forma secuencial, sin las optimizaciones nativas del almacén. 

El beneficio de seguridad es categórico. La investigación del Journal of Big Data identifica el movimiento de datos entre entornos como un riesgo principal de governance, señalando que las políticas que exigen que todo el procesamiento permanezca dentro de un entorno controlado se alinean con la Ley de IA de la UE y el RGPD. La ejecución en la base de datos cumple estos requisitos porque los datos nunca salen del entorno que esas regulaciones gobiernan. 

En el caso específico de Snowflake, todo el cálculo de métricas, la detección de anomalías, la validación y la supervisión de esquemas se ejecutan dentro del entorno de Snowflake como SQL nativo. La instancia de la plataforma digna se ubica en la propia infraestructura del cliente. Solo se devuelven resultados agregados de métricas, no datos a nivel de registro, al esquema de observability de digna. 

Cómo funciona la calidad de datos en la base de datos en los entornos modernos de almacenes de datos 

La plataforma de calidad se conecta a la base de datos mediante un conector estándar, emite consultas de inspección basadas en SQL contra tablas y vistas configuradas, recibe los valores de métricas resultantes, los compara con líneas base aprendidas o umbrales definidos y escribe el estado de calidad en su propio esquema dentro del mismo entorno. 

Este modelo desacopla por completo la supervisión de la calidad del movimiento de datos. La canalización que carga los datos en el almacén funciona de manera independiente a la inspección de calidad. La inspección lee tablas que la canalización ya ha poblado, sin interceptar ni modificar el flujo de datos ni requerir cambios en la forma en que se cargan los datos. 

digna implementa esto en Snowflake, Databricks, Teradata, PostgreSQL, Oracle, MS SQL Server y Azure Synapse: digna Data Anomalies aprende líneas base de comportamiento a partir de cálculos de métricas en la base de datos. digna Data Validation hace cumplir reglas de negocio mediante inspección de registros basada en SQL. digna Schema Tracker supervisa cambios estructurales consultando directamente los metadatos de la base de datos. digna Timeliness supervisa las marcas de tiempo de llegada de los datos desde dentro de la base de datos. digna Data Analytics calcula métricas de tendencia a partir de datos de observability en la base de datos. Ninguno requiere que los datos salgan del motor de la base de datos. 

Cuándo elegir la calidad de datos en la base de datos frente a enfoques de canalización externos 

El caso de la ejecución en la base de datos es más sólido en cuatro contextos que describen la mayoría de los entornos de datos empresariales. 

• Industrias reguladas con requisitos de residencia o sensibilidad de los datos: Las instituciones financieras, las organizaciones sanitarias y las empresas sujetas al RGPD, HIPAA o regulaciones de soberanía de datos se enfrentan a obligaciones documentadas sobre dónde pueden procesarse los datos. La ejecución en la base de datos mantiene por diseño la supervisión de la calidad dentro del entorno controlado, sin extracción y sin acceso externo que justificar ante un auditor. 

  
  

• Entornos de gran volumen donde el coste de extracción no es trivial: A volúmenes de datos empresariales, los costes de salida de datos en los almacenes en la nube, el consumo de ancho de banda y el cómputo de procesamiento externo escalan con el tamaño de los datos. La ejecución en la base de datos escala con el propio cómputo del almacén, que ya está aprovisionado. 

  
  

• Entornos donde importa la latencia de detección: Un análisis de 2024 de más de 1.000 canalizaciones de datos realizado por Datachecks encontró que el 72% de los problemas de calidad de datos se descubren solo después de afectar a las decisiones de negocio. Los controles en la base de datos se ejecutan sobre el estado más actual del almacén, no sobre una copia extraída que puede tener horas de antigüedad. 

  
  

• Equipos que necesitan supervisión de calidad sin modificar las canalizaciones: La supervisión de calidad en la base de datos no requiere cambios en la forma en que se cargan los datos ni en cómo están estructuradas las canalizaciones existentes. Se instala como una capa de observación sobre tablas existentes, eliminando el acoplamiento entre la supervisión de calidad y los ciclos de desarrollo de la canalización. 

Reflexión final: la arquitectura de la calidad debe coincidir con la arquitectura de los datos 

El giro de la industria hacia ELT reconoció que el cómputo para la transformación ya existe dentro del almacén y que extraer datos para transformarlos en otro lugar era un hábito arquitectónico anterior a la infraestructura moderna en la nube. Ese mismo reconocimiento se aplica a la calidad de datos. El cómputo necesario para comprobar la calidad ya existe dentro de la base de datos. Mover los datos fuera para verificarlos externamente introduce costos, latencia y riesgo que el modelo arquitectónico no necesita. 

Un estudio de Forrester citado por Acceldata encontró que el 30% de los ejecutivos informó haber perdido clientes debido a inexactitudes en los datos. Las organizaciones que detectan las inexactitudes antes son aquellas que tienen la supervisión de calidad más cerca de los datos. La ejecución en la base de datos hace que esa proximidad sea sistemática. 

Los controles de calidad deben ejecutarse donde viven los datos.

Vea la calidad de datos en la base de datos en su propio entorno. 

digna ejecuta todos los controles de calidad, la detección de anomalías, la supervisión de esquemas y la validación dentro del motor de su base de datos. Ningún dato sale de su entorno. No se requiere una canalización externa. Cinco módulos, todos ejecutándose en la base de datos en Snowflake, Databricks, Teradata, PostgreSQL y más. 

Reserve una demo personalizada Explore la arquitectura de la plataforma