Hiérarchisation des flux

1) Pourquoi la priorité est nécessaire

Avec l'augmentation de la charge de travail, « tout est important » se transforme en « on ne peut rien faire ». La hiérarchisation des flux est un moyen systémique de répartir les ressources limitées (CPU, I/O, réseau, budget) entre les flux/jobs/tenants afin que les SLO critiques soient exécutés et que le coût reste contrôlé. Le résultat est la fraîcheur prévisible des vitrines, des alertes irréprochables et des fenêtres de recalculage durables.

2) Taxonomie des flux et critères d'importance

• Temps : real/near-real-time (secondes-minutes), interactif (minutes), hors ligne/batch (heures).
• Criticité : finances/réglementation, incidents, produits, recherche.
• Dépendances : sources pour d'autres vitrines (upstream) vs terminales (downstream).
• Coût du temps d'arrêt : dommages par minute/heure de retard (SLO breach cost).
• Ténacité : équipe interne, partenaire, client externe.

Pratique : chaque classe est une priorité d'affaires (BP) et une priorité technique (TP) ; le résultat est la priorité composite « P = w1BP + w2TP + w3CostRisk ».

3) Modèle SLA/SLO/SI pour les flux

SLA : garantie contractuelle (ex : "vitrine financière T + 15 min, 99. 9%»).
SLO : objectifs d'ingénierie (p95 fraîcheur ≤ 10 min ; p99 retard ≤ 60 secondes).
SI (Indice de saturation) : rapport du chargement actuel aux limites ; utilisé par le planificateur.

Guardrails : les mesures de garde (par exemple, erreurs de validation, omissions) peuvent temporairement augmenter la priorité des flux de réparation.

4) Classes de service (QoS) et politiques

Gold (business-critical) : paiements, antifrod, rapports réglementaires, alertes d'incident.
Silver (product-critical) : vitrines pour dashboards de direction, campagnes, risque-scoring.
Bronze (best-effort) : batchi de recherche, long re-build et backfill fenêtres larges.

• Priorité stricte (SP) : Or toujours devant ; le risque de jeûne des plus faibles.
• Weighted Fair Queuing (WFQ) : poids sur le trafic/jobs, contrôle de l'équité.
• Deficit Round-Robin (DRR) : quotas de traitement des portions, bon pour les nœuds de réseau/streaming.
• Deadline-aware : les tâches avec une deadline proche obtiennent un but.
• Cost-aware : recalculer reporté si « cher heure » et SLO le permet.

5) Planificateurs et files d'attente (au niveau)

• Les tops/files d'attente sont divisés en classes QoS ; les limites des producteurs ; backpressure via quotas.
• Politique de rate limit + burst tokens pour les surtensions (token bucket).

• Pools de ressources/clusters par classe : exécuteurs distincts pour Gold.
• Préemption : sélection des ressources chez les plus faibles en cas de déficit (avec limitation de fréquence).
• Contrôle d'admission : filtre d'entrée par budget et SLO ; déviation des jobs « chers » sans fenêtre.

• I/O concurrentiel et files d'attente prioritaires.
• Materialized views : Gold - incrémental, Silver - périodique, Bronze - selon l'horaire/dans les fenêtres de nuit.

6) Backpressure, limites et protection des systèmes

Signaux backpressure : du consommateur au producteur (lag/latency/queue depth).
Limites de requête/jobu : bytes scanned, rows returned, wall-time caps.
Breakers Circuit : en cas de surcharge, dégradation en agrégats simplifiés ou snapshots « chauds ».
Shed-load : réinitialiser/réduire les flux best-effort pour sauver les flux critiques.

7) Multiplicité et « justice »

Quotas par tenant : CPU/IO/coût par unité de temps.
Poids par classe de requête : analyste, rapports, ML-fiches - différentes limites.
Budget envelopes : plafonds hebdomadaires/mensuels ; en cas d'épuisement - déclassement, transfert à off-peak.

8) Coût et « économie de priorité »

Cost-to-Freshness : combien coûte 1 min d'amélioration de fraîcheur.
Planification cost-aware : Bronze est transférée à off-peak ; backfill - en « heures bon marché ».
Spot/Preemptible : pour les moins prioritaires, l'utilisation des ressources preemptible.
Profilage des requêtes : listes noires de modèles « chers » ; auto-réécriture.

9) Priorité pour batch

Calendrier des fenêtres : fix-fenêtres pour Gold avant Silver/Bronze.
Dependency-aware DAG : les modèles d'or upstream obtiennent un slot précoce pour déverrouiller la cascade.
Première incrémentale : d'abord les lots incrémentaux, puis « froid » re-build.
Checkpointing : afin que la préemption n'entraîne pas de perte de progrès.

