Integridad de datos

1) Qué es la integridad de los datos

La integridad de datos es un conjunto de propiedades y controles que garantiza que los datos son correctos, consistentes y consistentes en todo el ciclo de vida: desde fuentes y transformaciones hasta escaparates, APIs y exportaciones. El objetivo es que la misma afirmación dé la misma respuesta cuando se repita, y que cualquier cambio sea rastreable y verificable.

2) Tipos de integridad y dónde viven

Entity: claves primarias únicas, sin duplicados.
Referencia (Referential): enlaces FK correctos; la ausencia de referencias «colgantes».
Dominio: rangos y formatos válidos (tipo, longitud, referencias).
Reglas de negocio: invariantes de área de tema (balance ≥ 0, suma de cableado = 0, etc.).
Temporal: monotonía y consistencia de las marcas de tiempo, zonas de tiempo correctas.
Directivas de acceso: RLS/CLS no violan la coherencia lógica de los datos visibles.

3) Contratos de datos y esquemas (fuente de la verdad)

Establecemos contratos formales para conjuntos y eventos; los aplicamos en la entrada y después de cada transformación.

yaml dataset: payments primary_key: txn_id foreign_keys:
- fk: user_id -> users.user_id schema:
- {name: txn_id, type: string, unique: true}
- {name: user_id, type: string, not_null: true}
- {name: amount, type: decimal(18,2), min: 0}
- {name: currency, type: string, in: [USD,EUR,TRY,UAH]}
- {name: event_time, type: timestamp, tz: UTC}
dq_rules:
- "duplicates(txn_id)=0"
- "ref_integrity(user_id, users.user_id)=true"
- "sum(amount) >= 0"
evolution:
semver: [MAJOR, MINOR, PATCH]
breaking_changes_require: approval:data-governance

4) Garantías de transacción y aislamiento

ACID para OLTP: atomicidad, consistencia, aislamiento, durabilidad.
Niveles de aislamiento: Read Committed/Repeatable Read/Serializable - elija bajo el riesgo de lecturas «sucias «/irrepetibles/fantasmas.
OLAP y lakehouse: commits atómicos de tabla (transaction log), idempotent sink y schema-evolution con control de compatibilidad.
Consistencia de fórmulas KPI: una capa semántica → una verdad para informes y API.

5) Sistemas distribuidos: orden, repeticiones, idempotencia

Orden de eventos: usamos 'event _ time' + 'ingested _ at', watermarks y tolerancia lateness; agregados basados en tiempo de evento.
Envíos repetidos (at-least-once): global 'event _ id', tablas idempotency keys, upsert/merge por clave sostenible.
Fuera de orden: re-cálculo de ventanas, estrategia de retraso, compensación.
Exactly-once por sentido: el transporte puede ser en-least-once, el receptor es idempotente.

6) Validación de integridad (DQ) en cada capa

• Freshness/Completeness/Uniqueness/Valid Values/Referential Integrity.
• Anomalías: ráfagas de duplicados, brechas de tiempo, cambios bruscos en las distribuciones.
• Control de fórmulas KPI: versionabilidad de cálculos y pruebas de coincidencia de resultados (sets de oro).
• Control de las exportaciones: prohibición de la emisión de conjuntos infractores (quarantine).

yaml expect_column_values_to_be_unique: {column: txn_id}
expect_column_values_to_not_be_null: {column: user_id}
expect_column_values_to_be_in_set: {column: currency, value_set: [USD,EUR,TRY,UAH]}

7) Integridad financiera y operativa

Doble entrada (doble entrada): débito/crédito en el balance; conciliaciones resumidas en cut-off.
Invariantes totales: importe de los pagos = importe de los cargos + comisiones + ajustes.
Invariantes operativos: las métricas SLA/guardrail no rompen las reglas del negocio (por ejemplo, las reparaciones automáticas no crean duplicados).

8) Lineage, auditoría y reproducibilidad

Linage: de la fuente a las vitrinas/fich; visibilidad de transformaciones y propietarios.
Audit Trails: quién cambió qué, cuándo y por qué; versiones de esquemas/fórmulas/jobs.
Snapshots/checkpoints: capacidad para volver a calcular y confirmar informes pasados.
Repro: la misma consulta en el mismo corte → el mismo resultado (versiones y capas).

9) Seguridad y privacidad sin pérdida de integridad

RLS/CLS: los filtros de fila/columna no deben interrumpir los invariantes (por ejemplo, la suma de la muestra visible debe coincidir con la declarada).
Enmascaramiento/tokenización: estrategias deterministas para mantener el dedoup y la integridad referencial.
Cifrado: en el canal y «en el disco» después de la compresión; administración de claves y auditoría de accesos.
DSAR/Retention: la eliminación/anonimización no rompe la conectividad (política en cascada).

10) Autoservicio y reparación automática

