Control de integridad de datos: una guía práctica para equipos modernos

Se puede tener un almacenamiento de datos que parezca saludable en el papel y, aun así, enviar una cifra errónea a finanzas antes del almuerzo. Se realiza una carga diaria, los paneles se actualizan y nadie nota que un campo obligatorio de repente está vacío, que una partición no llegó o que una fuente cambió de forma lo suficiente como para pasar desapercibida en una verificación rutinaria de recuento de filas. Así es como la confianza comienza a filtrarse, mucho antes de que alguien abra una sala de crisis.

Las comprobaciones de integridad de datos son la barrera de seguridad entre la ingesta en bruto y las decisiones que la gente está dispuesta a defender. Lo complicado es que la integridad no se trata solo de "si hay nulos", sino también de "si llegaron los registros correctos a tiempo, al lugar correcto y con los campos que el negocio necesita". Por eso, el enfoque más sólido trata la integridad como una cuestión de aptitud para el uso, no como una métrica cosmética.

Tabla de contenidos

• Por qué los fallos de integridad destruyen la confianza antes de que alguien se dé cuenta

• Qué verifican las comprobaciones de integridad de datos

  • Vistas a nivel de atributo y a nivel de registro

• Las cuatro formas de comprobaciones de integridad que ejecutará

  • Comprobaciones de fila, columna, lote y relación

• Técnicas de detección: desde recuentos simples hasta diffs de CDC

  • Comience con la línea de base

  • Agregue agregaciones, marcas de agua y diffs

• Diseño de SLA y alertas que distingan el retraso de la pérdida

• Investigar y corregir una comprobación de integridad fallida

• Cómo una plataforma de Observability en la base de datos redefine el panorama

• Una lista de verificación de integridad de una semana para sus flujos de trabajo

Por qué los fallos de integridad destruyen la confianza antes de que alguien se dé cuenta

Un equipo de finanzas que esperaría ver en cualquier configuración de gran almacenamiento de datos conoce bien este patrón. El panel no explota, simplemente deja de coincidir con el sistema de origen después de una carga diaria, y la primera pista es una comprobación de comparación con los totales de la semana pasada. Alguien vuelve a comprobar el modelo, otra persona vuelve a ejecutar el informe y entonces aparece el problema. Una columna desapareció del flujo, pero el pipeline de datos siguió mostrándose como "exitoso".

Ese tipo de error es exactamente la razón por la cual la guía oficial de calidad estadística trata la integridad como un control de primera línea. El Gobierno de Escocia recomienda comprobar si faltan valores, verificar el número esperado de entradas de datos, confirmar que todas las variables estén presentes y comparar los totales y las sumas de filas o columnas entre sí y con los años anteriores antes de la publicación, para luego probar las anomalías frente a datos históricos y otras fuentes publicadas para ver si el cambio es real o simplemente un error (Guía de calidad estadística del Gobierno de Escocia). En términos sencillos de almacenamiento de datos, este es un trabajo de conciliación, no solo una búsqueda de nulos.

Un equipo que solo verifica si una columna contiene nulos puede pasar por alto la pérdida silenciosa de filas, las entradas duplicadas o una carga que se retrasa pero que técnicamente no está vacía. Por eso, un fallo de integridad a menudo se manifiesta primero como una escalada de las partes interesadas y, en segundo lugar, como una investigación de la causa raíz. Para cuando se reconstruye el informe, el daño ya es tanto social como técnico.

Regla práctica: si el desvío de un panel se puede confundir con un cambio comercial, necesita comprobaciones de integridad tanto en el flujo de registros como en la presencia de campos, no solo en uno u otro.

Si está evaluando herramientas en torno a este problema, ayuda comparar cómo manejan diferentes productos las comprobaciones de datos operativos. Un lugar útil para comenzar es evaluar el software de contratistas gubernamentales, ya que los entornos de informes del sector público tienden a exponer los mismos modos de fallo de integridad que los almacenes de datos empresariales, solo que con menos margen para la ambigüedad.

Qué verifican las comprobaciones de integridad de datos

Un punto de partida útil es la métrica más simple. La integridad a menudo se expresa como la proporción de valores no ausentes en un campo o registro, calculada como Integridad = (Número de valores no nulos / Número total de valores) × 100 %. Esa fórmula ayuda porque hace que la integridad sea comparable entre tablas, sistemas y períodos de tiempo, y le brinda un único lenguaje para un campo, una fila o un conjunto de datos completo (definición de métrica de integridad).

