Saltar al contenido
Lakehouse LabLakehouse LabPreparación Databricks Data Engineer
Módulo 32 · Lección

Seguridad, interoperabilidad y CI/CD

Contenido abierto

Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.

Lecció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.

Duración
21 min aprox.
Objetivo
Opera el producto con expectations, event logs, system tables, lineage, alertas y runbooks que cubran datos y plataforma.
Siguiente paso
Continuar con la siguiente lección
Ver detalles del módulo

Proyecto Professional y simulacro de 59 preguntas

Converge las cuatro ramas en una solución production-grade y mide la preparación final.

Al terminar podrás
  • Diseñar y defender una plataforma completa
  • Responder a fallos, costes y cumplimiento
  • Completar un simulacro Professional original
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 2026
Nivel
Professional
Ruta relacionada
final
Dominios blueprint
Todos los dominios Professional
Estado
Revisión editorial interna
Fuentes principales
Data Engineer Professional exam guide · Lakeflow Jobs
Reportar un error
03
Operación

Seguridad, interoperabilidad y CI/CD

Opera el producto con expectations, event logs, system tables, lineage, alertas y runbooks que cubran datos y plataforma.

Mostrar prerrequisitos
Dificultad
Professional
Prerrequisitos
m17, m22, m27, m31
Reportar un error en esta lección

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.

Modelo mental

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.

Expectation

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.
Error budget

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.
Game day

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.
SQLIndicador de freshness consumible por alertas
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.

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.

Recuerdo activo

¿Qué diferencia una métrica de producto de una métrica de ejecución?

Borrador privado · solo en este navegador
5 lecciones pendientes

Vista de lectura · sin ejecución

Startup ERP Data Lakehouse

Startup ERP Data Lakehouse · commit ba6c71b

notebooks/01_bronze_generate_startup_erp_data.py