Priorización de flujos

1) Por qué se necesita priorizar

A medida que crece la carga, «todo es importante» se convierte en «no tenemos tiempo para nada». La priorización de subprocesos es una forma sistemática de asignar recursos limitados (CPU, I/O, red, presupuesto) entre subprocesos/jobs/tenantes para que los SLO críticos se ejecuten y el costo permanezca controlado. El resultado es la frescura previsible de las vitrinas, alertas sin problemas y ventanas de recuento sostenidas.

2) Taxonomía de los flujos y criterios de importancia

• Tiempo: real/near-real-time (segundos-minutos), interactivo (minutos), offline/batch (horas).
• Criticidad: financiera/regulatoria, incidente, producto, investigación.
• Dependencias: fuentes para otras vitrinas (upstream) vs finite (downstream).
• Costo de tiempo de inactividad: daños por minuto/hora de retraso (SLO breach cost).
• Tenencia: equipo interno, socio, cliente externo.

Práctica: cada clase es Business Priority (BP) y Technical Priority (TP); el total es la prioridad compuesta 'P = w1BP + w2TP + w3CostRisk'.

3) Modelo SLA/SLO/SI para hilos

SLA: garantía contractual (por ejemplo, "escaparate financiero T + 15 min, 99. 9%»).
SLO: objetivos de ingeniería (p95 frescura ≤ 10 min; p99 retraso ≤ 60 segundos).
SI (Índice de saturación): relación entre la descarga actual y los límites; es utilizado por el planificador.

Guardails: las métricas guardrail (por ejemplo, errores de validación, omisiones) pueden aumentar temporalmente la prioridad de los flujos de reparación.

4) Clases de servicio (QoS) y políticas

Gold (business-critical): pagos, antifraude, informes regulatorios, alertas de incidentes.
Silver (producto-crítico): escaparates para guías de dashboards, campañas, puntuación de riesgo.
Bronze (mejor effort): batches de investigación, re-build de larga duración y backfill de ventanas anchas.

• Prioridad estricta (SP): Oro siempre por delante; el riesgo de inanición de los más bajos.
• Weighted Fair Queuing (WFQ): peso en el tráfico/joba, control de la equidad.
• Definición Round-Robin (DRR): cuotas por porciones de procesamiento, bueno para nodos de red/streaming.
• Deadline-aware: los trabajos con un deadline cercano reciben un busto.
• Costo-aware: la recomposición se pospone si la «hora cara» y SLO lo permite.

5) Planificadores y colas (en niveles)

• Los topics/colas se dividen por clases de QoS; límites de productores; backpressure a través de cuotas.
• Política de rate limit + burst tokens para ráfagas (token bucket).

• Grupos de recursos/clústeres por clase: executors individuales para Gold.
• Preemption: selección de recursos de los más bajos en caso de escasez (con limitación de frecuencia).
• Control de administración: filtro de entrada por presupuesto y SLO; desviación de jobs «caros» sin ventana.

• I/O competitivo y colas de solicitudes prioritarias.
• Vistas materializadas: Oro - incremental, Plata - periódico, Bronce - en horario/en ventanas nocturnas.

6) Backpressure, límites y protección de sistemas

Señales de retroceso: del consumidor al productor (lag/latency/queue depth).
Límites de consulta/jobu: bytes scanned, rows returned, wall-time caps.
Circuit Breakers: en caso de sobrecarga - degradación a unidades simplificadas o snapshots «cálidos».
Shed-load: restablecer/cortar los flujos de mejor efecto para rescatar los críticos.

7) Multisotenencia y «justicia»

Cuotas por tenante: CPU/IO/valor por unidad de tiempo.
Pesos en las clases de consulta: análisis, informes, ML-fiches - diferentes límites.
Budget envelopes: techos semanales/mensuales; cuando se agota, baja la prioridad, se transfiere a off-peak.

8) Costo y «economía de priorización»

Costo-a-Freshness: cuánto cuesta 1 minuto mejorar la frescura.
Planificación de costo-aware: Bronze se transfiere a off-peak; backfill - en «relojes baratos».
Spot/Preemptible: para los de baja prioridad - uso de recursos preemptibles.
Perfiles de consulta: listas negras de plantillas «caras»; auto-reescritura.

9) Priorización para batch

Calendario de ventanas: ventana de fix para Gold antes de Silver/Bronze.
Dependency-aware DAG: upstream Los modelos Gold obtienen una ranura temprana para desbloquear la cascada.
Primero incremental: primero los lotes incrementales, luego los «fríos» re-build.
Checkpointing: para que la preemption no se traduzca en pérdida de progreso.

10) Priorización para streaming

