Приоритизация потоков

1) Зачем нужна приоритизация

При росте нагрузки «все важно» превращается в «ничего не успеваем». Приоритизация потоков — это системный способ распределять ограниченные ресурсы (CPU, I/O, сеть, бюджет) между потоками/джобами/тенантами так, чтобы критичные SLO выполнялись, а стоимость оставалась контролируемой. Результат — предсказуемая свежесть витрин, безотказные алерты и устойчивые окна пересчетов.

2) Таксономия потоков и критерии важности

• Время: real/near-real-time (секунды-минуты), интерактивные (минуты), оффлайн/batch (часы).
• Критичность: финансовые/регуляторные, инцидентные, продуктовые, исследовательские.
• Зависимости: источники для других витрин (upstream) vs конечные (downstream).
• Стоимость простоя: ущерб за минуту/час задержки (SLO breach cost).
• Тенантность: внутренняя команда, партнер, внешний клиент.

Практика: каждому классу — Business Priority (BP) и Technical Priority (TP); итог — композитный приоритет `P = w1BP + w2TP + w3CostRisk`.

3) Модель SLA/SLO/SI для потоков

SLA: договорная гарантия (например, «финансовая витрина T+15 мин, 99.9%»).
SLO: инженерные цели (p95 свежесть ≤ 10 мин; p99 задержка ≤ 60 сек).
SI (Saturation Index): отношение текущей загрузки к лимитам; используется планировщиком.

Гвардrails: guardrail-метрики (например, ошибки валидации, пропуски) могут временно повышать приоритет ремонтных потоков.

4) Классы обслуживания (QoS) и политики

Gold (business-critical): платежи, антифрод, регуляторные отчеты, инцидентные алерты.
Silver (product-critical): витрины для дашбордов руководства, кампаний, риск-скоринг.
Bronze (best-effort): исследовательские батчи, длительные re-build и backfill широких окон.

• Strict Priority (SP): Gold всегда впереди; риск голодания низших.
• Weighted Fair Queuing (WFQ): веса на трафик/джобы, контроль справедливости.
• Deficit Round-Robin (DRR): квоты на порции обработки, хорош для сетевых/стриминг-узлов.
• Deadline-aware: задания с близким дедлайном получают буст.
• Cost-aware: перерасчет отложен, если “дорогой час” и SLO позволяет.

5) Планировщики и очереди (на уровнях)

• Топики/очереди разбиты по классам QoS; лимиты продюсеров; backpressure через квоты.
• Политика rate limit + burst tokens для всплесков (token bucket).

• Пулы ресурсов/кластеры по классам: отдельные executors для Gold.
• Preemption: отбор ресурсов у низших при дефиците (с ограничением частоты).
• Admission control: входной фильтр по бюджету и SLO; отклонение «дорогих» джобов без окна.

• Конкурентный I/O и приоритетные очереди запросов.
• Materialized views: Gold — инкрементальные, Silver — периодические, Bronze — по расписанию/в ночные окна.

6) Backpressure, лимиты и защита систем

Backpressure сигналами: от потребителя к продюсеру (lag/latency/queue depth).
Лимиты на запрос/джобу: bytes scanned, rows returned, wall-time caps.
Circuit Breakers: при перегрузе — деградация до упрощенных агрегатов или «теплых» снапшотов.
Shed-load: сброс/урезание best-effort потоков для спасения критичных.

7) Многотенантность и «справедливость»

Квоты по тенантам: CPU/IO/стоимость в единицу времени.
Веса на классы запросов: аналитика, отчеты, ML-фичи — разные лимиты.
Budget envelopes: недельные/месячные потолки; при исчерпании — понижение приоритета, перенос на off-peak.

8) Стоимость и «экономика приоритизации»

Cost-to-Freshness: сколько стоит 1 мин улучшения свежести.
Cost-aware планирование: Bronze переносится на off-peak; backfill — в «дешевые часы».
Spot/Preemptible: для низкоприоритетных — использование preemptible-ресурсов.
Профилирование запросов: черные списки «дорогих» шаблонов; авто-переписывание.

9) Приоритизация для batch