Quarantine: aislamiento de lotes/batches sospechosos; los consumidores son una rama «limpia».
Replay/Backfill: volver a jugar una ventana de un registro raw inmutable.
Reconcile: conciliar capas y sistemas (raw↔curated↔marts; istochnik↔DWH).
Dedup/Compaction/Rebuild: procedimientos del sistema para reparar índices/agregados.
Policy-as-code: «qué anomalía → qué acción → umbrales → escalada».

11) Prácticas de modelado y almacenamiento

Claves estables: PK subrogado (UUID/ULID), claves naturales inalterables en los manuales.
Normalizatsiya↔denormalizatsiya: Enlaces FK en fuentes, vitrinas desnormalizadas con control de versión lógica.
SCD1/SCD2: una historia manejable para las mediciones.
Ordenar/agrupar: mejora el RLE/zone-maps y simplifica las conciliaciones.
Hashes y sumas de comprobación: verificación de la integridad de archivos/lotes.

12) Integridad en el tiempo y en la presentación de informes

Versiones de fórmulas: el informe de enero de 2025 debe reproducirse mediante la fórmula de la versión X.
Corte-apagado y «cierre de periodo»: congelación de escaparates y cortes de archivo.
Late arriving facts: mecánica de dosificación y recuento con marca de la versión del informe.
Documentación de redefiniciones: ajustes manuales - sólo con auditoría.

13) Integraciones y API

Contrato API: esquemas, tipos, campos obligatorios, códigos de error; versionar (v1/v2).
Validación en la entrada: reject mal payload's, no «arreglar en silencio».
Idempotent POST: clave de idempotencia, la repetición es segura.
Exportar a archivos: consistencia de lotes, hashes, firmas.

14) Antipattern

SELECT en solicitudes prod y pinzas - se rompe en la evolución MINOR.
FK «en palabras»: no hay verificación real de los enlaces.
Correcciones silenciosas de datos sin auditoría ni informes.
Mezcla de TZ y formatos de tiempo en un solo conjunto.
Redefiniciones de KPI por «lápices» sin versiones ni registros.
La única clave de desduplicación sin estrategias de repuesto.
Eliminación por DSAR sin verificación en cascada de vínculos.

15) Hoja de ruta para la implementación

1. Inventory & Criticidad: kits de mapa/eventos, propietarios, riesgos, invariantes.
2. Contratos y esquemas: formalizar tipos/restricciones/FK, pruebas de compatibilidad CI.
3. DQ en pipeline: Freshness/Completeness/Uniqueness/RI, quarantine, alertas.
4. Base transaccional: atomic-sink, upsert/merge, historia SCD, versionabilidad de fórmulas.
5. Lineage and Audit: directorio, seguimiento, change-logs, access-logs.
6. Políticas de reparación: replay/backfill/dedup/reconcile como código; runbook’и и SLO MTTR-data.
7. Seguridad: RLS/CLS, enmascaramiento, cifrado, procesos DSAR.
8. Informes: cut-off, cortes libres, control de versiones de KPI.

16) Check-list antes del lanzamiento del kit/escaparate

• PK/FK y las restricciones de dominio se establecen y pasan las pruebas.
• Se habilita la versificación de esquemas/fórmulas; schema-diff verde.
• Reglas DQ (frescura/plenitud/singularidad/rangos/RI) verdes.
• Registros idempotentes: upsert/merge, clave de idempotencia (para eventos).
• Tiempo: 'event _ time' e 'ingested _ at', TZ = UTC; política de datos late.
• La línea y la auditoría son visibles; quarantine y alertas incluidas.
• El RLS/CLS/enmascaramiento no rompe invariantes y RI.
• DSAR/Retention probados; cut-off/archivo listo.

17) Mini plantillas

SQL: verificación de integridad de referencia

sql select count() as orphans from fact_payments f left join dim_users u on f.user_id = u.user_id where u.user_id is null;
-- ожидаем orphans = 0

Política quarantine/repair (pseudo-YAML)

yaml policy: payments_integrity detect:
- rule: duplicates(txn_id) > 0
- rule: ref_integrity(user_id, users.user_id) = false auto_actions:
- quarantine_partition: {date: today}
- trigger_replay: {window: "last_2h"}
escalate_if:
- condition: violations_persist>30m page: "oncall-data"

Diagrama de SCD2 para medición

sql
-- dim_user_status (SCD2)
user_id, status, valid_from, valid_to, is_current

18) Resultado

La integridad de los datos no es una verificación aislada, sino un sistema de garantías transversales: contratos formales y restricciones, invariantes transaccionales y distribuidos, validación y automatización de reparaciones, lineage y auditoría, privacidad y derechos. Cuando estos elementos trabajan juntos, los datos se convierten en una base confiable para las soluciones, y los incidentes son raros, cortos y predecibles.