Un equipo de almacenamiento de datos generalmente siente la métrica solo después de que algo se rompe río abajo. Un flujo diario de pedidos puede parecer saludable a nivel de columna, mientras que algunas claves faltantes hacen que las uniones fallen, los paneles cuenten mal y las pistas de auditoría pierdan continuidad. Una tabla de clientes aún puede ser útil para la facturación incluso si un campo de enriquecimiento está vacío, porque la facturación solo necesita una porción más estrecha del registro. Es por eso que las comprobaciones de integridad se tratan realmente de la idoneidad para el uso, no de obligar a que se complete cada celda.

Vistas a nivel de atributo y a nivel de registro

La integridad tiene al menos dos capas que vale la pena separar. La integridad a nivel de atributo pregunta si una columna específica está poblada. La integridad a nivel de registro pregunta si una fila contiene todos los campos que requiere el caso de uso. Una columna puede verse bien en promedio y aun así dejar un puñado de filas críticas inutilizables río abajo.

Esa distinción es más importante durante la ingesta y la carga del almacenamiento de datos. Si falta customer_id, order_date o status en una tabla de pedidos, el pipeline aún puede cargar filas, pero el modelo ya no puede respaldar uniones, paneles o revisiones de auditoría con confianza. La guía de IBM sobre métodos de prueba de datos apunta en la misma dirección: la integridad debe centrarse en elementos de datos críticos, porque no todos los campos tienen el mismo valor operativo (Métodos de prueba de datos de IBM).

Una vez que se define el caso de uso, la comprobación se vuelve mucho más clara. Usted decide qué campos son obligatorios, cuáles son enriquecimientos opcionales y qué filas nunca deben llegar cargadas a medias. En la práctica, esto significa que las reglas de integridad siguen primero al proceso comercial y en segundo lugar al esquema.

Un almacenamiento de datos puede estar incompleto para el análisis y, aun así, ser lo suficientemente completo para los informes de control. Esa diferencia es lo que convierte a la integridad en una decisión sobre la puntualidad y la cobertura de los SLA, especialmente cuando una carga tardía es más perjudicial que una dispersa pero a tiempo.

Las cuatro formas de comprobaciones de integridad que ejecutará

Una comprobación de integridad debe coincidir con el fallo que intenta detectar. Un modelo minorista con una fila esperada por tienda necesita una comprobación diferente de una dimensión de cliente con atributos requeridos, y ambas son diferentes de un lote diario que nunca llegó. El error es intentar que un solo patrón cubra todas las brechas.

Comprobaciones de fila, columna, lote y relación

Las comprobaciones a nivel de fila verifican que cada entidad esperada esté presente. Si la fuente dice que debería haber un registro por cliente activo, el almacenamiento de datos debe contener esa población completa, no una coincidencia aproximada. Este patrón detecta la pérdida silenciosa de filas y el truncamiento de carga, pero no le dirá si un campo dentro de cada fila está vacío.

Las comprobaciones a nivel de columna buscan que se completen los atributos requeridos. Si falta customer_id o order_date en una tabla de hechos, la fila puede seguir existiendo mientras que el modelo posterior se vuelve poco confiable. Este patrón es fuerte para campos obligatorios, pero débil para pérdidas de origen a destino.

Las comprobaciones incrementales o a nivel de partición comparan un lote con el delta esperado. Son útiles para archivos diarios, flujos por hora o tablas particionadas donde el mayor riesgo es la falta de una porción. Una comprobación de partición detecta un archivo omitido, pero no detectará si una columna se corrompió dentro del archivo.

Las comprobaciones referenciales confirman que las claves externas sigan resolviéndose. Una fila de hechos con un customer_id que ya no existe en la dimensión está completa en el sentido estricto del recuento de filas, pero incompleta en el sentido relacional. Los equipos de CDC y almacenamiento de datos a menudo descubren esto después de un cambio de esquema o de un lote de dimensión que llega con retraso.

