Priorizar fluxos

1) Por que é preciso priorizar

Quando a carga aumenta, «tudo é importante» se transforma em «nada». Priorizar os fluxos é uma forma de distribuir recursos limitados (CPU, I/O, rede, orçamento) entre os fluxos/jobs/tenentes de modo que os SLO críticos sejam executados e o custo permaneça controlado. O resultado é uma frescura previsível de vitrines, alertas e janelas de contagem sustentáveis.

2) Taxonomia de fluxo e critérios de importância

• Tempo: real/near-real-time (segundos-minutos), interativo (minutos), off/batch (relógio).
• Criticidade: financeiro/regulatório, incidentes, alimentos, pesquisa.
• Dependências: fontes para outras vitrines (upstream) vs finais (downstream).
• Custo de inatividade: danos por minuto/hora de atraso (SLO breach cost).
• Comando interno, parceiro, cliente externo.

Prática: Todas as classes são Business Priority (BP) e Technical Priority (TP); resultado: prioridade composta 'P = w1BP + w2TP + w3CostRisk'.

3) Modelo SLA/SLO/SI para fluxos

SLA: garantia contratual (por exemplo, "vitrine financeira T + 15 min, 99. 9%»).
SLO: fins de engenharia (p95 frescor ≤ 10 min; p99 atraso ≤ 60 segundos).
SI (Saturation Index): relação entre o carregamento atual e os limites; usado pelo planejador.

Guardrails: métricas de guerrail (por exemplo, erros de validação, omissões) podem aumentar temporariamente a prioridade dos fluxos de reparação.

4) Classes de serviço (QoS) e políticas

Gold (business-critical): pagamentos, antifrode, relatórios regulatórios, alertas incidentes.
Silver (produt-critical): Vitrines para dashboards de orientação, campanhas, risco-escrutínio.
Bronze (best-effort): batalhas de pesquisa, longa ré-build e backfill amplas janelas.

• Stority (SP): Gold sempre à frente; o risco de morrer de fome.
• Weighted Fair Queuing (WFQ): peso sobre tráfego/jobs, controle de justiça.
• Deficit Round-Robin (DRR): quotas de processamento, bom para nós de rede/streaming.
• Deadline-aware: tarefas com deadline próximo recebem bust.
• Costa-aware: O repasse foi adiado se a «hora cara» e o SLO permitirem.

5) Planejadores e filas (em níveis)

• Os topics/filas estão divididos em classes de QoS; limites de produtores; backpressure através de quotas.
• Política de rate limit + burst tokens para picos (tocen bucket).

• Poulas de recursos/clusters por classe: executores individuais para Gold.
• Preempition: seleção de recursos para os mais baixos com deficiência (limitando a frequência).
• Controle de adesão: filtro de entrada de orçamento e SLO; Desviar «caros» jobs sem janela.

• Concorrente I/O e filas de solicitação prioritárias.
• Materializante views: Gold - Incorporativa, Silver - Periódica, Bronze - agendada/nas janelas noturnas.

6) Backpressure, limites e proteção de sistemas

Backpressure sinais: de consumidor para produtor (lag/latency/queue depth).
Limites de consulta/jobs: bytes scanned, rows returned, wall-time caps.
Circuito Breakers: Quando sobrecarregada, a degradação é até aparelhos simplificados ou snapshots «quentes».
Shed-load: largar/cortar os fluxos best-effort para salvar os críticos.

7) Multiplicidade e «justiça»

As quotas de tenentes são CPU/IO/valor por unidade de tempo.
Peso para as classes de consulta: analista, relatórios, fici ML - limites diferentes.
Budet envelopes: tetos semanais/mensais; quando esgotado, baixa a prioridade, transferência para off-peak.

8) Custo e «economia de prioridade»

Costa-to-Freshness: quanto custa 1 min de melhoria da frescura.
Custo-aware planejamento: Bronze é transferido para off-peak; backfill - no «relógio barato».
Spot/Preemptible: Para baixa prioridade - uso de recursos preemptil.
Perfilação de solicitação: lista preta de modelos «caros»; Uma reescrição automática.

9) Priorização para batch

Calendário de janelas: janelas de fix para Gold antes do Silver/Bronze.
Dependency-aware DAG: os modelos upstream Gold recebem uma slot inicial para desbloquear a cascata.
Incremental first: Primeiro, partituras incorporativas, depois ré-build «frias».
Checkpointing: para que a preempção não leve a uma perda de progresso.