10) Priorité pour le streaming

Lots prioritaires : plus d'instances de consommation sur les tops Gold.
Watermarks par classe : Pour Gold, des fenêtres latines étroites ; pour Bronze - plus large (plus grande tolérance aux événements tardifs).
Dedup and idempotent seinks : pour Gold - rigoureux ; pour Bronze - heuristique.
Alerts : Les alerts Gold passent par un canal séparé avec QoS élevé.

11) Signaux et changement automatique de priorité

Déclencheurs d'événements : trafic de spike, incident, campagne promotionnelle, → un boost temporaire Gold/Silver.
SLA-menace : prédiction d'une rupture de fraîcheur → auto-boost d'une vitrine spécifique.
Qualité des données : prises/pertes massives → priorité accrue des flux de réparation.
Risque financier : augmentation de la charge de travail → priorité au scoring/alerts.

12) Observabilité : ce qu'il faut surveiller

Files d'attente : longueur, temps d'attente, p95/p99 retards par classe.
SLO-board : fraîcheur/latence/erreurs par couche (ingest→curated→marts).
Coût : cost par classe/tenant ; écarts par rapport au budget.
Préemption/échecs : fréquence, perte de progrès, données MTTR.
Arythmétique de la priorité : le courant « P », les causes des boosts, l'histoire des décisions du planificateur.

13) Gestion des politiques

Stratégies dans le config-code (policy-as-code), versioning et review.
Runs secs (dry-run) avant application : comment le planning/coût changera.
Canary-inclusion : une partie des grappes passe à de nouveaux poids/règles.
Runbooks : que faire en cas de surcharge, comment déclasser temporairement, comment récupérer.

14) Anti-modèles

« Tout le monde est Gold ». La priorité perd son sens ; les guerres de ressources commencent.
SP stricte sans protection contre le jeûne. Silver/Bronze ne sont jamais terminés.
Pas de contrôle d'admission. Les demandes « chères » entrent dans le système et font tomber tout le monde.
Pas de cost-aware. Nous exécutons des backfill lourds dans des « heures chères ».
Mélange OLTP/OLAP. Les transactions critiques souffrent de l'analyse.
Données hybrides sans RLS/CLS. Réparation/priorité révèle accidentellement les champs sensibles.

15) Feuille de route pour la mise en œuvre

1. Discovery : inventaire des flux, des dépendances et des propriétaires ; Estimation de SLO et coût des temps d'arrêt.
2. Classes de QoS : Définir Gold/Silver/Bronze, poids et limites de base ; créer un policy-as-code.
3. Planificateur et pools : Diviser les clusters/pools de ressources, activer le contrôle d'admission.
4. Surveillance : planches SLO/lag/coût ; alertes à la menace de SLO et budget-breach.
5. Auto-boost : intégration des signaux (incidents, campagnes, DQ) dans le changement de priorité.
6. Cost-aware : horaires off-peak, ressources spot, profilage des requêtes « chères ».
7. Hardening : préemption-safe tchekpoints, runbooks, politiques canariens, tests de chaos.

16) Chèque-liste avant la sortie

• La classe QoS, le propriétaire, le SLO et le coût d'arrêt sont définis pour tous les flux.
• Les pools/clusters et le contrôle d'admission, les limites CPU/IO/scans sont configurés.
• Inclus backpressure et rate limites sur ingest/consumers.
• Les politiques de priorité sont définies comme un code ; il y a le dry-run et la rhubarbe.
• La lagune, la fraîcheur, le coût, la préemption/les erreurs sont surveillés ; alerties dans on-call.
• Configuré auto-boost en fonction des signaux (SLA-menace, DQ, incident, campagne).
• Les runbooks de dégradation sont documentés ; les scénarios de chaos ont été testés.
• Pour Bronze, les flux ont été transférés à off-peak/spot sans risque de retards en cascade.

17) Exemples de politiques types (pseudo-YAML)

17. 1 Classe Gold avec deadline et 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) Résultat

La hiérarchisation des flux est une combinaison gérée de priorités d'affaires, de SLO techniques et de contraintes économiques, mise en œuvre par le biais des files d'attente, des planificateurs, des limites et de la rétroaction du système. Lorsque les classes QoS, les signaux auto-boost et cost-aware de la politique fonctionnent ensemble, les données restent fraîches et fiables, les insignes critiques arrivent à temps et le compte d'infrastructure est prévisible.