La perspectiva de CDC y de la observabilidad importa porque los problemas de integridad suelen solaparse con otros modos de fallo. El planteamiento de Monte Carlo sobre la integridad nivel de atributo y nivel de registro es útil porque separa las brechas de columna de las de fila (Descripción general de la integridad de Monte Carlo). La perspectiva de origen a destino de Adverity es igualmente práctica, ya que trata la integridad como la verificación de que todos los datos previstos se han movido del origen al destino (Comprobación de integridad de Adverity). En el caso de los equipos que necesitan una comparación directa de origen a destino, la conciliación de datos en el almacenamiento de datos otorga a esa comprobación una forma operativa directa.

Un almacenamiento de datos puede estar incompleto para el análisis y seguir siendo lo suficientemente completo para los informes de control. Eso hace que la integridad sea una decisión de idoneidad para el uso vinculada a la puntualidad y la cobertura de los SLA. Una carga tardía puede doler más que una carga dispersa que llegó a tiempo, porque los trabajos posteriores pueden haber perdido ya su ventana de oportunidad.

Técnicas de detección: desde recuentos simples hasta diffs de CDC

No se necesita una estructura gigante para empezar. Los equipos comienzan con recuentos de filas y tasas de nulos, y luego agregan controles más sólidos a medida que los datos se vuelven más valiosos o más frágiles. El objetivo es acumular técnicas para que cada una detecte un tipo diferente de pérdida.

Comience con la línea de base

Una comprobación de línea de base suele ser la primera línea de defensa.

select count(*) as row_count
from fact_orders;

select count(*) as row_count
from fact_orders;

select count(*) as row_count
from fact_orders;

select
  count(*) as total_rows,
  sum(case when customer_id is not null then 1 else 0 end) as populated_customer_id
from fact_orders;

select
  count(*) as total_rows,
  sum(case when customer_id is not null then 1 else 0 end) as populated_customer_id
from fact_orders;

select
  count(*) as total_rows,
  sum(case when customer_id is not null then 1 else 0 end) as populated_customer_id
from fact_orders;

Esas comprobaciones son económicas, fáciles de explicar y de automatizar. Detectan pérdidas evidentes de registros y campos faltantes obvios, por lo que sigue valiendo la pena realizarlas incluso en almacenes de datos consolidados.

Agregue agregaciones, marcas de agua y diffs

Cuando los recuentos de filas sean demasiado imprecisos, agregue agregaciones y sumas de comprobación.

select
  sum(order_total) as total_amount,
  count(distinct order_id) as distinct_orders
from fact_orders;

select
  sum(order_total) as total_amount,
  count(distinct order_id) as distinct_orders
from fact_orders;

select
  sum(order_total) as total_amount,
  count(distinct order_id) as distinct_orders
from fact_orders;

Ese patrón detecta situaciones en las que el recuento de filas parece correcto pero la carga útil cambió durante la transmisión. En el caso de los modelos incrementales, una marca de agua suele ser la señal más reveladora.

select max(updated_at) as high_water_mark
from fact_orders_incremental;

select max(updated_at) as high_water_mark
from fact_orders_incremental;

select max(updated_at) as high_water_mark
from fact_orders_incremental;

Si la marca de agua deja de avanzar, el pipeline está estancado incluso si los recuentos de ayer todavía parecen normales. En el caso de sistemas de origen que emiten eventos de cambio, los diffs de CDC son más sólidos porque se compara lo que llegó al almacén de datos con lo que emitió el origen.

, pseudocode
compare source_events to target_events by primary_key and operation_type
report missing_rows and extra_rows

, pseudocode
compare source_events to target_events by primary_key and operation_type
report missing_rows and extra_rows

, pseudocode
compare source_events to target_events by primary_key and operation_type
report missing_rows and extra_rows

Una referencia interna útil para ese patrón de origen a destino es el artículo sobre el significado de conciliación, ya que la integridad y la conciliación suelen ser caras de la misma moneda operativa.

La puntualidad también pertenece a este conjunto de herramientas. Un conjunto de datos puede estar estructuralmente presente pero seguir incompleto para una decisión operativa si llega después de la ventana del SLA. Por eso, los datos tardíos no deben tratarse como un detalle menor. A menudo es el mismo tipo de fallo con una máscara diferente.

Si la empresa necesita los datos para las 8:00 a. m., una tabla perfectamente poblada a las 11:00 a. m. sigue estando incompleta para la decisión que debía respaldar.