10) Priorização para streaming

As partituras prioritárias são mais instâncias consumidoras em Gold Topics.
Watermarks em classes: para Gold - janelas lateness estreitas; para Bronze - mais amplo (tolerância maior para eventos atrasados).
Dedup e idempotent sinks: para Gold - rigorosos; para Bronze - Evristas.
Os Gold-Alerts seguem um canal de alta QoS.

11) Sinais e mudança automática de prioridade

Eventos desencadeadores de tráfego spike, incidente, campanha de promoção → bust temporário Gold/Silver.
SLA-Ameaça: Previsão de quebra de frescura → auto-boost de uma vitrine específica.
Data Quality: Duplas/perdas em massa → priorizar os fluxos repair.
Risco financeiro: o crescimento do chargeback → a prioridade do escrutínio/alertas.

12) Observabilidade: o que monitor

Fila/liga: comprimento, tempo de espera, p95/p99 atrasos por classe.
Tábua SLO: frescura/latência/erros por camada (ingest→curated→marts).
Custo: cut per class/tenant; desvios de orçamento.
Preempition/falhas: frequência, perda de progresso, dados MTTR.
A arritmética de prioridade é «P» atual, as causas dos bustos, o histórico de decisões do planejador.

13) Gerenciamento de políticas

Políticas em código config (policy-as-código), versionização e review.
Parafusos secos (dry-run) antes de aplicar: como mudar o horário/custo.
Inclusão Canary: parte dos clusters passa para novos pesos/regras.
Runbooks: O que fazer quando sobrecarregado, como rebaixar temporariamente a sala de aula, como recuperar.

14) Antipattern

«Tudo é Gold». A priorização perde o sentido; Há guerras por recursos.
SP rigorosa sem proteção contra fome. Silver/Bronze nunca terminam.
Não há controle de adesão. Os pedidos «caros» entram no sistema e fazem toda a gente entrar.
A falta de uma coca-aware. Fazemos backfill pesado no «relógio caro».
Mistura OLTP/OLAP. Transações críticas são prejudicadas por analistas.
Dados híbridos sem RLS/CLS. Reparação/prioridade revela acidentalmente campos sensíveis.

15) Mapa de trânsito de implementação

1. Discovery: inventário de fluxos, dependências e proprietários; estimativa de SLO e custo de inatividade.
2. Classes de QoS: definir Gold/Silver/Bronze, peso e limites básicos; Ter policia-as-código.
3. Programador e pool: separa os clusters/pool de recursos, e ative o adaptation control.
4. Monitoramento: tábuas SLO/bla/custo; alertas à ameaça de SLO e budget-breach.
5. Auto-boost: integração de sinais (incidentes, campanhas, DQ) em uma mudança de prioridade.
6. Costa-aware: agendamento off-peak, recursos spot, perfilando consultas «caras».
7. Hardening: preempition-safe checkpoint, runbooks, políticas de canários, testes de caos.

16) Folha de cheque antes do lançamento

• A classe de QoS, o proprietário, o SLO e o custo de inatividade são definidos para todos os fluxos.
• Os pulos/clusters e o controle de adesão estão configurados, os limites de CPU/IO/raias.
• Estão incluídos backpressure e rate limits em ingest/consumers.
• As políticas de priorização são formalizadas como código; há dry-run e ciúmes.
• As lagoas, o frescor, o custo, a preempção/erros são monitorados; alert em on-call.
• Configurado auto-boost por sinalização (SLA-ameaça, DQ, incidente, campanha).
• Documentados runbooks de degradação; Os cenários de caos foram testados.
• Para Bronze, os fluxos foram transferidos para off-peak/spot sem risco de atrasos em cascata.

17) Exemplos de políticas típicas (pseudo-YAML)

17. 1 Classe Gold com deadline e orçamento

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

Priorizar os fluxos é uma combinação controlada de prioridades empresariais, SLO técnico e limitações econômicas, implementada através de filas, planejadores, limites e feedback do sistema. Quando as classes de QoS, os sinais auto-boost e a política de custo-aware funcionam juntos, os dados permanecem frescos e confiáveis, os insights críticos chegam a tempo e a conta de infraestrutura é previsível.