Partes prioritarias: más instancias de consumo en los topics de oro.
Watermarks por clases: para Gold - ventanas lateness estrechas; para Bronze es más amplio (mayor tolerancia a eventos tardíos).
Dedup e idempotent sinks: para Gold - rigurosos; para Bronze - heurístico.
Alertas: Las alertas de oro van por un canal separado con un alto QoS.

11) Señales y cambio automático de prioridad

Desencadenantes de eventos: spike tráfico, incidente, campaña promocional → boost temporal Gold/Silver.
SLA-amenaza: pronóstico de la ruptura de la frescura → auto-boost de un escaparate específico.
Calidad de datos: tomas/pérdidas masivas → aumento de la prioridad de los flujos de reparación.
Riesgo financiero: crecimiento de chargeback → prioridad de puntuación/alertas.

12) Observabilidad: qué monitorear

Colas: longitud, tiempo de espera, p95/p99 retrasos por clase.
Tablero SLO: frescura/latencia/errores por capa (ingest→curated→marts).
Costo: costo por clase/tenant; desviaciones del presupuesto.
Preemption/fallas: frecuencia, pérdida de progreso, datos MTTR.
Arritmética de prioridad: la actual 'P', las causas de los aumentos, la historia de las decisiones del planificador.

13) Gestión de políticas

Políticas en código de configuración (policy-as-code), versioning y review.
Corridas secas (dry-run) antes de la aplicación: cómo cambiará el horario/costo.
Canary-inclusion: parte de los clústeres pasan a nuevos pesos/reglas.
Runbooks: qué hacer cuando hay sobrecarga, cómo bajar temporalmente la clase, cómo devolver.

14) Antipattern

«Todo es oro». La priorización pierde sentido; comienzan las guerras por los recursos.
Un SP estricto sin protección contra el hambre. Silver/Bronze nunca se completan.
No hay control de admisibilidad. Las solicitudes «caras» entran en el sistema y dejan caer a todos.
No hay costo-aware. Realizamos backfill pesado en «horas caras».
Mezcla OLTP/OLAP. Las transacciones críticas sufren debido a los analistas.
Datos híbridos sin RLS/CLS. La reparación/prioridad revela accidentalmente campos sensibles.

15) Hoja de ruta para la implementación

1. Discovery: inventario de flujos, dependencias y propietarios; Estimación de SLO y costo de tiempo de inactividad.
2. Clases de QoS: definir los límites de Oro/Plata/Bronce, pesos y base; Iniciar policy-as-code.
3. Planificador y grupos: separar clústeres/grupos de recursos, habilitar control de administración.
4. Monitoreo: tableros SLO/lag/costo; alertas a la amenaza de SLO y budget-breach.
5. Auto-boost: integración de señales (incidentes, campañas, DQ) en el cambio de prioridad.
6. Coste-aware: horarios fuera de línea, recursos spot, perfiles de consultas «caras».
7. Hardening: preemption-safe checkpoints, runbooks, políticos canarios, pruebas de caos.

16) Lista de verificación antes del lanzamiento

• La clase QoS, el propietario, el SLO y el costo de inactividad están definidos para todos los subprocesos.
• Grupos/clústeres configurados y control de administración, límites de CPU/IO/escáneres.
• Se incluyen backpressure y rate limits por ingest/consumers.
• Las políticas de priorización están formalizadas como código; hay dry-run y rugido.
• Monitor lags, frescura, costo, preemption/errores; alertas en on-call.
• Configurado auto-boost por señales (amenaza SLA, DQ, incidente, campaña).
• runbooks de degradación documentados; Escenarios de caos verificados.
• Para Bronze, los flujos se transfieren a off-peak/spot sin riesgo de retrasos en cascada.

17) Ejemplos de políticas modelo (pseudo-YAML)

17. 1 Clase Gold con dlline y presupuesto

yaml policy: gold_finance_stream priority_base: 90 deadline_slo: freshness<=10m boost_on:
- dq_violation: duplicates_in_txn_id>0
- incident: "chargeback_spike"
limits:
max_scan_mb: 20480 max_concurrency: 32 budget:
max_hourly_cost: 200 preemption:
can_preempt_classes: [silver, bronze]

17. 2 Cost-aware backfill для Bronze

yaml policy: bronze_backfill priority_base: 20 schedule: offpeak(22:00-06:00)
limits:
max_concurrency: 4 iops_cap: low fallback:
pause_if_cluster_si>0. 8

18) Resultado

La priorización de subprocesos es una combinación administrada de prioridades empresariales, SLO técnicos y limitaciones económicas, implementada a través de colas, planificadores, límites y retroalimentación del sistema. Cuando las clases de QoS, las señales de auto-boost y las políticas de costo-aware trabajan juntas, los datos siguen siendo frescos y confiables, los insights críticos llegan a tiempo y la cuenta de infraestructura es predecible.