Priorità dei flussi

1) Perché la priorità è necessaria

Quando il carico di lavoro aumenta, «tutto è importante» si trasforma in «niente in tempo». La priorità dei flussi è un modo per distribuire risorse limitate (CPU, I/O, rete, budget) tra i flussi/jobs/tenanti in modo che gli SLO critici siano eseguiti e che i costi restino controllati. Il risultato è la prevedibile freschezza delle vetrine, gli alerti di sicurezza e le finestre di calcolo sostenibili.

2) Tassonomia dei flussi e criteri di importanza

• Tempo: real/near-real-time (secondi-minuti), interattivo (minuti), off-line/batch (orologio).
• Criticità: finanziari/regolatori, incidenti, alimentari, ricerca.
• Dipendenze: sorgenti per altre vetrine (upstream) vs finali (downstream).
• Costo di inattività: danni per minuto/ora di ritardo (SLO breach cost).
• Team interno, partner, client esterno.

Pratica: per classe: Business Priority (BP) e Technical Priority (TP); totale - priorità composita «P = w1BP + w2TP + w3CostRisk».

3) Modello SLA/SLO/SI per i flussi

SLA: garanzia contrattuale (ad esempio, "vetrina finanziaria T + 15 min, 99. 9%»).
Obiettivi di ingegneria (p95 freschezza) 10 min; p99 ritardo di 60 secondi.
SI (Saturation Index) - Rapporto tra il caricamento corrente e i limiti; utilizzato dal pianificatore.

Guardrails: le metriche di guardia (ad esempio, errori di convalida, omissioni) possono aumentare temporaneamente la priorità dei flussi di riparazione.

4) Classi di servizio (QoS) e criteri

Gold (business-critical) - pagamenti, antifrode, rapporti regolatori, alert di incidente.
Silver (product-critical) - Vetrine per dashboard manuali, campagne, rischio-scorrimento.
Bronze (best-effort) - Battelli di ricerca, lunga re-build e backfill ampie finestre.

• Strict Priority (SP): Gold sempre davanti; il rischio di affamare i più bassi.
• Weighted Fair Queuing (WFQ): peso per traffico/jobs, controllo della giustizia.
• Deficit Round-Robin (DRR) - Le quote per le porzioni di lavorazione sono buone per i nodi di rete/streaming.
• Deadline-aware - Le operazioni con deadline ravvicinato ricevono bust.
• Cost-aware - Il ricalcolo è stato ritardato se «ora costosa» e SLO lo consente.

5) Pianificatori e code (livelli)

• I topic/code sono suddivisi in classi di QoS; Limiti dei produttori; backpressure attraverso le quote.
• Criterio rate limit + burst tokens per i picchi (token bucket).

• Pool di risorse/cluster per classe: esecutori separati per Gold.
• Preemption - Selezione delle risorse da quelle inferiori in caso di deficit (limitando la frequenza).
• Admision control: filtro di ingresso budget e SLO deviare i giubbotti «costosi» senza finestra.

• I/O competitivo e code di query prioritarie.
• Materialization views: Gold - incrementali, Silver - periodici, Bronze - orari/finestre notturne.

6) Backpressure, limiti e protezione dei sistemi

Backpressure: da consumatore a produttore (lag/latency/queue depth).
Limiti di query/jobs: bytas scanned, rows returned, wall-time caps.
Circuito Breakers - In caso di sovraccarico, degrado fino a unità semplificate o snapshot «caldi».
Shed-load - Reimposta/ritaglia i flussi best-effort per salvare i flussi critici.

7) Molteplicità e «giustizia»

Quote per tenente: CPU/IO/valore in unità di tempo.
I pesi per le classi di query sono analitici, report, fici ML - limiti diversi.
Budget encelopes: soffitti settimanali/mensili; quando esaurito, abbassamento della priorità, spostamento a off-peak.

8) Costo e «economia di priorità»

Cost-to-Freshness: quanto costa 1 minuto di miglioramento della freschezza.
Cost-aware pianificazione: Bronze viene spostata a off-peak; backfill nell'orologio low cost.
Spot/Preemptible - Per le risorse a bassa priorità, utilizzare le risorse preemptive.
Profilazione delle query: elenchi neri dei modelli «costosi» Riscrittura automatica.

9) Priorità per batch

