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

Definición del SLA

Contenido abierto

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

Lección 1 de 5

Definición del SLA

Un SLA de streaming debe traducirse en indicadores medibles de frescura, completitud, corrección y disponibilidad, con ventanas y responsables explícitos.

Duración
30 min aprox.
Objetivo
Un SLA de streaming debe traducirse en indicadores medibles de frescura, completitud, corrección y disponibilidad, con ventanas y responsables explícitos.
Siguiente paso
Continuar con la siguiente lección
Ver detalles del módulo

Proyecto de streaming con SLA

Entrega un flujo operable que soporte datos tardíos, recuperación e incidentes reproducibles.

Al terminar podrás
  • Cumplir SLA de frescura y completitud
  • Recuperar sin duplicados
  • Crear métricas y runbook
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 2026
Nivel
Professional
Ruta relacionada
streaming
Dominios blueprint
Streaming production readiness
Estado
Revisión editorial interna
Fuentes principales
Production considerations for Structured Streaming · Databricks · Monitor Structured Streaming queries · Databricks
Reportar un error
01
Modelo mental

Definición del SLA

Un SLA de streaming debe traducirse en indicadores medibles de frescura, completitud, corrección y disponibilidad, con ventanas y responsables explícitos.

Mostrar prerrequisitos
Dificultad
Professional
Prerrequisitos
m16
Reportar un error en esta lección

Decir 'tiempo real' no permite diseñar ni operar. Un SLO útil puede exigir que el p95 de `published_at - event_ts` sea inferior a cinco minutos y que al menos el 99,5% de eventos válidos aparezcan antes de quince minutos. La completitud se reconcilia con una fuente autoritativa, no con que el stream siga activo.

Cada indicador necesita una fuente de medición, periodo y presupuesto de error. Un watermark de diez minutos no garantiza por sí mismo diez minutos de frescura: el backlog, el trigger y el sink también cuentan. La arquitectura se valida contra los SLO, no al revés.

Modelo mental

Un SLA de streaming no es la frase tiempo real; es un contrato cuantificado entre productor, plataforma y consumidor. Se descompone en indicadores: frescura del evento publicado, completitud respecto a la fuente, corrección de reglas, disponibilidad de lectura y tiempo de recuperación. Cada indicador necesita método, ventana, percentil, presupuesto de error y dueño. La frescura puede medirse como reloj menos máximo event time válido, mientras que la latencia de microbatch es solo un componente interno. Un p95 de cinco minutos permite colas ocasionales que un máximo estricto no permitiría. RPO expresa cuántos datos podrían perderse y RTO cuánto se tarda en restaurar el servicio; checkpoints y replay deben demostrar ambos. El contrato también define comportamiento degradado: si Kafka se retrasa, puede ser mejor servir datos marcados como stale que bloquear una tabla consistente y disponible.

SLI

Medida concreta del comportamiento observado, como frescura p95 o porcentaje de eventos reconciliados.

Convierte expectativas ambiguas en datos sobre los que se pueden alertar y mejorar.
SLO

Objetivo interno para un SLI durante una ventana, normalmente más estricto que el límite contractual externo.

Crea margen operativo y guía decisiones de capacidad y fiabilidad antes de incumplir el SLA.
RPO/RTO

Máxima pérdida de datos aceptable y máximo tiempo para recuperar el servicio tras un incidente.

Conecta checkpoints, retención, replay y runbooks con compromisos verificables de continuidad.
SQLIndicadores de frescura y completitud
WITH stream AS (
  SELECT
    date_trunc('hour', event_ts) AS hour,
    percentile_approx(
      unix_timestamp(published_at) - unix_timestamp(event_ts),
      0.95
    ) AS freshness_p95_s,
    count(DISTINCT event_id) AS published_events
  FROM main.silver.clickstream
  WHERE event_ts >= current_timestamp() - INTERVAL 24 HOURS
  GROUP BY 1
)
SELECT * FROM stream ORDER BY hour DESC;

La completitud necesita comparar `published_events` con un conteo independiente de la fuente o un manifiesto de productores.

Puntos clave

  • Frescura compara tiempo de negocio publicado con el reloj; disponibilidad solo indica si el proceso está ejecutándose.
  • Completitud requiere un denominador o reconciliación autoritativa.
  • El presupuesto de error determina cuándo una desviación es incidente y qué cambios se priorizan.

Evita

  • Medir solo duración de microbatch y llamarla frescura de negocio.
  • Fijar un SLA sin definir zona horaria, percentil, ventana ni exclusiones de eventos inválidos.

Recuerdo activo

¿Por qué una consulta `ACTIVE` puede incumplir frescura?

Borrador privado · solo en este navegador
5 lecciones pendientes

Fuente revisada · vista externa

Databricks Free Declarative Pipelines

Databricks Free Declarative Pipelines · commit a515370

docs/3-2-building-bronze-sql.md

Lectura en GitHub

Este notebook se abre desde su fuente revisada

El repositorio no permite republicar su contenido dentro de Lakehouse Lab. Conservamos la misma experiencia lateral, la ruta exacta y el commit auditado, y dejamos la lectura en GitHub para respetar la autoría.

Autor
andkret
Licencia
No verificada
Formato
project
Ver notebook en GitHub