Comprendre les emplacements
Un emplacement BigQuery est une unité de calcul virtuelle utilisée par BigQuery pour exécuter des requêtes SQL, du code Python ou d'autres types de tâches. Lors de l'exécution d'une requête, BigQuery détermine automatiquement le nombre d'emplacements utilisés par la requête. Le nombre d'emplacements utilisés dépend de la quantité de données traitées, de la complexité de la requête et du nombre d'emplacements disponibles. En général, l'accès à davantage d'emplacements vous permet d'exécuter plus de requêtes simultanées, et vos requêtes complexes peuvent s'exécuter plus rapidement.
Bien que toutes les requêtes utilisent des emplacements, vous avez le choix entre deux options de facturation pour l'utilisation : le modèle de tarification à la demande ou le modèle de tarification basé sur la capacité.
Par défaut, vous êtes facturé selon le modèle à la demande. Avec ce modèle, la quantité de données traitées (mesurée en TiB) par chaque requête vous est facturée. Les projets utilisant le modèle à la demande sont soumis à des limites d'emplacements par projet et par organisation avec une capacité d'utilisation intensive temporaire. La plupart des utilisateurs du modèle à la demande trouvent que les limites de capacité des emplacements sont amplement suffisantes. Toutefois, en fonction de votre charge de travail, l'accès à un plus grand nombre d'emplacements peut améliorer les performances des requêtes. Pour vérifier le nombre d'emplacements utilisés par votre compte, consultez Surveiller l'état, l'utilisation des ressources et les jobs.
Avec le modèle basé sur la capacité, vous payez la capacité d'emplacements allouée à vos requêtes au fil du temps. Ce modèle vous permet de contrôler explicitement la capacité totale des emplacements. Vous choisissez explicitement le nombre d'emplacements à utiliser via une réservation. Vous pouvez spécifier le nombre d'emplacements dans une réservation comme un montant de référence qui est toujours alloué, ou comme un montant avec autoscaling, qui est alloué en cas de besoin. Les réservations avec emplacements Autoscaling adaptent leur capacité en fonction de vos demandes de charge de travail. BigQuery alloue des emplacements en fonction de l'évolution des charges de travail. Les réservations avec emplacements d'autoscaling ne sont disponibles qu'avec les éditions BigQuery. Cela vous permet de configurer le nombre d'emplacements dans une réservation en fonction des performances ou du caractère critique de la charge de travail qui utilise la réservation.
Exécuter des requêtes à l'aide d'emplacements
Lorsque BigQuery exécute une tâche de requête, il convertit l'instruction SQL en un plan d'exécution, composé d'une série de phases de requête. Les étapes sont elles-mêmes composées d'ensembles d'étapes d'exécution. BigQuery utilise une architecture parallèle distribuée pour exécuter les requêtes. Les étapes modélisent les unités de travail pouvant être exécutées en parallèle. Les données sont transmises entre les étapes à l'aide d'une architecture de brassage distribuée, qui est présentée en détail dans cet article de blogGoogle Cloud .
L'exécution des requêtes BigQuery est dynamique. Un plan de requête peut être modifié pendant le traitement de la requête. La distribution du travail peut être optimisée pour la distribution des données à mesure que des étapes sont ajoutées. De plus, la capacité d'exécution d'une requête peut changer lorsque d'autres requêtes démarrent ou se terminent, ou lorsque l'autoscaler ajoute des emplacements à une réservation.
BigQuery peut exécuter plusieurs phases simultanément, exploiter l'exécution spéculative pour accélérer une requête et repartitionner dynamiquement une phase pour obtenir une parallélisation optimale.
Économie des ressources d'emplacements
Si une requête demande plus d'emplacements que ce qui est disponible, BigQuery place en file d'attente des unités de travail individuelles et attend que des emplacements soient disponibles. Au fur et à mesure de l'exécution de la requête et de la libération des emplacements, ces unités de travail mises en file d'attente sont sélectionnées de manière dynamique.
BigQuery peut demander autant d'emplacements qu'il le souhaite pour une phase donnée d'une requête. Le nombre d'emplacements demandés n'est pas lié au volume de capacité achetée, mais indique plutôt le facteur de parallélisation optimal choisi par BigQuery pour cette phase. Les unités de travail sont placées en file d'attente et sont exécutées dès que des emplacements sont disponibles.
Lorsque vos besoins en requêtes dépassent le nombre d'emplacements que vous avez souscrit, aucun emplacement ni aucuns frais supplémentaires ne vous sont facturés. Vos unités de travail individuelles sont placées en file d'attente.
Par exemple :
- Une phase de requête nécessite 2 000 emplacements, mais seulement 1 000 emplacements sont disponibles.
- BigQuery utilise ces 1 000 emplacements et place les 1 000 autres en file d'attente.
- Par la suite, si 100 emplacements se libèrent, ils récupèrent de façon dynamique 100 unités de travail parmi les 1 000 unités de travail en attente. Il reste donc 900 unités de travail en attente.
- Par la suite, si 500 emplacements se libèrent, ils récupèrent de façon dynamique 500 unités de travail parmi les 900 unités de travail en attente. Il reste donc 400 unités de travail en attente.
Si la charge de travail nécessite plus d'emplacements que ceux disponibles pour la réservation, la durée d'exécution du job peut augmenter, car les jobs attendent que des emplacements soient disponibles. C'est ce qu'on appelle la contention de créneaux. La contention d'emplacements peut augmenter si la demande de charge de travail est beaucoup plus importante que les emplacements disponibles pour la réservation.
Planification équitable dans BigQuery
BigQuery alloue la capacité d'emplacements dans une seule réservation à l'aide d'un algorithme appelé planification équitable.
Le programmeur BigQuery applique un partage équitable des emplacements entre les projets avec des requêtes en cours d'exécution au sein d'une réservation, puis entre les tâches d'un projet donné. Le programmeur assure une équité à terme. Pendant de courtes périodes, certaines tâches peuvent obtenir une part disproportionnée des emplacements, mais le planificateur finit par corriger cette inégalité. L'objectif du programmeur est de trouver un équilibre entre l'éviction agressive des tâches en cours (ce qui entraîne un gaspillage du temps d'utilisation des emplacements) et une attitude trop indulgente (où les tâches de longue durée obtiennent une part disproportionnée de la durée de l'utilisation de l'emplacement).
La planification équitable garantit que chaque requête a accès à tous les emplacements disponibles à tout moment, et que la capacité est réaffectée de manière dynamique et automatique aux requêtes actives, au fil de l'évolution de leurs besoins. Les requêtes s'exécutent, et les nouvelles requêtes sont soumises pour exécution dans les conditions suivantes :
- Lorsqu'une nouvelle requête est soumise, la capacité est automatiquement réaffectée aux requêtes en cours d'exécution. Les unités de travail individuelles peuvent être mises en pause, réactivées et placées en file d'attente de manière optimale en fonction des capacités disponibles pour chaque requête.
- Lorsqu'une requête se termine, la capacité consommée par cette requête peut immédiatement être utilisée par toutes les autres.
- Chaque fois que les besoins d'une requête changent en raison des modifications apportées au DAG dynamique de celle-ci, BigQuery réévalue automatiquement la disponibilité en capacité pour cette requête et pour toutes les autres, et réaffecte ou met en pause les emplacements si nécessaire
En fonction de sa complexité et de sa taille, une requête peut ne pas utiliser tous les emplacements auxquels elle a droit. Elle peut aussi devoir en utiliser plus. Grâce à un fonctionnement dynamique et à la planification équitable, BigQuery permet une utilisation complète de tous les emplacements à tout moment.
Si une tâche importante a toujours besoin d'un nombre d'emplacements supérieur à celui qu'elle reçoit du planificateur, envisagez de créer une réservation supplémentaire avec le nombre d'emplacements requis et d'attribuer la tâche à cette réservation.
Par exemple, supposons que vous ayez la configuration de réservation suivante :
- Réservation
A, qui comporte 1 000 emplacements de référence sans autoscaling - Projet
Aet projetB, qui sont attribués à votre réservation
Scénario 1 : Dans le projet A, vous exécutez la requête A (une requête simultanée) qui nécessite une utilisation élevée des emplacements, et dans le projet B, vous exécutez 20 requêtes simultanées. Même si 21 requêtes au total utilisent la réservation A, la répartition des emplacements est la suivante :
- Le projet
Areçoit 500 emplacements et la requêteAs'exécute avec 500 emplacements. - Le projet
Breçoit 500 emplacements qui sont partagés entre ses 20 requêtes.
Scénario 2 : Dans le projet A, vous exécutez la requête A (une requête simultanée) qui nécessite 100 emplacements pour s'exécuter, et dans le projet B, vous exécutez 20 requêtes simultanées.
Étant donné que la requête A ne nécessite pas 50 % de la réservation, la distribution des emplacements est la suivante :
- Le projet
Areçoit 100 emplacements, et la requêteAs'exécute avec 100 emplacements. - Le projet
Breçoit 900 emplacements qui sont partagés entre ses 20 requêtes.
Inversement, examinons la configuration de réservation suivante :
- Réservation
B, qui compte 1 000 emplacements de référence sans autoscaling. - 10 projets, tous attribués à la réservation
B.
Supposons que les 10 projets exécutent des requêtes qui ont une demande d'emplacements suffisante. Chaque projet reçoit alors 1/10 des emplacements de réservation totaux (soit 100 emplacements), quel que soit le nombre de requêtes exécutées sur chaque projet.
Quotas et limites des emplacements
Les quotas et limites d'emplacements fournissent une protection pour BigQuery. Différents modèles de tarification utilisent différents types de quotas d'emplacements, comme suit :
Modèle de tarification à la demande : vous êtes soumis à une limite d'emplacements par projet et par organisation avec une capacité d'utilisation intensive temporaire. En fonction de vos charges de travail, l'accès à un plus grand nombre d'emplacements peut améliorer les performances des requêtes.
Modèle de tarification basé sur la capacité : les quotas et limites de réservation définissent le nombre maximal d'emplacements que vous pouvez allouer à toutes les réservations dans un même emplacement géographique. Si vous utilisez l'autoscaling, la somme de vos tailles de réservation maximales ne peut pas dépasser cette limite. Vous ne payez que pour vos réservations et vos engagements, pas pour les quotas. Pour savoir comment augmenter votre quota d'emplacements, consultez la page Demander une augmentation de quota.
Pour vérifier le nombre d'emplacements que vous utilisez, consultez Surveiller BigQuery.
Emplacements inactifs
Certains emplacements peuvent être inactifs à n'importe quel moment. Cela peut inclure :
- Les engagements d'emplacements qui ne sont alloués à aucune référence de réservation.
- Les emplacements qui sont alloués à une référence de réservation, mais qui ne sont pas utilisés.
Les emplacements inactifs ne s'appliquent pas lorsque vous utilisez le modèle de tarification à la demande.
Par défaut, les requêtes exécutées dans une réservation utilisent automatiquement les emplacements inactifs des autres réservations de la même région et du même projet d'administration. BigQuery alloue immédiatement les emplacements inactifs à une réservation attribuée lorsqu'ils sont nécessaires. Les emplacements inactifs utilisés par une autre réservation sont rapidement préemptés si la réservation d'origine l'exige. Il est possible que la consommation totale d'emplacements dépasse brièvement le nombre maximal que vous avez spécifié pour toutes les réservations, mais vous ne serez pas facturé pour cette utilisation supplémentaire d'emplacements.
Par exemple, supposons que vous ayez la configuration de réservation suivante :
project_aest attribué àreservation_a, qui compte 500 emplacements de référence sans autoscaling.project_best attribué àreservation_b, qui comporte 100 emplacements de référence sans autoscaling.- Les deux réservations se trouvent dans la même région et le même projet d'administration, et aucun autre projet n'est attribué à ces réservations.
Vous exécutez query_b dans project_b. Si aucune requête n'est en cours d'exécution dans project_a, query_b a accès aux 500 emplacements inactifs depuis reservation_a. Tant que query_b est en cours d'exécution, il peut utiliser jusqu'à 600 emplacements : 100 emplacements de référence et 500 emplacements inactifs.
Supposons que vous exécutiez query_a dans project_a, qui peut utiliser 500 emplacements, alors que query_b est en cours d'exécution.
- Étant donné que 500 emplacements de référence sont réservés pour
project_a,query_adémarre immédiatement et se voit allouer 500 emplacements. - Le nombre d'emplacements alloués à
query_bdiminue rapidement à 100 emplacements de référence. - Les requêtes supplémentaires exécutées dans
project_bpartagent ces 100 emplacements. Si les requêtes suivantes ne disposent pas de suffisamment d'emplacements pour démarrer, elles sont mises en file d'attente jusqu'à ce que les requêtes en cours d'exécution se terminent et que des emplacements se libèrent.
Dans cet exemple, si project_b a été attribué à une réservation sans emplacements de référence ni autoscaling, query_b n'aura aucun emplacement après le démarrage de query_a. BigQuery mettrait en pause query_b jusqu'à ce que des emplacements inactifs soient disponibles ou que la requête expire. Les requêtes supplémentaires dans project_b seraient mises en file d'attente jusqu'à ce que des emplacements inactifs soient disponibles.
Pour vous assurer qu'une réservation n'utilise que ses emplacements provisionnés, définissez ignore_idle_slots sur true. Les réservations où ignore_idle_slots est défini sur true peuvent toutefois partager leurs emplacements inactifs avec d'autres réservations.
Vous ne pouvez pas partager des emplacements inactifs entre des réservations d'éditions différentes. Vous ne pouvez partager que les emplacements de référence ou les emplacements validés. Les emplacements avec autoscaling peuvent être temporairement disponibles, mais ne peuvent pas être partagés en tant qu'emplacements inactifs pour d'autres réservations, car ils peuvent être réduits.
Tant que ignore_idle_slots est défini sur "false", une réservation peut avoir un nombre d'emplacements de 0 et avoir toujours accès aux emplacements inutilisés. Si vous utilisez uniquement la réservation default, il est recommandé de désactiver ignore_idle_slots. Vous pouvez ensuite attribuer un projet ou un dossier à cette réservation, qui n'utilisera que des emplacements inactifs.
Les attributions de type ML_EXTERNAL font exception à la règle, car les emplacements utilisés par les tâches de création de modèles externes BigQuery ML ne sont pas préemptifs. Les emplacements d'une réservation avec les types d'attribution ML_EXTERNAL et QUERY ne sont disponibles que pour les autres tâches de requête lorsque ceux-ci ne sont pas occupés par les tâches ML_EXTERNAL. De plus, ces tâches ne peuvent pas utiliser les emplacements inactifs associés à d'autres réservations.
Équité basée sur les réservations
Avec l'équité basée sur les réservations, BigQuery priorise et alloue les emplacements inactifs de manière égale à toutes les réservations d'un même projet d'administration, quel que soit le nombre de projets exécutant des jobs dans chaque réservation. Chaque réservation reçoit une part similaire de la capacité disponible dans le pool d'emplacements inactifs, puis ses emplacements sont répartis équitablement entre ses projets. Cette fonctionnalité n'est disponible qu'avec les éditions Enterprise ou Enterprise Plus.
Le graphique suivant montre la répartition des emplacements inactifs sans que l'équité basée sur les réservations soit activée :
Dans ce graphique, les emplacements inactifs sont partagés équitablement entre les projets.
Si l'équité basée sur les réservations n'est pas activée, les emplacements inactifs disponibles sont répartis de manière égale entre les projets des réservations.
Le graphique suivant montre comment les emplacements inactifs sont répartis lorsque l'équité basée sur les réservations est activée :
Dans ce graphique, les emplacements inactifs sont partagés équitablement entre les réservations, et non entre les projets.
Lorsque l'équité basée sur les réservations est activée, les emplacements inactifs disponibles sont répartis de manière égale entre les réservations.
Lorsque vous activez l'équité basée sur les réservations, examinez votre consommation de ressources pour gérer la disponibilité des emplacements et les performances des requêtes.
Évitez de vous appuyer uniquement sur les emplacements inactifs pour les charges de travail de production avec des exigences de temps strictes. Ces jobs doivent utiliser des emplacements de référence ou à autoscaling. Nous vous recommandons d'utiliser des emplacements inactifs pour les tâches de priorité inférieure, car les emplacements peuvent être préemptés à tout moment.
Utilisation excessive des emplacements
Lorsqu'un job conserve des emplacements trop longtemps, il peut recevoir une part injuste de ces emplacements. Pour éviter les retards, BigQuery permet à d'autres jobs d'emprunter des emplacements supplémentaires, ce qui entraîne des périodes d'utilisation totale des emplacements supérieures à la capacité que vous avez spécifiée. Toute utilisation excessive des emplacements n'est attribuée qu'aux jobs qui reçoivent plus que leur part équitable.
Les emplacements excédentaires ne vous sont pas facturés directement. Au lieu de cela, les jobs continuent de s'exécuter et d'accumuler l'utilisation des emplacements de façon inéquitable jusqu'à ce que toute leur utilisation excédentaire soit couverte par votre capacité allouée. Les emplacements excédentaires sont exclus de l'utilisation des emplacements signalée, à l'exception de certaines statistiques d'exécution détaillées.
Notez que certains emprunts d'emplacements préemptifs peuvent se produire pour réduire les retards futurs et offrir d'autres avantages, tels que la réduction de la variabilité des coûts d'emplacements et de la latence de queue. L'emprunt de créneaux est limité à une petite fraction de votre capacité totale de créneaux.