Calendario finestre: finestre fix per Gold prima di Silver/Bronze.
Dependency-aware DAG: i modelli upstream Gold ricevono uno slot precoce per sbloccare la cascata.
Incremental first - Prima le partenze incrementali, poi le parti «fredde» re-build.
Checkpointing: in modo che la preemption non comporti una perdita di progresso.

10) Priorità per lo streaming

Le parti prioritarie sono un numero maggiore di istanze consumer per i Gold topics.
Watermarks per classe: per Gold, finestre lateness strette; Bronze è più ampia (maggiore tolleranza per gli eventi in ritardo).
Dedup e idempotent sinks: per Gold sono rigorosi; Bronze è euristica.
I Gold-Alert seguono un canale separato con un alto livello.

11) Segnali e modifica automatica della priorità

Scatenatori di eventi: spike del traffico, incidente, campagna promozionale, bust temporaneo Gold/Silver.
Rischio SLA: previsione di un crollo della freschezza dell'auto-boost di una vetrina specifica.
Data Quality - Le riprese/le perdite di massa aumentano la priorità dei flussi repair.
Il rischio finanziario è che la crescita della chargeback sia la priorità degli screening/alert.

12) Osservabilità: cosa monitor

Code/lega: lunghezza, tempo di attesa, p95/p99 ritardi di classe.
Lavagna SLO: freschezza/latitanza/errori di livello (ingest→curated→marts).
Costo: cost per classe/tenant; Deviazioni di bilancio.
Preemption/guasti: frequenza, perdita di progresso, dati MTTR.
L'aritmetica di priorità è «P» corrente, le cause dei bust, la cronologia delle soluzioni del pianificatore.

13) Gestione delle regole

Regole in codice config (policy-as-code), versioning e review.
Test secchi (dry-run) prima di applicare: come cambiare la pianificazione/il costo.
Inclusione Canary: parte dei cluster passa a nuovi pesi/regole.
Runbooks: cosa fare in caso di sovraccarico, come abbassare temporaneamente la classe, come restituirla.

14) Antipattern

«Tutti Gold». La priorità perde senso; iniziano le guerre per le risorse.
Una SP rigida senza protezione contro la fame. Silver/Bronze non si completano mai.
Nessun adattamento control. Le richieste «costose» entrano nel sistema e rovinano tutti.
Assenza di cost-aware. Eseguiamo un pesante backfill in orologi costosi.
Miscelazione OLTP/OLAP. Le transazioni critiche sono danneggiate dagli analisti.
Dati ibridi senza RLS/CLS. Riparazione/priorità mostra casualmente i campi sensibili.

15) Road map di implementazione

1. Inventario dei flussi, delle dipendenze e dei proprietari stima del SLO e dei costi di inattività.
2. Classi di QoS: definire Gold/Silver/Bronze, pesi e limiti di base; attivare policy-as-code.
3. Pianificatore e pool: separa cluster/pool di risorse, abilita admision control.
4. Monitoraggio: tavole SLO/lega/costo; alert per la minaccia di SLO e budget-breach.
5. Auto-boost - Integra i segnali (incidenti, campagne, DQ) per cambiare la priorità.
6. Cost-aware - Pianificazione off-peak, risorse spot, profilassi di query «costose».
7. Hardening: preemption-safe checkpoint, runbooks, politiche canarie, test di caos.

16) Foglio di assegno prima del lancio

• Per tutti i flussi è stata definita la classe QoS, il proprietario, il SLO e il costo di inattività.
• Sono stati configurati pool/cluster e adattamento control, limiti CPU/IO/scene.
• Sono inclusi backpressure e rate limits su ingest/consumatori.
• I criteri di priorità sono formati come codice; mangiare dry-run e gelosia.
• Monitor di laghe, freschezza, costo, preemption/errori; alert in on-call.
• Configurato auto-boost tramite segnale (SLA-minaccia, DQ, incidente, campagna).
• Documentato il degrado runbooks; Script di caos testati.
• Per Bronze i flussi sono stati spostati su off-peak/spot senza il rischio di ritardi a cascata.

17) Esempi di regole tipiche (pseudo-YAML)

17. 1 Classe Gold con deadline e budget

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) Totale

La priorità dei flussi è una combinazione gestita di priorità aziendali, SLO tecnici e vincoli economici, implementata attraverso code, pianificatori, limiti e feedback del sistema. Quando le classi QoS, i segnali auto-boost e le politiche cost-aware funzionano insieme, i dati rimangono freschi e affidabili, le insight critiche arrivano in tempo e il conto delle infrastrutture è prevedibile.