Quand plusieurs requêtes se disputent la même réservation, BigQuery utilise l’ordonnancement équitable pour distribuer les slots de manière équilibrée. L’algorithme de distribution a des conséquences directes sur les performances des requêtes et doit orienter les décisions d’architecture de projets.
L’algorithme à deux niveaux
L’ordonnancement équitable fonctionne en deux étapes :
- Diviser les slots équitablement entre les projets exécutant des jobs dans la réservation
- Diviser la part de chaque projet entre ses jobs
C’est là le point essentiel : la première division se fait par projet, pas par nombre de requêtes.
Pourquoi cela compte : un exemple
Considérons une réservation avec 1 000 slots :
- Projet A exécute 1 requête complexe
- Projet B exécute 20 requêtes simples
Comment les slots sont-ils distribués ?
| Projet A | Projet B | |
|---|---|---|
| Slots alloués | 500 | 500 |
| Requêtes | 1 | 20 |
| Slots par requête | 500 | 25 |
La requête unique du Projet A obtient 500 slots. Les 20 requêtes du Projet B partagent 500 slots (25 chacune).
C’est contre-intuitif. On pourrait s’attendre à ce que les 21 requêtes partagent 1 000 slots proportionnellement (environ 48 chacune). Au lieu de cela, BigQuery attribue d’abord une part égale à chaque projet, puis distribue au sein de chaque projet. La requête unique du Projet A obtient 20 fois plus de slots que chaque requête du Projet B.
Implications pour l’architecture de projets
L’architecture de projets est importante pour les performances, pas seulement pour la facturation et la sécurité.
L’ordonnancement équitable divise d’abord par projet. Si dbt et une requête d’analyste se trouvent dans le même projet, toutes les requêtes partagent équitablement l’allocation du projet. Si elles se trouvent dans des projets différents, chaque projet obtient la moitié de la réservation, quel que soit le nombre de requêtes exécutées par chacun.
C’est pourquoi le pattern multi-projets est important au-delà de la simple isolation de facturation. Des projets séparés affectés à différentes réservations garantissent une isolation complète. Mais même des projets séparés affectés à la même réservation bénéficient de la protection de l’ordonnancement équitable — chaque projet obtient une part égale.
La règle de conception pratique : regroupez les charges de travail de priorité similaire dans le même projet, et séparez les charges de priorité différente dans des projets distincts (et idéalement, des réservations différentes). Le dbt de production dans un projet, les tableaux de bord BI dans un autre, le développement dans un troisième. Chacun obtient sa part équitable.
Le problème de l’analyste ad hoc
Un pattern courant dans les équipes data en croissance :
- L’équipe commence avec un seul projet pour tout
- Le dbt de production fonctionne bien avec 8 threads
- L’équipe grandit, plus d’analystes exécutent des requêtes ad hoc
- Les exécutions dbt ralentissent pendant les heures de bureau
L’ordonnancement équitable divise la réservation équitablement entre les projets. Avec un seul projet, toutes les requêtes (dbt + analystes) partagent équitablement. À mesure que le volume de requêtes des analystes augmente, l’allocation effective de slots de dbt diminue. La solution consiste à séparer les charges de travail dans différents projets avec des affectations de réservation appropriées, pas à ajouter des slots.
L’ordonnancement équitable au sein d’un projet
Au sein de l’allocation d’un seul projet, BigQuery distribue les slots équitablement entre les jobs concurrents. Si le Projet A dispose de 500 slots et exécute 5 requêtes simultanées, chacune obtient 100 slots.
Cela signifie que le paramètre threads de dbt affecte directement l’allocation de slots par modèle. Avec 500 slots et threads: 8, chaque modèle obtient environ 62 slots. Avec threads: 4, chacun obtient environ 125 slots. Plus de threads signifie plus de parallélisme mais moins de compute par modèle. Pour les modèles complexes qui bénéficient d’un fort parallélisme (scans importants, agrégations lourdes), moins de threads avec plus de slots par modèle peut en réalité être plus rapide.
Le bon paramètre threads dépend de la taille de la réservation et de la complexité des modèles. La surveillance de l’utilisation des slots par modèle aide à identifier la valeur optimale.
Priorité en cas de contention régionale
Lorsqu’une région entière est sous pression de capacité (rare, mais possible lors de pannes majeures ou d’une demande extrême), BigQuery applique une hiérarchie de priorité différente qui s’applique au-dessus de l’ordonnancement équitable :
- Slots de base/engagés Enterprise Plus et Enterprise
- Slots autoscalés Enterprise Plus
- Slots autoscalés Enterprise
- Edition Standard et tarification à la demande
Cette priorité n’est pertinente que lors de contraintes de capacité régionales. En fonctionnement normal, l’ordonnancement équitable gère la distribution au sein de chaque réservation. Mais lorsque la région elle-même manque de capacité, les slots de base Enterprise Plus et Enterprise sont prioritaires sur Standard et la tarification à la demande.
Les utilisateurs de Standard Edition et de la tarification à la demande sont affectés en premier lors de contraintes de capacité régionales. Enterprise avec des slots de base offre un accès prioritaire lors de tels événements.