Diseño de SLA y alertas que distingan el retraso de la pérdida

Un almacenamiento de datos puede estar lleno y, aun así, no cumplir con su plazo. Llega un lote, el recuento de filas parece correcto, el panel sigue en verde, pero el equipo de negocios necesitaba esa tabla antes de la hora límite matutina. El diseño de los SLA debe separar el retraso de la pérdida antes de que una alerta llegue al localizador, porque estos dos fallos requieren respuestas diferentes.

Clasificar por niveles es una forma práctica de hacerlo. El Nivel 1 debe cubrir los campos que guían las decisiones críticas, donde la falta de valores significa que los datos no son aptos para el uso. El Nivel 2 funciona para columnas operativas donde una pequeña brecha importa, pero no siempre justifica una notificación inmediata. El Nivel 3 se adapta a los campos de enriquecimiento que es mejor vigilar para detectar desviaciones que escalar ante cada cambio. El enfoque de hoja de trabajo de los CDC se adapta bien a este patrón, ya que comienza con los elementos mínimos y principales que más importan para el caso de uso y luego se expande a los campos extendidos solo cuando afectan la decisión (Hoja de trabajo de calidad de datos de los CDC).

Las líneas de base deben provenir de la propia fuente. Una caída en el volumen de eventos puede ser normal para un flujo de información y un problema real para otro, por lo que un umbral global para todo el almacenamiento de datos suele ocultar más de lo que revela. Un archivo nocturno que se mantiene estable durante meses necesita una expectativa más estricta que una API que fluctúa de manera natural con la actividad de los usuarios. La guía del Gobierno de Escocia señala lo mismo de otra manera: los analistas deben comparar un cambio con patrones anteriores y otros puntos de referencia antes de catalogarlo como real (Guía de calidad estadística del Gobierno de Escocia).

Un modelo simple de enrutamiento mantiene la respuesta alineada con el impacto comercial.

• Tablas críticas: notificar al propietario técnico de guardia de inmediato.

• Tablas operativas: enviar una alerta al canal de datos y abrir un ticket.

• Tablas de enriquecimiento: enviar un informe resumido y revisar la tendencia en la reunión semanal de governance.

El modelo de ejecución también importa. Si las comprobaciones se ejecutan en la base de datos del cliente, el equipo puede comparar la frescura, el desvío del esquema y la integridad a nivel de registro con la misma fuente de verdad, en lugar de hilar trabajos y paneles separados. digna realiza ese tipo de Observability integrada en la base de datos, combinando líneas de base históricas con validación y supervisión en una sola interfaz (Descripción general de la Observability de digna). Esa configuración cambia el panorama operativo, porque una carga tardía, una partición faltante y una rotura real del esquema pueden evaluarse en el mismo lugar antes de que alguien decida si notificar, reportar un ticket o esperar.

Investigar y corregir una comprobación de integridad fallida

Una tabla de hechos de pedidos puede superar los recuentos de filas y aun así fallar donde importa. He visto este patrón con mayor claridad cuando la tabla tenía todas las filas, pero una comprobación referencial con la dimensión de clientes comenzó a fallar después de que un lote tardío actualizó algunas claves. Al principio, los números parecían correctos, pero la unión ya no era confiable.

El primer paso es el alcance. Verifique qué particiones fallaron, qué fuentes ascendentes las alimentaron y si el problema está aislado a un solo día o se extiende a una ventana más amplia. Luego, compare las horas de llegada con el patrón de entrega esperado, ya que un lote faltante o retrasado a menudo explica el síntoma más rápido que un análisis profundo del esquema.

El segundo paso es separar las brechas temporales de las estructurales. Una brecha temporal se parece a una entrega retrasada, un retraso de actualización o una interrupción del sistema anterior. Una brecha estructural suele apuntar a un cambio de esquema, un valor predeterminado roto, un problema de enrutamiento o una regla de transformación que ya no coincide con la fuente.

En un incidente, la causa raíz fue un cambio de esquema que introdujo un nuevo código de estado sin una ruta de gestión predeterminada. La solución no fue simplemente "volver a ejecutar el trabajo". El equipo tuvo que decidir si actualizar los datos históricos desde los registros de CDC, aceptar la brecha con una excepción documentada o bloquear a los consumidores de datos posteriores hasta que la dimensión del cliente volviera a ser coherente. La respuesta correcta depende de si la decisión de los procesos posteriores puede tolerar datos parciales.

