Comprendre les emplacements

Un emplacement BigQuery est une unité de calcul virtuelle utilisée par BigQuery pour exécuter des requêtes SQL ou d'autres types de jobs. 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 : 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 la page Surveiller BigQuery.

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 confère un contrôle explicite sur la capacité totale des emplacements, contrairement au modèle à la demande. 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 nombre de référence, qui est toujours alloué, ou comme un nombre avec autoscaling, qui est alloué en cas de besoin.

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 divisé en une série de phases de requête. Ces dernières sont composées d'ensembles d'étapes d'exécution plus précis. BigQuery exploite une architecture parallèle fortement distribuée pour exécuter ces requêtes, et les phases modélisent les unités de travail que de nombreux nœuds de calcul potentiels peuvent exécuter en parallèle. Les données sont transmises entre les étapes à l'aide d'une architecture de brassage distribuée rapide qui est présentée en détail sur le blogTrusted Cloud by S3NS .

L'exécution d'une requête BigQuery est dynamique, ce qui signifie que le plan de requête peut être modifié lorsqu'une requête est en cours d'exécution. Les phases introduites lors de l'exécution d'une requête permettent souvent d'améliorer la distribution des données entre les nœuds de calcul qui traitent la requête. De plus, l'exécution des requêtes peut être affectée par la variation de la capacité disponible à mesure que d'autres requêtes se terminent ou commencent à s'exécuter, ou que des emplacements sont ajoutés à la réservation par l'autoscaler.

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.

Les emplacements BigQuery exécutent des unités de travail individuelles à chaque phase de la requête. Par exemple, si BigQuery détermine que le facteur de parallélisation optimal d'une phase est de 10, il demande 10 emplacements pour traiter cette phase.

Graphique d'exécution des étapes et des opérations d'une requête

É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 :

1. Une phase de requête nécessite 2 000 emplacements, mais seulement 1 000 emplacements sont disponibles.
2. BigQuery utilise ces 1 000 emplacements et place les 1 000 autres en file d'attente.
3. 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.
4. 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.

Emplacements BigQuery placés en file d'attente si les besoins dépassent le nombre disponible

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

Planification équitable dans BigQuery

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 programmeur, 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 A et projet B, 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 A reçoit 500 emplacements et la requête A s'exécute avec 500 emplacements.
• Le projet B reç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 A reçoit 100 emplacements, et la requête A s'exécute avec 100 emplacements.
• Le projet B reçoit 900 emplacements partagés entre ses 20 requêtes.

Inversement, examinons la configuration de réservation suivante :

• Réservation B, qui comporte 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 nécessitent suffisamment d'emplacements. 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. 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 du même projet d'administration. BigQuery alloue immédiatement des emplacements à 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. 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_a est attribué à reservation_a, qui compte 500 emplacements de référence sans autoscaling.
• project_b est attribué à reservation_b, qui comporte 100 emplacements de référence sans autoscaling.
• Les deux réservations se trouvent dans 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, pendant 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_a démarre immédiatement et se voit allouer 500 emplacements.
• Le nombre d'emplacements alloués à query_b diminue rapidement à 100 emplacements de référence.
• Les requêtes supplémentaires exécutées dans project_b partagent 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.