Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 4 de 5
Backfills y ventanas de proceso
Concurrencia, queueing, timeouts y notificaciones determinan cómo responde el Job cuando llegan triggers más rápido de lo que termina el trabajo.
- Duración
- 17 min aprox.
- Objetivo
- Concurrencia, queueing, timeouts y notificaciones determinan cómo responde el Job cuando llegan triggers más rápido de lo que termina el trabajo.
- Siguiente paso
- Continuar con la siguiente lección
Ver detalles del módulo
Triggers, alertas, backfills y operación
Opera pipelines según disponibilidad real del dato y recupera ventanas históricas sin romper producción.
- Elegir trigger por evento o calendario
- Diseñar backfills seguros
- Crear alertas accionables y SLOs
04DiagnósticoBackfills y ventanas de proceso
Concurrencia, queueing, timeouts y notificaciones determinan cómo responde el Job cuando llegan triggers más rápido de lo que termina el trabajo.
+
Backfills y ventanas de proceso
Concurrencia, queueing, timeouts y notificaciones determinan cómo responde el Job cuando llegan triggers más rápido de lo que termina el trabajo.
Por defecto, un Job suele admitir un run activo. Aumentar `max_concurrent_runs` puede reducir espera, pero solo si runs simultáneos escriben rangos aislados. Si no, aparecen carreras y sobrecarga. Queueing conserva runs cuando no hay capacidad; omitirlo o superar límites puede producir skips.
Continuous inicia otro run al completar o fallar el anterior y aplica reintentos/backoff propios. Es adecuado para servicios siempre activos, no para un batch que espera datos. Las notificaciones se configuran para fallo, duración o atraso y deben incluir owner y contexto sin secretos.
Modelo mental
Concurrencia describe cuántos runs del mismo Job pueden estar activos; queueing decide si un run espera cuando no hay capacidad; timeouts acotan cuánto puede permanecer una tarea o run; notificaciones comunican estados relevantes. Estos controles forman una política de presión, no simples opciones. La configuración segura por defecto suele ser una ejecución concurrente para evitar que dos runs escriban el mismo periodo. Aumentarla solo es correcto si ventanas, staging, checkpoints y efectos están aislados. Cuando los triggers llegan más rápido que el procesamiento, poner todo en cola conserva trabajo pero aumenta frescura y puede crear una deuda imposible; omitir runs es aceptable únicamente si el siguiente procesa acumulativamente desde un checkpoint. Timeouts deben exceder p99 normal y activar cancelación idempotente, no matar cargas sanas durante picos. Las alertas incluyen inicio tardío, duración, fallo y pérdida de SLA, no solo estado final.
Límite configurado de ejecuciones simultáneas del mismo Job que el scheduler admite antes de aplicar espera u omisión.
Protege targets y dependencias, y solo debe crecer cuando existe aislamiento demostrable entre runs.Política que mantiene un run pendiente hasta disponer de capacidad en lugar de descartarlo inmediatamente por límites de concurrencia.
Preserva trabajo, pero transforma saturación en latencia acumulada que debe medirse contra frescura.Límite de tiempo tras el cual una tarea o ejecución se cancela y adopta un estado terminal de fallo.
Contiene bloqueos y coste, pero necesita idempotencia porque cancelar no deshace efectos externos ya confirmados.max_concurrent_runs: 1
queue:
enabled: true
timeout_seconds: 7200
email_notifications:
on_failure:
- data-platform-oncall@example.invalid
on_duration_warning_threshold_exceeded:
- data-platform-oncall@example.invalidLa dirección `.invalid` es deliberadamente ficticia; reemplázala por un destino gestionado del entorno.
Puntos clave
- Más concurrencia solo es segura con entradas y efectos aislables.
- Queueing gestiona presión del planificador; no corrige un Job más lento que la llegada indefinidamente.
- Timeout y alertas delimitan fallos colgados y protegen el SLO.
Evita
- Aumentar concurrencia para reducir cola mientras todos los runs sobrescriben la misma partición.
- Usar continuous para una fuente ociosa y pagar reinicios/compute sin mejorar frescura.
Recuerdo activo