Proyecto streaming

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.

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;

Bronze conserva el evento original y coordenadas de origen. Silver valida esquema, deduplica y aplica reglas temporales. Gold sirve agregados con la latencia acordada. Cada consulta tiene un checkpoint exclusivo y cada tabla una clave o contrato que permite recomponerla desde una capa anterior.

La capacidad se diseña para la tasa sostenida más un margen de recuperación. Si tras una hora de caída llegan diez millones de eventos, el pipeline debe procesar más rápido que la tasa normal para volver al SLA. Separar ingestión de agregación evita que un operador stateful pesado bloquee la captura de entrada.

pipeline: clickstream
sources:
  - main.bronze.web_events
targets:
  silver: main.silver.web_events
  gold: main.gold.sessions_5m
slo:
  freshness_p95_seconds: 300
  completeness_percent: 99.5
recovery:
  rto_minutes: 30
  replay_source: main.bronze.web_events
owner: data-platform-oncall

Un fallo transitorio del executor suele resolverse reanudando desde el mismo checkpoint. Un cambio incompatible de estado requiere checkpoint nuevo y reconstrucción desde bronze. Un error lógico publicado exige identificar versiones o tiempos afectados, corregir código y escribir de forma idempotente en un destino aislado antes del cutover.

La retención de Kafka, CDF, archivos y Delta debe cubrir el RTO y el máximo tiempo de detección. Si el origen ya eliminó datos, restaurar compute no recupera completitud. Los runbooks incluyen criterios para pausar productores o consumidores, rutas alternativas y validación posterior.

SELECT
  min(event_ts) AS first_affected,
  max(event_ts) AS last_affected,
  count(*) AS affected_rows,
  count(DISTINCT event_id) AS affected_events
FROM main.silver.web_events
WHERE pipeline_version = '2026.07.20-bad'
  AND event_date BETWEEN DATE '2026-07-20' AND DATE '2026-07-21';

El progreso de la consulta muestra duración, tasas y estado; Kafka o Auto Loader aportan backlog; las tablas silver aportan máximo event time y descartes. Una alerta de frescura debe enlazar esas señales para diferenciar fuente parada, cuello de proceso, dato inválido o sink lento.

Las métricas se escriben en una tabla con `query_id`, `batch_id`, versión y timestamp. Un dashboard sin alertas ni propietario no reduce tiempo de recuperación. Cada alarma debe incluir umbral, periodo, severidad, enlace a evidencia y primera acción segura.

import json
from pyspark.sql import Row

progress = query.lastProgress or {}
record = Row(
    query_id=str(query.id),
    batch_id=progress.get("batchId"),
    observed_at=progress.get("timestamp"),
    input_rps=progress.get("inputRowsPerSecond", 0.0),
    processed_rps=progress.get("processedRowsPerSecond", 0.0),
    progress_json=json.dumps(progress),
)
spark.createDataFrame([record]).write.mode("append").saveAsTable(
    "main.ops.streaming_progress"
)

La prueba puede detener compute durante diez minutos, introducir un evento tardío y reiniciar desde el mismo checkpoint. Se mide tiempo hasta recuperar frescura, lag máximo, duplicados y completitud. Otra prueba despliega un cambio stateful incompatible en un entorno aislado para practicar rollback o rebuild.

El runbook se escribe como decisiones observables: si el checkpoint está íntegro y el código es compatible, reanudar; si faltan offsets, escalar pérdida y reconciliar; si el sink tiene efectos externos, verificar idempotencia. El resultado del ejercicio genera acciones con responsable y fecha.

experiment: stop-streaming-compute
preconditions:
  - bronze_backlog_is_zero
  - baseline_freshness_p95_lt_300s
fault:
  duration_minutes: 10
success:
  - no_duplicate_event_ids
  - completeness_percent_gte_99.5
  - freshness_recovered_within_30m
rollback:
  - resume_original_job
  - preserve_checkpoint
owner: data-platform-oncall