Datos de auto-recuperación

1) Definición y objetivos

Los datos autocomplacientes son un enfoque de ingeniería de datos en el que los defectos se detectan automáticamente y las acciones correctivas (reparación, re-entrega, retroceso, reconsificación, re-indexación) se realizan sin la participación humana o con una intervención mínima (human-in-the-loop para casos sensibles).
Objetivos: reducir los datos MTTR, aumentar la confianza, la resistencia a la deriva y las interrupciones, el costo predecible de propiedad.

2) Fallas típicas por las que se debe tratar

Esquemas y contratos: cambios incompatibles, columnas desaparecidas, conflictos tipo.
Calidad/integridad: duplicados, omisiones, violaciones de la singularidad/integridad referencial.
Tiempo y frescura: retardos de los higos, «agujeros» en las ventanas, resincronización de TZ/locales.
Identificadores y claves: cambio de generador de ID, colisiones, llaves naturales flotantes.
Orden de los eventos: eventos atrasados, reordenación, reenvío (at-least-once).
Repositorios: degradación de lotes, archivos rotos/bloques, deformación de sharding.
Derechos/seguridad: máscaras/cifrado incorrectos, fugas PII en las descargas.

3) Pilares de auto-recuperación

1. Contratos de datos (schemas + reglas) con pruebas automáticas.
2. Paipelines idempotentes (reinicio sin efectos dobles).
3. Registro y reproducibilidad (raw/bronze inmutable, lineage).
4. Mecanismos de reparación (replay, backfill, compaction, merge-repair, rebuild).
5. Observabilidad y SLO (frescura, plenitud, singularidad, latencia).
6. Políticas de toma de decisiones (cuando la autoficción, cuando escalamos).

4) Contratos y pruebas de calidad

El contrato describe: esquema, rangos permitidos, singularidades, RLS/enmascaramiento, frescura SLA.

yaml dataset: payments 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: created_at; type: timestamp; tz: UTC freshness_sla: 15m constraints:
- "count(distinct txn_id) = count()"
- "pct_null(user_id) < 0. 1%"
privacy:
- mask: card_pan -> BIN6LAST4 actions_on_violation:
- auto_quarantine_partition
- backfill_missing_window
- notify_owner_and_open_ticket

Las pruebas se realizan en cada paso: higo → staging → escaparate. La violación de las reglas activa la reparación automática (ver abajo) y/o la cuarentena.

5) Idempotencia y determinismo

Upsert/Merge en llaves estables (SCD2 para historial, SCD1 para cortes).
Transformaciones deterministas: una entrada → una salida con los mismos parámetros.
Control de versiones: capture la versión de código/diagramas/capas y el rótulo de datos (watermark).
Idempotent sink: escribir a través de staging + atomic swap/rename.
Exactly-once en el sentido: aceptable «at-least-once» transporte + receptor idempotente.

6) Mecanismos de reparación automática (repair toolkit)

Replay/Backfill: volver a enviar por la ventana 't ∈ [T0, T1]' desde un registro (raw) inmutable.
Reconciliation (conciliación): comparación de agregados/claves entre capas (raw ↔ curated ↔ marts) y entre sistemas (fuente ↔ DWH).
Deduplication: window-dedup por clave (txn_id, event_id) + heurística de distancias (fuzzy para llaves «sucias»).
Compaction: reenviar archivos pequeños en lotes grandes (Parquet/ORC), re-indexación.
Merge-repair: en un conflicto de registros, los predicados de prioridad (por origen/tiempo/versión).
Reducción de índices/materializaciones: recuento de agregados/cubo/roll-up.
Quarantine/Shadow: los lotes sospechosos se aíslan; los consumidores leen la rama «limpia».
Schema mediation: selector automático de proyecciones (relleno de impagos, columnas calculadas) en cambios menores.

7) Protección del almacenamiento e integridad

Suma de cheques y validación de bloques (CRC, paridad).
Almacenamiento de quórum (sistemas compatibles con RAFT/Paxos, quorum reads/writes).
Codificación de borrado (código erasure) para una redundancia rentable.
Versionar objetos (object store versioning, undelete).
Atomic commit в Lakehouse (transaction log, ACID-таблицы: Delta/Iceberg/Hudi).

8) Orden de los acontecimientos y «realidad sucia»

Eventos atrasados: mantenga lateness-window, use watermark 'y; volver a calcular las ventanas.
Volver a enviar: dedup por 'event _ id' global, tablas idempotency-keys.
Tiempo desplazado: normalización de TZ, almacenamiento de 'ingested _ at' y 'event _ time'.
Out-of-order: unidades basadas en event_time con ajuste por watermark.

9) Lógica de la toma de decisiones (motor de políticas)

Regla: «qué anomalía → qué acción → qué umbrales → quién es el propietario».

yaml policy: payments_freshness detect: freshness_delay > 15m auto_actions:
- trigger: backfill(last_60m)
- if: gap_persisted > 30m then: quarantine_partition(date=today, hour=current_hour)
escalate:
- if: gap_persisted > 60m -> page_oncall:data guardrails:
- do_not_expose_unverified_to_marts

10) Observabilidad y SLO para datos