Un flujo simple de triaje ayuda:

1. Confirmar la naturaleza del fallo. ¿Se trata de pérdida de filas, de campos o de referencias?

2. Comprobar los tiempos en los sistemas anteriores. ¿Llegó el origen tarde o no llegó?

3. Inspeccionar el historial. ¿Es esto inusual para este origen o es una variación normal?

4. Elegir la solución. Actualizar datos históricos, suprimir, bloquear o documentar.

Ese flujo de trabajo es más rápido cuando su almacenamiento de datos ya guarda el linaje, la frescura y el historial de comprobaciones de forma que los operadores puedan inspeccionarlos sin tener que saltar entre cinco herramientas distintas.

Cómo una plataforma de Observability en la base de datos redefine el panorama

Muchos equipos aún ejecutan comprobaciones de integridad como SQL programados, ven los resultados en BI e implementan alertas por chat. Eso funciona hasta que la cantidad de pipelines de datos crece y las comprobaciones comienzan a competir con el desarrollo del producto. Una plataforma de Observability en la base de datos cambia el panorama operativo ejecutándose donde ya viven los datos y aprendiendo de las métricas históricas, en lugar de obligar a ajustar manualmente cada comprobación.

Esa distinción importa por dos razones. Primero, los datos del cliente permanecen en su propio entorno cuando la plataforma se ejecuta en la base de datos, lo que mitiga el movimiento de datos y mantiene los registros confidenciales en nubes privadas o infraestructuras locales. Segundo, la plataforma combina señales de Observability como la detección de anomalías, la puntualidad y el seguimiento de esquemas con reglas de validación de calidad de datos en un solo lugar, en lugar de exigir a los ingenieros que estructuren herramientas separadas para cada capa.

El resultado práctico es una infraestructura de detección más pequeña. En lugar de docenas de trabajos programados, obtiene un conjunto más ajustado de inspecciones siempre activas que vigilan las llegadas faltantes, los desvíos de esquemas y los comportamientos inesperados frente a líneas de base aprendidas. Esto se adapta mejor cuando el almacén de datos es grande, las fuentes son volátiles y el negocio necesita una respuesta rápida sobre si una brecha es un retraso o una pérdida real.

Para los equipos que desean mantener los controles cerca de los datos, la descripción general de la plataforma digna muestra el modelo claramente. No es un reemplazo para un buen diseño del almacén de datos y no salvará un modelo de propiedad débil, pero reduce drásticamente el tiempo entre la detección, el triaje y la respuesta.

Una lista de verificación de integridad de una semana para sus flujos de trabajo

Comience con dos elementos de datos críticos por pipeline y luego defina una comprobación a nivel de atributo y otra a nivel de registro para cada uno. Eso evita el clásico error de monitorear todos los campos por igual y pasar por alto los que rompen los controles.

Luego, agregue una marca de agua o un diff de CDC. Eso detecta pérdidas silenciosas de lotes y cargas incrementales estancadas, cosas que los recuentos de filas por sí solos pueden omitir. Si el pipeline funciona por lotes, compare los tiempos de llegada con el cronograma previsto para que una entrega tardía no active la misma respuesta que una faltante.

Después de eso, establezca SLA por niveles. Asigne umbrales estrictos y un enrutamiento rápido a las tablas más importantes, y mantenga los campos de enriquecimiento bajo supervisión de tendencias para no saturar al equipo con alertas innecesarias.

Programe una revisión semanal para que los operadores evalúen las anomalías, ajusten los umbrales y documenten las excepciones. Ese es el momento en que la integridad se convierte en un control continuo en lugar de una regla puntual.

La integridad no es un número que se alcanza, es una decisión de idoneidad para el uso que se toma y se revisa continuamente.

digna ayuda a los equipos a ejecutar comprobaciones de integridad de datos donde los datos ya residen, para luego emparejarlas con supervisión de anomalías, puntualidad y esquemas en un único entorno controlado. Si desea reforzar la confianza en su almacén de datos sin dispersar comprobaciones en scripts y de paneles, visite digna y conozca cómo la Observability en la base de datos puede integrarse en el proceso de revisión de sus flujos de datos.