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

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 політика працюють разом, дані залишаються свіжими і надійними, критичні інсайти приходять вчасно, а інфраструктурний рахунок - передбачуваним.