• Frescura (Freshness) vitrinas ≤ 15 min.
• Completeness> 99. 5% en campos clave.
• Uniqueness (Uniqueness): duplicados <0. 01%.
• Latencia del cálculo: p95 <5 min.
• Sostenibilidad de la reparación: MTTR-data <30 min.

Métricas y alertas: exponer en Prometheus/Grafana; construya una cinta prioritaria de incidentes de datos.

11) Reconsificación y conciliación (prácticas)

Conciliación de unidades: 'count/sum/min/max' entre capas/sistemas en una ventana deslizante.
Conciliación de claves: diferencia simétrica de conjuntos 'Δ = (A\B) ∪ (B\A)'.
«audit job» periódico: comparación con la fuente, verificación selectiva en la primaria.
Pagos/finanzas: doble entrada (doble entrada), cotejo de corte diario, registro de ajustes.

12) Gestión de esquemas y evolución

SemVer para circuitos: MAJOR (rompe )/MINOR (añade )/PATCH (corrige).
Contratos en CI/CD: schema-diff, interoperabilidad, autogeneración de migraciones.
Backfill-hook: en MINOR, agregue defectos/campos calculables, vuelva a calcular las vitrinas.
Proyecciones flexibles: los lectores leen subconjuntos de columnas; prohibimos «SELECT».

13) Seguridad, privacidad, cumplimiento

RLS/CLS: filtros de filas/columnas, especialmente en ramas de reparación y exportaciones.
Enmascaramiento PII: determinista (tokenización) para la deduplicación sostenida.
Auditoría de acceso/exportación: quién vio lo que exportó, a dónde lo envió.
DSAR/Retention: auto-eliminación/anonimización en procesos de reparación; las revisiones tienen en cuenta los requisitos legales.

14) Costo y rendimiento

Backfill de coste-aware: limitación del ancho de las ventanas (por ejemplo, deslizamiento 3-7 días).
Materializaciones y cachés: volver a calcular sólo los lotes modificados (incremental).
Priorización: primero escaparates críticos (finanzas, riesgos), luego analíticos.
Reparaciones off-peak: ventanas nocturnas/prioridad baja en el planificador.

15) Pruebas y simulaciones de incidentes

Chaos-data-testing: rompe deliberadamente los lotes/circuitos en el filete.
Retardos falsos: simular saltos de batch, fuera de orden, duplicados.
Datasets de oro: puntos de referencia para la conciliación después de la reparación.
GameDays: entrenamiento regular del equipo de runbook 'am.

16) Antipattern

Correcciones «invisibles»: correcciones silenciosas sin auditoría ni informes.
Backfill's impenetrables: no hay fuente de verdad/versión de fórmulas.
Consultas en vivo pesadas a OLTP cuando se repara: remata el prod.
SELECT en los consumidores: se rompe en cualquier cambio MINOR.
La única clave de deduplicación: ninguna clave fallback/firma hash.

17) Hoja de ruta para la aplicación

1. Discovery: kits críticos/métricas, riesgos, propietarios; Mapa de dependencias.
2. Contratos y pruebas: formalizar los esquemas/reglas en CI; glosario publicado.
3. Idempotencia: Reenviar las líneas clave en upsert/merge, atomic sink.
4. Registro raw y enlace: capa inmutable, metadatos completos, watermark 'i.
5. Repair-mecánicos: backfill/replay, dedup, compaction, quarantine; policy engine.
6. Observabilidad y SLO: dashboards de calidad, alertas, cinta prioritaria.
7. Chaos-data y entrenamiento: enseñanzas regulares + runbook 'y.
8. Optimización de costes: revalorizaciones incrementales, priorización de ventanas.

18) Lista de verificación antes del lanzamiento

• Los contratos de datos y las pruebas de calidad cubren conjuntos críticos.
• Los pipelines son idempotentes; hay commit atómico y retrocesos.
• Configurado backfill/replay y quarantine, se especifican las políticas de escalamiento.
• Métricas Freshness/Completeness/Uniqueness/Latency y alertas en venta.
• Auditoría de revisiones/reparaciones habilitada; se almacenan versiones de fórmulas y escaparates.
• DSAR/Retention se cumplen en las reparaciones y revisiones.
• Hay un runbook 'y, se han realizado ejercicios, se ha fijado un objetivo MTTR.
• El costo del backfill está limitado a los guardas del presupuesto.

19) Ejemplos de autocaravanas (plantillas)

«El fracaso de la frescura del escaparate X» → backfill (last_2h) → si no cerca de 30 min → quarantine + página on-call.
La «ráfaga de duplicados txn_id» → incluir una dedup + conciliación estricta con la fuente → un informe de causa.
El «cambio de esquema MINOR» → generar un campo de default calculado → los agregados rebuild.
La «pérdida de lotes» → restaurar de un objeto versionado → verificación con una suma de cheques.

En pocas palabras: los datos auto-recuperables no son un «script de reparación», sino una arquitectura de sistemas: contratos formales, paipelines idempotentes, registro confiable, mecánicas de reparación automatizadas y observabilidad transparente con estrictos SLO. Tal sistema no solo se arregla a sí mismo, sino que también convierte los incidentes en eventos administrados con un costo y tiempo de recuperación comprensibles.