Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLección 3 de 5
Seguridad, interoperabilidad y CI/CD
Opera el producto con expectations, event logs, system tables, lineage, alertas y runbooks que cubran datos y plataforma.
21 min aprox.
03OperaciónSeguridad, interoperabilidad y CI/CD
Opera el producto con expectations, event logs, system tables, lineage, alertas y runbooks que cubran datos y plataforma.
+
Seguridad, interoperabilidad y CI/CD
Opera el producto con expectations, event logs, system tables, lineage, alertas y runbooks que cubran datos y plataforma.
La observabilidad se diseña en capas: freshness y completitud del producto, calidad de registros, estado/duración/retries del pipeline, perfiles de consulta y coste. Expectations pueden fallar, descartar o registrar según severidad; event logs de pipelines explican updates y calidad; system tables agregan jobs, queries, billing, audit y lineage.
Una alerta debe ser accionable: incluye umbral, ventana, owner, contexto y enlace al runbook. Evita alert fatigue agrupando síntomas del mismo fallo. En recuperación, valida downstream y no sólo el run. Usa lineage para impacto, audit para actor/cambio y Query Profile/Spark UI para rendimiento. Ensaya RTO con game days.
CREATE OR REPLACE VIEW ops.slo.orders_freshness AS
SELECT
MAX(processed_at) AS last_processed_at,
TIMESTAMPDIFF(MINUTE, MAX(processed_at), current_timestamp()) AS freshness_minutes,
CASE
WHEN TIMESTAMPDIFF(MINUTE, MAX(processed_at), current_timestamp()) <= 15
THEN 'OK'
ELSE 'BREACH'
END AS slo_state
FROM prod.silver.orders;Distingue ausencia legítima de eventos de pipeline detenido; combina freshness con señal del origen y calendario de negocio.
¿Qué diferencia una métrica de producto de una métrica de ejecución?
Profundiza
Operar un producto de datos exige observar plataforma y significado. Una tarea verde sólo indica que el código terminó; no demuestra frescura, completitud ni exactitud. Expectations miden reglas en el flujo y pueden advertir, descartar o fallar según gravedad. El event log del pipeline explica updates y calidad; system tables aportan historia de jobs, queries, compute, coste, audit y lineage; las tablas de negocio aportan reconciliaciones. Las alertas se enlazan a un SLO y un runbook, con owner y acción inicial. El diseño también presupone que una fuente de observabilidad puede ser parcial o retrasada, por lo que combina señales y mantiene IDs comunes para reconstruir un incidente.
Regla declarativa de calidad asociada a un dataset que registra o aplica una acción cuando una fila la incumple.
Convierte contratos de datos en telemetría y control durante procesamiento, antes de publicar resultados defectuosos.Cantidad tolerada de incumplimiento de un SLO durante una ventana, derivada del objetivo de fiabilidad acordado.
Equilibra entrega y estabilidad y proporciona una señal objetiva para priorizar trabajo de fiabilidad.Ejercicio controlado que introduce un fallo previsto para comprobar alertas, roles, runbooks y capacidad real de recuperación.
Detecta procedimientos incompletos antes de un incidente y transforma documentación no ejecutada en evidencia operativa.Resumen
Puntos clave
- Mide producto, datos, ejecución y coste por separado.
- Cada alerta conduce a una decisión concreta y un owner.
- Prueba recovery y RTO; no confíes sólo en documentación.
Evita
- Alertar por cada tarea fallida aunque el retry automático recupere dentro del SLO.
- Declarar recuperación al ver un run verde sin medir freshness, duplicados y consumidores.