Календарь окон: фикс-окна для Gold перед Silver/Bronze.
Dependency-aware DAG: upstream Gold-модели получают ранний слот, чтобы разблокировать каскад.
Incremental first: сначала инкрементальные партиции, затем «холодные» re-build.
Checkpointing: чтобы preemption не приводил к потере прогресса.

10) Приоритизация для стриминга

Приоритетные партиции: больше consumer-инстансов на Gold-топики.
Watermarks по классам: для Gold — узкие lateness-окна; для Bronze — шире (выше толерантность к опоздавшим событиям).
Dedup и idempotent sinks: для Gold — строгие; для Bronze — эвристические.
Алерты: Gold-алерты идут по отдельному каналу с повышенным QoS.

11) Сигналы и автоматическое изменение приоритета

Событийные триггеры: spike трафика, инцидент, промо-кампания → временный буст Gold/Silver.
SLA-угроза: прогноз срыва свежести → auto-boost конкретной витрины.
Data Quality: массовые дубли/потери → повышение приоритета repair-потоков.
Финансовый риск: рост chargeback → приоритет скоринга/алертов.

12) Наблюдаемость: что мониторить

Очереди/лаг: длина, время ожидания, p95/p99 задержки по классам.
SLO-доска: свежесть/латентность/ошибки на слой (ingest→curated→marts).
Стоимость: cost per class/tenant; отклонения от бюджета.
Preemption/отказы: частота, потеря прогресса, MTTR данных.
Аритметика приоритета: текущий `P`, причины бустов, история решений планировщика.

13) Управление политиками

Политики в конфиг-коде (policy-as-code), версионирование и review.
Сухие прогоны (dry-run) перед применением: как изменится расписание/стоимость.
Canary-включение: часть кластеров переходит на новые веса/правила.
Runbooks: что делать при перегрузе, как временно понизить класс, как вернуть.

14) Антипаттерны

«Все — Gold». Приоритизация теряет смысл; начинаются войны за ресурсы.
Строгий SP без защиты от голодания. Silver/Bronze никогда не завершаются.
Нет admission control. В систему заходят «дорогие» запросы и роняют всех.
Отсутствие cost-aware. Выполняем тяжелые backfill в «дорогие часы».
Смешение OLTP/OLAP. Критичные транзакции страдают из-за аналитики.
Гибридные данные без RLS/CLS. Ремонт/приоритет случайно раскрывает чувствительные поля.

15) Дорожная карта внедрения

1. Discovery: инвентаризация потоков, зависимостей и владельцев; оценка SLO и стоимости простоя.
2. Классы QoS: определить Gold/Silver/Bronze, веса и базовые лимиты; завести policy-as-code.
3. Планировщик и пулы: разделить кластеры/пулы ресурсов, включить admission control.
4. Мониторинг: доски SLO/лаг/стоимость; алерты на угрозу SLO и budget-breach.
5. Auto-boost: интеграция сигналов (инциденты, кампании, DQ) в изменение приоритета.
6. Cost-aware: расписания off-peak, spot-ресурсы, профилирование «дорогих» запросов.
7. Hardening: preemption-safe чекпоинты, runbooks, канареечные политики, тесты хаоса.

16) Чек-лист перед релизом

• Для всех потоков определены класс QoS, владелец, SLO и стоимость простоя.
• Настроены пулы/кластеры и admission control, лимиты CPU/IO/сканов.
• Включены backpressure и rate limits на ингест/консумеров.
• Политики приоритизации оформлены как код; есть dry-run и ревью.
• Мониторятся лаги, свежесть, стоимость, preemption/ошибки; алерты в on-call.
• Настроен auto-boost по сигналам (SLA-угроза, DQ, инцидент, кампания).
• Документированы runbooks деградации; проверены хаос-сценарии.
• Для Bronze потоки перенесены на off-peak/spot без риска каскадных задержек.

17) Примеры типовых политик (псевдо-YAML)

17.1 Класс Gold с дедлайном и бюджетом

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) Итог

Приоритизация потоков — это управляемая комбинация бизнес-приоритетов, технических SLO и экономических ограничений, реализованная через очереди, планировщики, лимиты и обратную связь системы. Когда классы QoS, сигналы auto-boost и cost-aware политика работают вместе, данные остаются свежими и надежными, критичные инсайты приходят вовремя, а инфраструктурный счет — предсказуемым.